Workflow UI design for automated and AI-run work

Most workflow tools focus on the build step. The demo shows a clean canvas, a few drag-and-drop blocks, and a workflow that runs perfectly from start to finish.

Real workflows don’t fail at the build step. They fail at the exception: a missing field, a rejected payment, a model that isn’t sure, a step that times out. At that moment, the automation stops, and a person has to understand what happened and decide what to do.

That screen, the one a person sees when the automation stops, matters most. This guide covers workflow UI design across the whole run, from the builder to the exception to the audit trail.

What workflow UI design covers

Workflow UI design is the design of the screens people use to create, watch, step into, and review automated processes. Those processes can be simple rules, such as routing an invoice for approval, or chains of AI steps that classify, decide, and act.

Every workflow UI has to serve four moments:

Build: someone defines the steps, rules, and conditions.
Run: the workflow executes, often thousands of times a day.
Intervene: something goes wrong or needs a decision, and a person steps in.
Audit: later, someone needs to know what happened and why.

Most products put nearly all their design effort into the first moment. Most of the risk sits in the third. The fourth is where the team finds out, weeks later, whether the third was handled well.

Why workflow tools are designed around the build step

The builder is the part that sells. It is visual, it demos well, and it is what a buyer sees first. So that is where product teams invest.

But the people who live in a workflow UI every day are rarely the ones who built it. They are operators, analysts, case workers and engineers. Their questions are different:

• Is everything running?
• What is stuck, and why?
• What do I need to approve right now?
• What did the system do while I wasn’t looking?

These are all questions about status. The first of Nielsen Norman Group’s usability heuristics, visibility of system status, says people need timely feedback about what a system is doing so they can decide what to do next. Automation makes this harder. When work happens in the background, the system’s state is invisible unless the interface puts it in front of people.

A workflow that runs smoothly almost every time still needs a good screen for the runs that don’t. Those rare runs are where money, time and trust are lost. They are also the runs a customer, an auditor or a manager will ask about later.

The four screens of a workflow UI

Each moment of a workflow needs its own screen, built around the question the user brings to it. The table shows what each screen must answer, and what goes wrong when it is missing:

Workflow builder UI: design the failure path first

A good workflow builder UI is still important. It just needs to treat exceptions as part of the design, not an afterthought. In practice, that means:

Every step has a visible “if this fails” branch. Retry, wait, skip, or route to a person. A step with no failure path should look unfinished on the canvas.
Human steps are first-class blocks. Approvals, reviews and hand-offs appear in the flow with an owner and a time limit, not as a comment in a config file.
Test runs use real edge cases. The builder lets people run the flow on bad data, missing fields and slow responses, not only on a perfect example.
The builder shows impact. Before publishing a change, the screen shows how many live runs it will affect.

Canvas or list?

Most workflow builders use one of two layouts, and each suits a different user:

A visual canvas of connected blocks works well for workflows with branches and parallel paths. It shows the shape of the process at a glance, which helps when someone is tracing where an exception came from.
A step list works better for long, mostly linear workflows. It is easier to read on smaller screens and easier to scan for a specific step.

Many tools offer both views of the same workflow. Whichever you choose, failure paths should be visible in it, not hidden in a settings panel.

The details that prevent exceptions

Conditions in plain language. “If invoice total is over $10,000, send to finance” is easier to check than a code expression.
Variables with examples. When a step uses data from an earlier step, the builder shows a sample value, so mistakes are visible before the first run.
Templates with failure paths included. A template that already handles common exceptions teaches good habits to every new builder.
Versioning. Every published change gets a version, and the history shows which version each run used. That links the builder directly to the audit view.

A builder that forces the failure path to be designed up front makes every later screen easier. The exception already has a destination before it happens.

Status views: sort by exception, not by time

The run screen is where operators spend their day. Its job is to answer one question quickly: what needs me?

Most status views fail at this because they list runs in time order. A failed run sits between ninety successful ones, and the operator has to hunt for it. A better workflow UI flips the order:

• Exceptions first. Failed, stuck and waiting-for-approval items rise to the top. Healthy runs collapse into a count.
• Clear states. “Failed,” “waiting on a person” and “waiting on another system” are different problems and need different labels.
• Time in state. An approval that has waited five minutes is fine. One that has waited two days is a problem.
• Owner on every exception. Each item shows who is expected to act.
• Filters that match how people work. By owner, by step, by type of exception and by customer or site, so each person sees their own queue.
• Bulk actions. When the same exception hits fifty items at once, people need to retry, reassign or approve them together, after reviewing a sample.
• SLA timers. Items close to a deadline change color or move up, before the deadline passes rather than after.

We used this pattern on OptivionAI, an AI-assisted platform for telecom network operations. Its map views are sorted by exception: faulty sites stand out and healthy ones recede, so operators see where to look before they start reading.

For large operations, the run screen often becomes a full monitoring dashboard. The same principle applies at that scale, and it is the core of our approach to AI dashboard design: the screen should point at the problem, not make people search for it.

The intervention screen: where the automation stops

This is the screen the whole workflow depends on. When an item stops and waits for a person, the screen has to give them everything needed to decide, in one place:

1. What happened. The item, the step it stopped at and the exact error or condition.
2. Why it stopped. The rule that fired, or the reason an AI step was unsure.
3. What the system suggests. A recommended action, if there is one, marked clearly as a suggestion.
4. What each choice will do. Approve, edit, reject, retry or escalate, with a short note on the consequence of each.
5. What happens next. Where the item goes once the person decides.

Microsoft’s Guidelines for Human-AI Interaction cover several of these points directly. The guidelines ask systems to make clear why they did what they did, support efficient correction when they are wrong, and convey the consequences of user actions. On an intervention screen, those are not nice extras. They are the difference between a correct fix and a guess.

Two design rules make this screen work in practice:

One record, not five tabs. People shouldn’t have to open logs, a second system, and an email thread to understand one item.
Fixing is as easy as approving. If the only fast button is “approve,” people will approve. Editing a value or choosing a different action should take one step too. This can not be emphasized enough.

Walkthrough: an exception arrives mid-run

Here is how a single exception should move through a workflow UI. The setting is a telecom operations workflow like the one we designed for OptivionAI, where an incident is detected, diagnosed, and fixed in the field.

1. The workflow is running
Automated checks run across thousands of network sites. When a site degrades, the workflow raises an incident, runs diagnostics, and, for known issues, applies a scripted fix. Most incidents close without anyone touching them.

2. An exception arrives
On one mast, a radio unit shows 98.99% packet loss while its neighbor on the same mast is healthy. The scripted restart doesn’t clear it, and the next step in the workflow is to send a field crew. Dispatching people costs time and money, so the workflow pauses and asks for approval. The item moves to the top of the operator’s queue, marked “needs decision.”

3. The operator opens one record
The intervention screen shows the whole story in one place: the alert on the national map, the site, the failing component, the event trail, and the fix that was already tried. The suggested next step, a field visit with a specific fix procedure, sits beside the evidence, not on top of it.

4. The operator approves or fixes
The operator can approve the dispatch as suggested. They can also edit it, for example by attaching a different fix procedure or changing the priority, or reject it and choose another path. Whatever they choose, the workflow resumes from that point. Engineers and the field technician then work from the same record, so the handoff doesn’t require two versions of the truth.

5. The history records it
The incident’s timeline now shows each step: what the automation did, where it stopped, who approved or changed what, and when the technician closed the incident in the field. A person reviewing it next month can see exactly why a crew was sent.

The audit view: what happened and why

On the Digital Management Framework (DMF), a smart city platform we designed, a timeline lets users move through historical events and footage with event tracking. The same idea applies to any workflow: history should be something people can navigate, not a log file they have to export.

The audit view also feeds the build step. When a team can see which exceptions happen most often, it knows which failure paths to automate next. That is how a workflow gets better instead of just getting busier.

Workflow automation UI with AI steps

AI makes the exception screen even more important. A rule either passes or fails. An AI step returns a guess, and sometimes it is unsure. That creates a new kind of exception: not “this broke,” but “I am not confident enough to continue.” Read this sentence twice, there is a big difference discussed here.

For workflow automation UI that includes AI steps, the intervention screen needs a few additions:

Confidence, in plain words. A label like “low confidence” next to any number, so people know when to look closer.
The evidence. What the AI step looked at, so the reviewer can check it rather than trust it.
A clear line on autonomy. Which steps the AI may complete alone, and which always need a person.

When AI agents run whole chains of steps on their own, these questions grow. We cover how to design for that in our guide to UI design for AI agents.

Common mistakes in workflow UI design

• Designing only the happy path. The demo works, and the first real exception lands in an email inbox.
• Treating errors as notifications. A red toast that disappears is not a place to resolve a problem.
• Splitting one item across many screens. If people need three tabs to understand one exception, they will act on partial information.
• Hiding automated actions. If the history shows only what people did, nobody can tell what the system did on its own.
• No owner for waiting items. An approval with no owner waits forever.

Each of these mistakes has the same cause: the team designed for the run that works, not for the run that stops.

Conclusion

Workflow UI design is usually judged by the builder, because that is what people see first. But workflows are judged by what happens when they stop. The status view that points at the problem, the intervention screen that lets a person decide well, and the history that explains it afterward are what make automation something a team can rely on.

Design the exception first, and the rest of the workflow UI gets easier. If you are building a product where automated or AI-run work needs people to step in at the right moment, our AI workflow UI design team can help.