See which parts of a difficult workflow are difficult because the work is genuinely difficult, and which are difficult because the product made them so.
Use this before simplifying anything. Removing necessary complexity is worse than leaving it.
It is for product managers, designers and operations leads who keep hearing that something is confusing.
You need one workflow and one person who does it for real. Allow enough time to walk it end to end with them, and do this with them rather than about them.
Write the workflow as done, not as designed. Number each step and include everything, including the parts that happen outside your product.
For each step record who does it, what they need to know, what they decide, and what they produce.
Pay attention to any step that involves a spreadsheet, a message to a colleague, a note somewhere, or a rule someone carries in their head. Those steps are the most informative in the exercise because they mark places where the product stopped helping.
A person exercises judgement. The complexity here is real.
Information has to get into the system.
Someone verifies something before continuing.
Responsibility moves to another person or team.
Someone is getting to where the work happens.
Someone is making two sources agree.
Something happens outside the product because the product cannot do it.
Different types fail for different reasons. Use the question for each type, then interpret what a bad answer means.
| Type | The question that matters | What a bad answer means |
|---|---|---|
DECISION | Does the person have everything they need, in one place, at the moment they decide? | They are gathering, not deciding. Bring the context to the decision. |
INPUT | Is this information the product could already know? | You are asking a person to do a system's job. |
CHECK | What goes wrong if this check is skipped? | If nothing, the check is ritual. If something, why is it manual? |
HANDOFF | Does the receiver get everything they need, including why? | Handoffs that lose context become rework. |
NAVIGATION | How many of these steps exist purely to get somewhere? | Navigation is pure cost. It never produces anything. |
RECONCILIATION | Why do two sources exist? | Often a product model problem wearing a workflow costume. |
WORKAROUND | What need does this serve that the product ignores? | This is your most valuable finding. Do not remove it. Understand it. |
Steps that exist because the work genuinely requires judgement, verification, coordination or care. Consequential decisions belong here. So do checks that prevent real harm. Simplifying these makes the product worse and the users less safe.
Navigation, re-entry of known information, reconciliation between sources that should not both exist, checks nobody can justify, and every workaround. This is where the friction actually lives.
Teams often start this exercise believing the workflow is too complex, and finish it having separated two things: a decision that was always going to require judgement, and a layer the product added on top of it.
Deal with changes in this order, because each makes the next easier to see.
These reveal what the product model is missing, and fixing them often removes several other steps.
Cheapest visible win.
Bring the work to the person rather than the person to the work.
Retire checks nobody can justify, deliberately and with the person accountable for them.
Instead, make them better supported.
Information Architecture and Workflow Design is the service that resolves what step 4 usually uncovers. The Dealpath case shows the same separation applied to a mature enterprise product, and the workflow design definition covers the underlying idea.
If the mapping shows the cause is disputed rather than obvious, the UX and Product Audit starts with a free audit on one workflow.
Use one real workflow with one person who does it for real, then separate necessary complexity from accidental complexity before deciding what to change.
