Writing · 4 min read
Designing for the moment the workflow breaks
When an order stalls or a transaction fails, people need more than an error message. They need to understand what happened, what it affects, and what they can safely do next. The design work is to make the business situation legible, to separate what the system knows from what it only assumes, and to design the recovery rather than the warning alone. The scenario below is illustrative, not an account of a project already delivered.
Key idea 1 of 5
One order, three screens, no account of what happened
Making operational software easier to use starts with what someone has to do when the normal process stops working. A cleaner dashboard may help. The more useful question is whether the product lets a person recognize the problem, understand what it costs, and take the next correct action.
Picture an operations coordinator investigating an order a customer says never arrived.
One screen says the document was sent. Another shows a processing failure. A third carries the customer’s order number, and the first two identify the same order by two other numbers. The coordinator opens a support ticket, copies values between windows, and asks an integration specialist whether it is safe to try again.
The information may all be there. What is missing is a coherent account of the situation.
That is where the design work starts.
Key idea 2 of 5
Start from the last time it happened, told by both people who were there
Before proposing a new dashboard, I would ask someone to walk me through the last time this happened.
What first told them something was wrong? Which screen did they open next? What did they copy somewhere else? At what point did they stop investigating and ask another person?
I would want the person responsible for the business outcome and the specialist who resolved it, because their accounts describe different parts of the same problem.
The coordinator says: I could not tell whether the customer had the order.
The specialist says: the message reached the destination, but we had no confirmation that the receiving application accepted it.
That difference is not something to smooth over in a research summary. It is a requirement. The interface has to separate what the system knows from what the person needs to know.
Key idea 3 of 5
Sent, received and accepted are three different facts
Sent, received and accepted are three different stages here. I would work with engineering and architecture to pin down what each one means, what evidence stands behind it, and where the product genuinely does not know.
Then organize the experience around the task rather than around the system that produced the record.
A coordinator investigating an order needs its current business state, the affected customer, the last confirmed event, whoever is already working on it, and the available next steps. An integration specialist needs the underlying document, the processing history, and the diagnostics.
Those two views should connect. They do not have to show the same detail at the same moment.
The system knows
- Sent: the document left, with a timestamp
- Received: the message reached the destination
- Who is already working on it, and the last confirmed event
It only assumes
- Accepted: that the receiving application took it
- That the customer has the order
- That trying again is safe
I would also resist making the screen look simpler by hiding what experienced users compare. A dense data table can be the right tool for reviewing a queue. The question is whether its hierarchy, its terminology and its interactions support the work, not how much sits on it.
Key idea 4 of 5
Design the recovery, not only the warning
An alert is the beginning of the experience, not the end of it.
Say the next action is to retry a failed transaction. Before designing that button, I would ask engineering what happens when someone presses it.
Do we know whether the first attempt reached its destination? What prevents duplicate processing? Does this person have permission? Could a colleague already be working the same issue?
- Reached?did the first attempt arrive
- Duplicate?what prevents processing twice
- Permitted?does this person have the right
- Owned?is a colleague already on it
The answers are the design. The person needs to see the scope of the retry, confirm a consequential action, understand that processing is still under way, and tell a submitted request apart from a confirmed result.
There also has to be a useful path when they cannot resolve it themselves. Escalation should carry the context forward: the transaction, the evidence, what has already been tried, and why help is needed. A recovery is not finished if the person still has to take screenshots and explain it all again.
Key idea 5 of 5
Measure whether the work got easier
For a change like this I would set a baseline around the investigation itself.
How long does it take to identify the issue and its owner? How often do people pick the correct next action? Which escalations are necessary, and which happen because the product withheld context it had? Do resolved issues come back?
Those measures have to account for issues of different difficulty. A faster resolution is not automatically a better one.
The designer’s contribution is to connect the questions people actually ask to what the system can actually answer, and to help the team turn that into a workflow someone can use under pressure.
The test is whether a person leaves the screen able to say: I know what happened, I know what is still uncertain, and I know what to do next.