B2B Workflow Design for the Process People Actually Run

Every B2B product I have worked on arrived with a workflow diagram, and in almost every case the diagram described a process nobody had run in years. The real one lived in a spreadsheet on somebody’s second monitor and in the head of the one person everybody asks when something goes wrong.

B2B workflow design is the job of finding that real process and giving it a surface. Here is how I go looking for it, the four things a workflow design has to settle before anyone opens Figma, and why the exception path decides whether your software gets used or worked around.

The process in the document and the process on the floor

The documented process is what the organisation agreed to. The real process is what it does at 4pm on a Friday when a customer changes an order that has already been picked. The two drift apart by design, because the document was written for the happy path while the floor absorbed a decade of exceptions.

Software built from the document demos well and fails in week two. Staff hit the first case it does not cover, find no way forward, and go back to the spreadsheet. Now there are two systems, and the one that cost money holds the stale data.

On a wholesale ordering platform I designed, the documented flow was browse, add to cart, check out. What buyers did was open last month’s order, change four lines and send it. A nine second reorder mattered far more than the browse experience, and only watching made that obvious. You can see how it turned out in my case studies.

Finding the real workflow

Interviews on their own will not get you there, because people describe the process they are supposed to follow. Watching gets you there. I ask for two things.

A recorded screen share of someone doing the job. An hour with the person who lives in the software, on real work, with permission to interrupt. I want the moment they hesitate, the tab they switch to, and the thing they copy and paste. Recording it means I can replay the hesitation instead of trusting my notes.

The spreadsheet. Every B2B team has one sitting beside the official system, holding the fields the system will not accept and the statuses it does not have. That spreadsheet is a specification written by the people who need the software. Read it as one.

Then I ask the question that produces the most useful answer in B2B discovery. “What happened the last time this went wrong?” People narrate exceptions in detail, because exceptions are memorable, and the exceptions are where the design work is.

The four things a workflow design has to settle

Before a screen gets drawn I want these four written down and agreed. Each is cheap to settle on a call and expensive to change once build starts.

States are the one teams underestimate. A purchase order in a distribution business is rarely just placed or delivered. It is placed, confirmed, partially picked, backordered, short shipped, invoiced, disputed and credited, and several of those can be true at once across different lines of the same order. Get the state list wrong and every screen after it inherits the mistake.

The exception path is the product

In consumer software the happy path carries most of the value. In B2B the happy path is the part that already works. Your buyer reorders, it goes through, nobody notices. The product earns its keep the day the warehouse is 40 cases short and somebody decides what the customer gets.

So I design the exceptions alongside the main path. In practice that means four things.

• Give every blocked state somewhere to go. A record that can sit with no available next action is a record that leaves the system.
• Make partial completion a first-class state. Real work stops halfway far more often than it finishes cleanly, and the interface should have a name for that.
• Show who is waiting. Most B2B delay comes down to somebody not knowing it is their turn.
• Let people override, and record it. Staff will route around a rule that blocks a legitimate case. Far better that the override happens inside the product with a name and a timestamp on it.

On a tour budgeting tool, the feature that made it usable was keeping an alternative version of a tour beside the real one, because routing changes constantly and the team had to compare before committing. That is an exception promoted to a feature, and it came from watching someone duplicate a spreadsheet tab.

What to design first

Pick the screen the busiest person opens most. In an operations team that is usually a filtered list rather than a dashboard, because the job starts with finding the right record. Get it right at real data volume, with a production export rather than twelve tidy rows, and the rest of the product has a pattern to follow. The principles behind those screens are in B2B dashboard design.

Then work outward along one complete path, from the trigger to the thing that closes it, with at least one exception on the way. One path designed all the way through reveals more about your state model than ten screens spread across the surface, and it gives engineers something to build straight away.

For timelines, one workflow designed to this depth runs three to five weeks, and a product surface with several roles runs eight to twelve. My own projects sit between $1,000 and $5,000. Where those weeks actually go is in how long MVP design takes.

When the workflow is already in software

Replacing a process that already lives in an old portal is a different job, because that system has trained everybody in it. People build habits around its quirks, and some of those workarounds turn out to be load-bearing.

The rule I use is to keep the sequence and change the effort. If invoices are approved in a particular order for a reason somebody can explain, keep the order and cut the clicks. Reorder the steps and redraw the interface in one release and nobody can tell which change caused the complaints. There is a full example in redesigning a legacy B2B portal.

Frequently asked questions

What is B2B workflow design?

It is designing the sequence of screens, states and handoffs a business process moves through, rather than designing pages. The deliverable is a state model, the roles that act on it, and an interface for every step including the ones that go wrong. Visual design sits on top and takes a fraction of the time.

How is it different from designing a consumer app?

Three ways. Your user is there because it is their job, so speed counts for everything and persuasion counts for little. Several people touch the same record, so handoffs and permissions carry real weight. And the data is large and untidy, which settles most layout questions before taste gets a look in.

How long should discovery take?

One to two weeks for a single workflow. That covers three or four recorded sessions with people who do the work, a read of whatever spreadsheet is propping up the current process, and a state model everybody has agreed to. Longer usually means the scope covers several workflows and should be split.

Do we need the whole process mapped before design starts?

One path mapped end to end, plus a list of the exceptions on it. Mapping every branch of every process first is how discovery turns into a quarter. Design the first path, build it, and let what you learn shape the next.

We already have a process document. Is that enough to start?

It is a useful input and a poor foundation. Bring it to the screen shares and mark up where the document and the recording disagree. Those gaps are the most valuable thing discovery produces, because each one is either a step the document missed or a rule people have quietly stopped following.

If you are designing one of these

I design B2B products for teams in the US, Australia and Asia, mostly the ordering systems, dashboards and internal tools staff open every day. If you have a workflow people are routing around, send me the rough shape of it and I will tell you where I would start. Have a look at how I work.