AI-Assisted Workflows
Designing recommendations that operators can trust, question and override.
Recreated from my work on a real enterprise logistics platform. Screens, names and data are fictional. The problems, decisions and trade-offs are real.
- Product
- Exception recommendations
- Platform
- Enterprise web application
- Role
- Lead product designer - interaction design, explainability patterns, design system contribution
- Design focus
- Human-in-the-loopExplainabilityDecision supportOverride design
Problem
When a system recommends an action in a live operation, the risk isn't a wrong recommendation, it's an unexplained one. Operators either follow it blindly or ignore it, and neither builds trust.
No reason, no confidence, no way to disagree.
Approach
- 01
Mapped the decisions operators actually make
Sat with control-room operators and listed the moments where a suggestion would change what they do next. That told me where a recommendation belongs in the workflow, and where it would only be noise.
- 02
Put the recommendation inside the workflow
The recommendation sits beside the exception it concerns, using the same status language and the same reference style, so it reads as part of the operation and not as a separate AI feature.
- 03
Made the override a feedback loop
Dismissing or overriding takes one step and one line of reasoning. Those reasons go to a review queue, so the people who maintain the rules can see where the system and the operators disagree.
Key UX decisions
Show the reason, not just the action
Every recommendation states the rule or signal behind it in one line.
Confidence is visible but plain
A simple level and its basis, not a percentage that implies false precision.
Apply is never the only option
Dismiss and override are equally reachable, and overrides ask for a one-line reason that feeds review.
Nothing irreversible runs unattended
High-impact actions require confirmation and show what will change.
Decisions & leadership
Trade-off I made
A single "Apply" button would have been the fastest interaction, and the easiest to demo. I chose to put the reason, the confidence level and the dismiss option in the same panel, which costs more space and a few seconds per decision. I accepted that because a fast action nobody trusts gets ignored, and then the recommendation has no value at all.
Where I pushed back
The early direction was to show a confidence percentage on every recommendation. I argued that "87%" implies a precision the underlying signals don't have, and operators would either treat it as a guarantee or learn to discount it. I proposed a plain level (high, medium, low) with its basis stated in one line, and we reviewed both versions against real past cases before settling on it.
How the team adopted it
I documented the recommendation panel as a design-system pattern with its states: suggested, applied, dismissed, overridden and failed. Other designers and engineers could then reuse it for new recommendation types without redesigning the logic, and new rules had to supply a reason line before they could ship.
What I'd do differently
I would define the override-review loop earlier. Overrides are the most useful data the product produces, but we designed the capture before we designed who reads it and how it changes the rules. Next time I'd design that review step in the first iteration.
Final product screens
Outcome & impact
| Measure | Before | After |
|---|---|---|
| Why a suggestion was made | Not shown | One-line reason on every recommendation |
| Confidence | Absent, or a bare percentage | Plain level with its basis |
| Operator control | Apply or ignore | Apply, dismiss or override, equally reachable |
| High-impact actions | Could run in one click | Confirmation that shows what will change |
| Overrides | Lost | Captured with a one-line reason for review |
Operators can see why a suggestion was made and keep control of the decision. Overrides become data the team can learn from.
Some product names, data, and details have been anonymized or represented for confidentiality. The case studies reflect real design challenges, decisions, workflows, and outcomes from my professional experience.
Playbook: customs hold over 4 hours, and Felixstowe has confirmed capacity.
Confidence: Medium
More case studies
All case studies →- 01Insurance
Claims & Policy Operations
Claims handlers worked across disconnected screens to judge cover, chase documents and route approvals - so decisions stalled long before anyone had all the facts.
View case study→ - 02Banking
Transaction & Reconciliation Platform
Operations teams reconciled thousands of ledger and statement lines a day, but the exceptions that actually needed a human were buried inside everything that matched automatically.
View case study→ - 03Logistics
Shipment & Exception Control Tower
Control-room teams monitored a live European network on screens that reported status well but never said which disruption to act on first, or what to do about it.
View case study→ - 04Enterprise mobile
Field Operations App
Field engineers captured work on a mobile app built like a desktop form - slow to complete, unusable with gloves, and dependent on a connection they often did not have.
View case study→
Let's talk.
I'm Pavan, a Lead Product Designer with six years in enterprise and B2B product design across finance, banking, insurance, logistics and internal business systems. Most of my work sits where business rules, user needs and technical constraints meet. I turn complicated workflows into products that are clear to use and easy to learn.
What I specialise in
- Enterprise & B2B product design
- UX architecture & workflow design
- Interaction & UI design
- Design systems & governance
- UX research & usability testing
- WCAG 2.1 AA accessibility
Availability - open to Lead Product Design and UI/UX roles
- pavanps583@gmail.com
- Phone
- +91 94497 22598
- linkedin.com/in/pavan-ps
- Location
- Mangalore, India