Case study ↓
Designing Governance & Approval Workflows for Ruleset Management
Webapp, Service Design
A major enterprise client identified that the existing ruleset management process was highly manual and difficult to scale. In response, I designed a governance-driven workflow enabling teams to securely view, edit, and reassign policies across cards and tokens through approval-based controls. While initially driven by one client’s operational needs, the solution was expanded using additional client use cases to create a more scalable and flexible platform experience.
Roles
Lead UX/UI design
Service Design
Tools
Figma
Miro
Client:
Thredd.ai
Problem ↓
What the problems they are facing today?
As enterprise clients (We will called in “P” from here) scaled their programmes and operational complexity, managing policy controls and rulesets became increasingly difficult. Existing workflows relied heavily on manual operational processes, internal support teams, and fragmented approval handling to manage policy updates across cards and tokens.
Existing Workflow
Why is this problem was difficult?
Heavy Reliance on Manual Operations
Policy and ruleset updates required operational teams to manually review, coordinate, and execute configuration changes across cards and tokens.
Fragmented Communication Channels
Requests and approvals were handled across emails, Slack, meetings, and Jira tickets, making workflows difficult to track and manage.
Lack of Governance & Approval Visibility
There was no structured approval workflow within the platform, limiting visibility, accountability, and auditability for sensitive policy changes.
High Operational Risk
Manual ruleset editing and reassignment increased the risk of incorrect configurations, unauthorised changes, and difficult rollback processes.
Limited Self-Service Capability
Enterprise clients depended heavily on internal support and operations teams to perform routine policy management tasks.
Poor Scalability for Enterprise Clients
As clients scaled across multiple programmes, governance models, and approval layers, the existing workflow became increasingly difficult to maintain efficiently.
Research ↓
What I discovered
Understanding Enterprise Operational Needs
To better understand the operational complexity behind ruleset management, I collaborated closely with product, operations, and platform stakeholders to map existing workflows, governance requirements, and user responsibilities across the policy management lifecycle.
Workshop & User Story Mapping
Workshop Goals
1.
Identify operational pain points
2.
Understand governance and approval requirements
3.
Map dependencies across cards, tokens, and rulesets
4.
Prioritise MVP vs future scalability needs
5.
Align cross-functional stakeholders on workflow complexity
The workshop surfaced a critical structural insight: the platform needed to support not one type of user, but a tiered hierarchy of roles — each with distinct responsibilities, access levels, and approval authority. This directly shaped how I approached the design.
Discover ↓
What I discovered
Defining Roles & Jobs to Be Done
Working with the product and operations teams, I led a role-definition exercise that resulted in four platform personas, each mapped to their primary Jobs to Be Done:
Design Process
Given the complexity of designing for multiple roles simultaneously, I established a structured, phased process to keep the workstream aligned across product, engineering, and operations:
This incremental validation approach reduced the risk of late-stage misalignment and kept all teams anchored to the same source of truth throughout the process.
Ideas ↓
The key design decisions
Structuring the Work: From Roles to Epics
With roles, JTBDs, and user flows aligned, the design work was organised into three epics — each representing a distinct area of platform functionality, scoped by the roles that needed to interact with it.
This epic structure was a deliberate decision. Rather than designing feature-by-feature, organising around epics meant every screen and interaction could be anchored to a specific user need and permission boundary. It also allowed parallel workstreams to progress without creating dependencies that would slow delivery.
Epic 1: Rulesets Configuration
The first epic covered the core ruleset management experience — the primary surface where operational teams spend the majority of their time.
Epic 2: Rulesets Connected to Current Token
The second epic addressed a distinct but related need: understanding which rulesets govern a specific card or token, and being able to act on that directly from the card's configuration view.
Epic 3: Service Design — Approval Workflow
The approval workflow was the most complex and governance-critical part of the project, and the area where I took the lead on design.
The core challenge was designing a system that enforced compliance rigour without creating friction that would push users back to informal channels — the very problem the platform was built to solve. Two surfaces needed to work in tandem: a request tracking view for the user who submitted the change, and a review and action view for the Approver
Detailed Process Flows
Beneath the three epics sat a set of more granular process flows that defined how the system should behave at critical decision points — ensuring governance constraints were structurally enforced rather than left to implementation interpretation.
Compliance Guardrails
When a user sets a limit on a ruleset, the system validates it against the BIN Sponsor Max Limit of $10,000. Values below the threshold are routed through the standard approval workflow. Values above it trigger a hard error and are rejected immediately — preventing non-compliant configurations from ever reaching the approval queue.
Gated Change Process
When a user edits a ruleset, the system determines whether approval is required. If yes, the request enters a time-bound approval window — actioned within the window it is approved; if the window expires, it is automatically rejected. Changes that don't require approval are applied directly, ensuring low-risk edits don't create unnecessary bottlenecks.
Re-assign Card to Ruleset
From Cards & Transactions, users navigate to a specific token and into its Card Configuration Detail, which surfaces four configuration dimensions: Group Usage, MCC, Fee Configuration, and Group Limit. A re-assign action is available from any of these views, keeping the current configuration visible throughout to reduce the risk of incorrect reassignments.
From Flows to Low-Fidelity Designs
With the user flows and process logic validated by stakeholders, I translated the architecture into low-fidelity designs. This first pass mapped each role's journey across the platform — from the Rulesets Configuration view and drill-down detail screens, through to the Approval Dashboard and the Cards & Transactions surface. The lo-fi stage was used to pressure-test layout decisions, confirm navigation hierarchy, and surface any structural gaps before investing in high-fidelity execution.
Implement ↓
Final Solution
The final designs were delivered as three interactive prototypes, each presenting the platform experience from a distinct user role perspective.
Persona 1 — Read-Only
A visibility-focused experience for support and reporting users to search, view, and export ruleset configurations across cards and tokens — without edit access.
Persona 2 — View & Edit
An operational workflow enabling users to manage and edit ruleset configurations, with inline validation and a structured change request process that routes edits to an Approver before going live.
Persona 3 — Approver
A governance-focused experience giving Approvers a centralised dashboard to review pending change requests, assess configuration diffs, and approve or reject edits within a defined compliance window.
🌟 Impacts of the solution
The result was a single governed workflow that replaced a process previously spread across ~30 people and four disconnected tools. What had been manual, ad hoc, and unaccountable became self-service, auditable, and owned.
Concretely, against the problems we started with:
Manual operational updates
✔ Enterprise clients now manage rulesets directly, without routing every change through internal support.
Fragmented requests across email, Slack, and Jira
✔ One workflow with a single source of truth.
No governance or approval visibility
✔ Structured approval oversight with a clear, auditable trail of who changed what, and who signed off.
High operational and rollback risk
✔ Controlled, reversible changes with accountability built into each step.
Poor scalability
✔ A governance model that grows with the client rather than breaking under volume.
[If you have any hard outcomes, this is where one or two land hardest — e.g. approval turnaround time, number of enterprise clients now self-serving, or reduction in support tickets. Even one real number lifts this section a lot.]
Why this matters next: governing agentic payments
This system solved a human-scale problem — giving teams a single, governed way to edit, approve, and manage rulesets with clear accountability. That same governance layer is becoming foundational for agentic payments, and it maps directly onto where Thredd is now heading: a platform rebuilt for agentic commerce and autonomous payments.
As AI agents begin to initiate and manage transactions on a platform's behalf, the question shifts from can they act to who authorised this rule, within what limits, and who's accountable when it changes. Scoped permissions, approval oversight, and an auditable change history — the core of what I designed — are exactly the controls autonomous payments depend on. The architecture is the same; only the actor changes. Designing governance for human operators at scale turned out to be the same problem, one actor-type early, as governing what machines are allowed to do.
See other case studies ↓
