Map a workflow before you draw screens

Why map first

When a workflow is complicated, the hard part is rarely the layout. It’s the decisions: who does what, in which order, with which information, and what happens when something goes wrong. A map gets those decisions onto one surface where product, design and engineering can argue about them before anyone has fallen in love with a screen.

On every complex project behind our work, from alert handling at an investment bank to troubleshooting journeys at a broadband provider, the map was the thing people kept coming back to. The screens changed many times. The map changed far less.

Choose one real scenario

A map gets unreadable fast when it tries to show the whole organisation. Start with one specific scenario. For example: a regional manager creates an event, submits it for approval and deals with a request for changes. Name the people involved and the outcome each of them needs.

Use realistic example data. Generic boxes labelled “input”, “process” and “output” hide the decisions you’re trying to find. A good map makes the team ask sharp questions, like “does the approver see the same version as the person who submitted it?”

Give each kind of thing its own shape

You don’t need specialist notation. You need a simple vocabulary everyone reads the same way. We show user actions as actions, decisions as questions and system responses as responses, with a lane for each role so handovers jump out.

At each step, note what information is needed, who provides it and what changes. For a request review, that might be the request version, supporting documents, the assigned reviewer and the decision status. If nobody can explain where a value comes from, mark the gap. Don’t fill it with a convenient guess.

Include the work that happens off-screen

Complex workflows often depend on email, spreadsheets, phone calls or another system entirely. Include these when they affect whether the task gets done. Otherwise you’ll end up with a tidy screen flow that hides the hardest part of the job.

Say your event platform lets someone draft a request, but budget approval happens somewhere else. The design needs to be honest about that dependency. It shouldn’t label an event “approved” just because the form was submitted.

Walk through the exceptions

Once the main route is clear, test it against a handful of alternatives that matter. What if the reviewer is on holiday? Can the requester edit details while a review is underway? What if a required attachment doesn’t exist? Who owns the next step after a rejection?

You’re not trying to draw an enormous decision tree. Keep the main map readable and give complicated branches their own focused view. Keep a short exception log for anything that needs a policy or technical decision before it can be designed.

Turn the map into a design brief

Review the map with product, engineering and people who know how the work gets done day to day. Mark confirmed rules, assumptions and open questions differently. And don’t mistake agreement in a workshop for validation with users. They’re not the same thing.

Before moving on to screens, check that:

• Every handover has someone receiving it and a clear next action.
• Every status has a clear meaning.
• The information people need is available when they need it.
• Every failure has a way to recover, or an honest explanation.
• Every important assumption has an owner.

The enterprise event-creation case shows this kind of mapping in a large organisation, with flexible authoring and consent-aware guest management designed as one platform. Complex Workflow Design always starts with a map like this, agreed with your team before any screens are designed.