Designing for the moment the workflow breaks

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. Take one order, from the phone call to the fix.

A customer calls to say the order never arrived. The coordinator who takes the call opens the order screen, and it says the document was sent. The integration monitor shows a processing failure on a document with a different number. A third screen carries the customer’s own order number, and the first two identify the same order by two other numbers.

Between them, the systems know a good deal. They know when the document left, that it reached the trading partner’s side, and that something downstream rejected it, on which field.

None of them says the thing the coordinator was asked: does the customer have the order, and if not, what happens now. The information may all be there. What is missing is a coherent account of the situation.

So the coordinator opens a support ticket, copies values between three windows, and asks an integration specialist whether it is safe to try again. The customer waits on an answer the systems held between them all along. The specialist begins rebuilding a story the screens could have told.

The order is invented, and I have not designed an integration product. I have designed for operational work: a dispatch room running more than 450 trucks and a portfolio of SAP apps used in the field. The method in the rest of this article comes from that work.

Key idea 2 of 5

Start from the last time it happened, told by both people who were there

On the dispatch floor I learned the job before redesigning the tool, and it is where my own first idea died. I assumed dispatchers needed a map, because a map is how I would have found my way around the work. Once I sat beside them it was plain that they knew every location code by heart. What slowed them down was scanning long lists.

That is not the kind of thing that ends up in a requirements document. To the people doing the job it was not a requirement. It was how the job was done. The case study has the cards, and where the map ended up.

For the stalled order the same method starts with the last real time it happened. What first told someone it 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?

It needs two tellers: the person responsible for the business outcome and the specialist who resolved it. Their accounts describe different parts of the same problem.

For this order they might go like this. The coordinator: I could not tell whether the customer had the order. The specialist: the message reached the destination, but nothing confirmed 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, and each stands on different evidence:

• Sent: a timestamp when the document left
• Received: an acknowledgment when it arrived
• Accepted: either a confirmation from the receiving application or nothing at all

Pinning those down is work to do with engineering and architecture. It includes writing down where the product genuinely does not know.

Then the experience gets organized 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
• 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

The other trap is to make the screen look simpler by hiding what experienced people compare. On the dispatch floor the screen that worked was the denser one. The dispatchers could sort and stack its cards at the speed of what they already knew.

A dense data table can be the right tool for a queue of failed orders for the same reason. 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 the failed transaction. Before anyone designs that button, engineering has to answer what happens when someone presses it.

1. Reached?did the first attempt arrive
2. Duplicate?what prevents processing twice
3. Permitted?does this person have the right
4. 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
• Tell a submitted request apart from a confirmed result

I have built one version of this, for a different person. The rollback in the Deploy Console prototype lists every service it will change and every one it will leave alone. Each comes with its reason, before anything moves. The rows that say unchanged matter as much as the ones that change, because they are what let somebody press.

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

On the dispatch floor the measure came from the work rather than from the screen. Board-clearing time was read from the dispatch system’s own timestamps, from an order entering the unassigned queue to its assignment. It was a median over four weekday weeks before launch and four after, with a holiday week left out.

Wrong-vehicle dispatches came from the operations manager’s log of reassignments. The counts were small enough that the direction was worth more than the size.

For the stalled order the baseline is 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. A coordinator can close the ticket in four minutes by resubmitting an order that had in fact gone through. That makes the number better and the customer’s week worse.

The test is whether a person leaves the screen able to say: I know what happened. I know what is still uncertain. I know what to do next.