Process maps
The work as it actually runs, not as the org chart implies. We map both happy paths and the messy parts everyone routes around.
What we do · One of three lenses
Business process design.
How the work moves behind the product. Most "the system is broken" complaints aren't really system complaints. The approval chain has three exception paths nobody documented, two teams disagree on what "submitted" means, and the workflow assumptions that worked in the demo break the moment a real exception arrives. Business process design is the layer where those failures live.
What it really is
Software only works if the workflow around it works.
Before any of the screens get drawn, somebody has to know who does what, in what order, and what happens when it goes wrong. That's the work. We map it, redesign it, and turn it into something the product team can actually build against.
We're not a BPM consultancy. We don't sell you an automation engine. BPMN is one notation we use when it earns its keep. The point isn't the diagram, it's the conversation the diagram forces. By the end of it, business rules have stopped being abstract ("we always check that") and started being explicit (who decides, what triggers it, what happens when it fails).
When this is where the risk sits
You probably need a process lens when…
- The product touches multiple roles or departments and the seams keep leaking.
- "It worked in the demo, broke in production," because the workflow assumptions were never tested.
- Approval chains, regulatory steps, or exception paths are where most rework lands.
- Different sides of the business have different mental models of how the work should run.
- An old system is being replaced and "as-is" exists only as folklore.
- Engineering is being asked to implement rules nobody has written down.
What we deliver
Artefacts that make the workflow honest.
Each one of these exists to take an unwritten assumption and put it where the product team can argue with it.
Role definitions
Who decides, who executes, who's informed, who can be skipped. RACI when it earns its keep, plain English when it doesn't.
As-is and to-be flows
Today's reality next to the version the new product enables. Useful for change management, sales pitches, and engineering scope.
Handoff diagrams
The seams where work changes hands. Most failures live here, so we draw them deliberately rather than letting them happen by accident.
Decision tables
The rules behind branching paths, in a form a developer can implement and a stakeholder can sign off, without translating between them.
Exception path maps
The parts that aren't on the happy path. The rejections, the timeouts, the manual overrides. The 20 percent of paths that hold 80 percent of the risk.
Three lenses, one product
Process design holds the structure UX sits on.
The three lenses we use, UX, business process, and service design, each look at a different layer of the same product. Process is the choreography the screens have to support. UX is the screen the user touches. Service design is the broader experience around both.
Sibling lens
UX design
The product people actually use. Screens, flows, and the small details that make software feel clear or frustrating.
You're hereBusiness process design
How the work moves behind the product.
Sibling lensService design
The whole experience, end to end. The people, channels, and support around the product.
Skip the process lens and you get pretty screens that don't fit how anyone actually works. Use it well and the UX and service work each have somewhere honest to land. We use whichever lens the risk asks for, and most engagements end up needing all three.
Where it shows up in our process
Process work concentrates early, then re-surfaces.
Our five-phase process is shared across all three lenses. Process design lives heaviest in Plan and Gather, and shows up again whenever a feature spans multiple roles or touches a regulatory step.
Plan
What process is this product really for?
We surface the workflow assumptions baked into the brief, and agree on the boundary of what we're redesigning vs working around.
Gather
As-is mapping with the people who run it.
Workshops with each role on the chain, walking the work the way it actually moves, including the workarounds everyone has quietly normalised.
Ideation
To-be flows, multiple directions.
We test alternative process shapes against the same business goals, then narrow once the trade-offs are visible.
Build
Process feeds the prototype.
The to-be flow tells the prototype what's possible, what's blocked, and what an exception looks like. The screens follow the workflow, not the other way around.
Test
End-to-end runs with real roles.
We test the workflow with the people who'll live in it, not just individual screens. The handoffs are usually where reality bites.
When a workflow assumption breaks during Test, we loop back through Gather. That loop is cheaper than discovering the same break after launch.
Building a product that has to fit a workflow?
Tell us about the process the product has to live in. We'll help you map it, redesign it, and make sure the screens follow.
Talk to us