Reviewers
Prepare a complete request with the relevant context.
Accord
Independent B2B concept
A traceable path through contract policy exceptions.
I designed a desktop concept that helps reviewers compare a clause with company policy, prepare an exception and record the final decision.
Product
A fictional contract review workspace
Focused on clauses that fall outside company policy.
Contribution
Problem framing through high fidelity
Information architecture, interaction model, visual direction and prototype.
Current outcome
A connected flow ready to test
Review, exception preparation, approval, failure states and audit record.
Why this scope
Exception handling combines policy interpretation, business pressure, human judgement and a durable record. It offered a focused way to explore responsible AI in a B2B workflow.
01 · Context and stakes
Exceptions gather context from several places before anyone can make a defensible decision.
Reviewers may need the proposed clause, company playbook, previous decisions, business rationale and the right approver. I explored whether bringing that context into one workflow could reduce clarification and strengthen the decision record.
Approvers
See policy, precedent, rationale and evidence before deciding.
Business
Keep decisions accountable and easier to audit.
02 · Evidence and assumptions
What informed the first prototype.
I reviewed contract products, public Legal Ops material and responsible AI guidance. The result was a plausible workflow and a set of questions for practitioners.
Seen in desk research
- Reviews use clauses, playbooks, owners and approval status.
- Exceptions need a rationale and decision record.
Design assumptions
- Policy and precedent are useful beside the proposed clause.
- A structured request may reduce clarification.
Still unknown
- How often exceptions create delays.
- Who owns each step across organisations.
Before high fidelity
I mapped the review loop first.
Early frames checked the sequence, information order and reviewer-to-approver handoff. They also exposed missing evidence and disagreement as states to design.
03 · Success definition
How I would evaluate the direction.
Four measures give the first sessions a standard beyond visual quality.
Speed
Time from flagged deviation to final decision.
Completeness
Requests sent with the required rationale and evidence.
Rework
Clarification loops before an approver can decide.
Trust
Reviewer confidence in AI guidance and its sources.
04 · Product decisions
Four decisions shape the workflow.
Decision 1
Start with the work that needs attention.
The queue shows deviation, risk, owner, due date and status before a contract is opened.
Tradeoff
Each row has one primary risk label. Metadata stays neutral and orange is reserved for the deviation that needs action.
Decision 2
Keep policy beside the clause.
Proposed wording and company guidance share one working view.
Tradeoff
The three-column desktop layout would need a dedicated focus mode on narrower screens.
Decision 3
Structure the exception before approval.
The request captures rationale, business impact, fallback wording, evidence and approver. Missing context is visible early.
Tradeoff
Required fields add consistency; free text covers cases the form cannot anticipate.
Decision 4
Make the decision and its record explicit.
The approver sees the relevant context before acting. The final decision is written to an audit timeline.
AI boundary
AI summarises sourced material and suggests a next step. A named person approves, and weak evidence pauses the recommendation.
05 · Failure states
Three routes for cases that cannot continue.
The extended flow keeps uncertainty, feedback and ownership visible.
Evidence gap
Weak sources pause the recommendation.
The reviewer is directed to stronger sources or the policy owner.
Feedback stays attached.
The approver returns the request with the missing context.
Both positions remain visible.
A named policy owner receives the disputed evidence before deciding.
06 · Prototype and next step
The expanded flow is ready to test.
The clickable prototype covers approval, a returned request and an escalation.
Core tasks
- Understand the deviation and guidance.
- Check the AI suggestion against its sources.
- Prepare or approve an exception.
Questions for practitioners
- Where do exceptions create delays?
- Who owns each step?
- Which evidence supports a confident decision?
Next step
Test with Legal Ops practitioners.
I would recruit four to six practitioners, run one realistic exception through the workflow and revise roles, context and decision steps before making an impact claim.