Designed decision layer between AI findings and human accountability
Product designer (solo)
Self-directed side project
10-day sprint
Web and mobile, Figma prototype
Summary
AI can find a problem in a second, but before someone acts on it, they need to understand it, trust the evidence, and know what happens next. AI Exception Studio is a decision workspace where an accounts payable specialist reviews, edits, and approves the mismatches an AI flags across purchase orders, invoices, and internal records.
Product framing from the brief
Human / AI responsibility split
Failure & uncertainty states
Tokens, type & tags reworked
End-to-end workflow
- Defined the product concept: user, operational context, exception type, and stakes
- Mapped the human-versus-AI responsibility split, including which actions require approval and which thresholds trigger escalation
- Designed three failure and uncertainty states alongside the happy path: low-confidence evidence, conflicting source documents, and partial execution failure
- Reworked an existing SaaS UI kit for this workflow with my own color tokens, typography and text styles, and status tags
- Designed the full workflow end to end: exception inbox, exception detail with an editable AI plan, evidence comparison, consequence preview and approval, and resolution and audit trail, plus a partial-failure and an empty state
- Accounts payable operations specialist (primary)
- Accounts payable manager (escalation approver)
Why this problem
AI is getting good at flagging what's wrong in accounts payable, but every flag still lands on a person who has to decide whether to act on it, with money, a vendor relationship, and an audit trail on the line. I wanted to design that moment: where a specialist either trusts the AI enough to approve, or knows exactly why they shouldn't.
The design challenge
An unresolved exception delays payment and strains a vendor relationship. A specialist who rubber-stamps findings just to keep the queue moving creates real financial and audit risk, not just a UX inconvenience.
Before anyone acts on a finding, they need to know
- What it found
- What evidence it used
- Where it's uncertain
- What it recommends
- What happens if approved
- Who stays accountable if wrong
The final screens
One exception, step by step. Click any screen to see it full size.
Mobile experience
Reviewing an exception doesn't stop at a desk. The same decision model carries over to mobile: the overview dashboard, exception detail, consequence preview and approval, and the resolved audit trail, not a stripped-down companion view but the same workflow at phone width.
What I assumed
This is a self-directed concept built on a common accounts payable pattern, a three-way match between a purchase order, a vendor invoice, and an internal record, so the persona and failure states are my own design reasoning, not interview findings. The next step would be two or three conversations with people who work AP exception queues, to pressure-test the assumptions below.
Notice
Is this worth my attention right now?
Verify
Does the evidence actually support this?
Weigh
How much do I trust this confidence score?
Decide
What should happen, and can I edit the plan?
Act
What exactly changes when I approve?
Confirm
Did it actually work?
Design principles
The lens every screen and decision in this project was run through.
The AI proposes, the specialist decides
Nothing touches a live system without a person's approval.
State uncertainty, don't disguise it
Confidence is a spectrum, not a gate
Try it in the slider below.
Buttons say what they'll do
"Approve and update 3 systems," never "Submit."
Drag the confidence score
The same exception at three different scores. What changes is how much verification the screen asks for before anything runs, not just the color of the bar.
What the screen asks for
The specific fields that disagree are flagged and opened for a check, rather than the whole record being re-verified.
The AI says which part it is unsure about instead of presenting a best guess with one confident number attached.
Primary action
Verify 2 fields, then approveThe button is named for its consequence at every score, so the reader never approves something described only as "Submit."
Early Exploration
Low-fi first: structure before style
Before any color, I wireframed every screen in greyscale in Figma, so each one had to answer a single question: what is the specialist deciding here, and what do they need to see first? Failure states got the same fidelity as the happy path.
The end-to-end flow
The low-fi screens wired into one flow in FigJam: every decision point, branch, and failure path. Pan and zoom to explore.
Key decisions
Confidence as a spectrum, not a badge
Rejected the binary green/red badge. Confidence is visible everywhere the AI makes a claim, with reasoning one tap away.
An editable plan, not accept-or-reject
The resolution plan is a sequence of individually editable steps. The specialist collaborates with the plan instead of voting on it.
Action language, not a generic Submit
“Approve and update three systems” states the actual consequence. Copy is only honest if the product tracked which systems change.
AI design thinking
Why AI
AI takes on the matching, the evidence gathering, and the first draft of a plan. Here's how that changes the work:
Human vs AI output
AI produced
- →Finds the mismatch between PO, invoice, and record, down to the field
- →A confidence score, with evidence and reasoning visible on request
- →A resolution plan, split into steps a person can review one by one
Human controlled
- ◎Approve, edit, or remove any step before it runs
- ◎Reject the plan and resolve it manually
- ◎Escalate to a manager, by choice or by threshold
Confidence and dollar impact together decide how much friction sits between a recommendation and its execution.
Trade-offs
What didn't make v1
Intent and measurement
From
“The AI found something.”
To
“I understand the issue, trust the evidence, and know what happens when I approve.”
This is a concept prototype, so there's no usage data yet. The first round of testing would answer three questions:
Does low confidence read as "use judgment"?
Or does a 41% flag get approved on autopilot? The riskiest assumption in the design.
What does the edit rate on AI plans mean?
Low could mean accurate plans, or controls that are hard to trust. The rate alone won't say which.
Can a specialist explain the consequence?
Before approving, they should be able to say which systems change and what can be undone.
The emotional shape of building it
Nine real moments across the ten days, not just the finished screens.
Reflection
The most valuable part to design was what the product says when it doesn't know the answer. A polished happy path shows you can design a clean flow; designing for uncertainty is where an AI product earns trust.
Everything here is still a hypothesis until it's tested with people who work exception queues. That's the next step, not another screen.