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
Client:
Thredd.ai
"One incorrect ruleset could impact thousands of payment cards instantly."
My challenge wasn’t simply designing a new screen—it was designing governance that allowed teams to move faster without increasing operational risk.
Problem ↓
What problems are they facing today?
As enterprise clients 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 was this problem 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 asked
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
Who was in the room and why it mattered
I brought compliance, engineering leads and client-facing teams into one room deliberately. Each group held a different piece of the workflow in their head, and no two pieces matched. Mapping the story together was the fastest way to surface where they disagreed.
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
Where it gets messy: edge cases and guardrails
Approval systems fail at the edges, not the happy path. These are the states we designed for: rejections with a hard compliance limit, approvals that expire before anyone acts, and changes submitted against a configuration that moved underneath them.
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.
Outcome ↓
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.
Built for the people who investigate, not configure.
Customer service and card investigation teams don't edit rulesets; they need to answer one question fast: "why did this card behave that way?" The read-only panel gives them the full picture without the risk. Blast radius upfront (2,341 cards, 3 products linked to this policy), every rule grouped by category, and a scannable Active/Inactive status on each line. No edit controls, no accidental changes, just the evidence trail an investigation needs, exportable when it has to travel to another team.
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.
The maker's flow: edit freely, submit safely.
Mid-tier product managers keep rulesets up to date without engineering support, but no change here goes live directly. The review step confronts them with the full consequence of their edit, 2,341 cards affected, before routing it to an approver, with scheduling control over when the change lands. One mistake at this scale is expensive; the flow is designed so it can't happen quietly.
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.
Built for the people who carry the accountability.
Approvers sit at the top of the chain: they didn't make the change, but they answer for it. The review panel is designed so a decision needs no digging: who requested it, when it lands, and the exact before-and-after of every rule, Active → Inactive, shown as a diff rather than a description. The consequence sits right beside the change: 2,480 tokens affected by this one approval. Everything an accountable decision requires, in a single glance, ending in exactly two actions: approve or reject.
🌟 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.
This work is in build now, so no invented adoption numbers.
What I can stand behind:Validated with approvers at two of Thredd's enterprise clients, each running large-scale regulated card programmes, where one broken approval risks a programme, not just a team's afternoon. Approved by client-side approvers and internal compliance, greenlit for build across all three epics.
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.
⚡️ Learnings from this project
Complexity never disappears, it only moves.
Rulesets touching thousands of live cards can't be made simple, but the burden can be placed deliberately: structure for the maker, clarity for the approver, and an audit trail nobody has to think about until they need it.
Design the change process, not just the screens
The hardest problems weren't in any single flow. They were in what happens between states: a ruleset mid-approval, an edit during review, a token pointing at a config that's about to change. Enterprise design is mostly designing the in-between.
See other case studies ↓
