Process maps
The work as it really runs, not as the org chart suggests. We map the happy path and the awkward paths everyone quietly routes around.
What we do · Process lens
Business process design.
How the work moves before, during and after the screen. When people say "the system is broken", the software is not always the first thing to fix. Sometimes two teams simply mean different things by "submitted".
What it really is
Software only works if the workflow around it works.
Before the screens get drawn, somebody has to know who does what, in what order, and what happens when the happy path stops being happy. We map that work, redesign it where needed, and turn it into something a product team can build against.
We are not a BPM consultancy and we do not sell automation engines. BPMN is one notation we use when it earns its keep. The point is not the diagram. It is the conversation the diagram forces: who decides, what triggers the check, what happens when it fails.
When process is the problem
A process lens is useful when...
- The product touches multiple roles or departments and work keeps falling between them.
- It worked in the demo, then broke in production because nobody tested the workflow assumptions.
- 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 the as-is process exists mostly as folklore.
- Engineering is being asked to implement rules nobody has written down.
What we deliver
Artefacts that make the workflow discussable.
The aim is to move assumptions out of people's heads and into a form the room can challenge, sign off, and build from.
Role definitions
Who decides, who acts, who is informed, who can be skipped. RACI when it helps, plain English when it does not.
As-is and to-be flows
Today's reality next to the version the new product enables. Useful for change management, commercial conversations, and engineering scope.
Handoff diagrams
The moments 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.
How it connects
Process gives UX something solid to sit on.
Process is the choreography the screens have to support. UX is what the user touches. Service design is the broader experience around both. When those layers disagree, the product usually feels heavier than it should.
Sibling lens
UX design
The screens, flows and small decisions people have to live with.
You're hereBusiness process design
How the work moves behind the product.
Sibling lensService design
The broader experience: people, channels, support and follow-up around the product.
Skip the process lens and the team may still get attractive screens, but not screens that fit the work. Use it well and UX has somewhere honest to land.
Where it shows up in our process
Process work starts early, then keeps coming back.
It is heaviest in Plan and Gather, but it does not disappear. Every feature that spans multiple roles or touches a regulatory step has process hiding inside it.
Plan
What work is this product really for?
We surface the workflow assumptions baked into the brief and agree on what we are redesigning, preserving, or working around.
Gather
As-is mapping with the people who run the work.
Workshops with each role in the chain, following the work as it really moves, including the workarounds everyone has 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