User Journeys That Show How Work Actually Moves
A step-by-step map of what each role does, in what order, and what must be true before the next step — drawn before any screen exists. GullySystem maps journeys for new software and for processes already running on habit.
What a User Journey Actually Maps
A journey is not a feature list. It is the path one role takes through a piece of work, from the moment it starts to the moment it is finished, including the decisions made along the way and what happens when something does not go to plan.
- One map per role, since the same process looks different from a counter, a warehouse and a manager's desk
- Covers the ordinary path and the detours — a rejection, a return, a missing approval
- Drawn before screens exist, so the screen list comes from real steps rather than a guess
- Used for a new process and for one that already runs, mapped as it truly happens rather than as the manual says
Where Journeys Go Missing
Most software is not missing a feature. It is missing a step nobody wrote down.
The Journey Only Exists in One Person's Head
Ask three staff how an order actually moves from counter to dispatch and you get three different answers, each confident and each slightly wrong about somebody else's part.
The Happy Path Is Documented, the Detours Are Not
What happens when a payment fails halfway, when the approving manager is on leave, or when an order has to be split across two vehicles is worked out live, differently, every time it comes up.
Screens Get Built Role by Role, Not Task by Task
A job passes from a field engineer to a supervisor to accounts, and each screen was designed by looking only at its own role, so the handoff between them was never actually designed by anyone.
The Wait Between Two People Is Invisible
One person's task finishes and sits untouched until somebody else notices. Nothing in the current process shows that gap, so it survives into the new software unnoticed until launch.
There's a Journey for the Sale, Not for the Reversal
Placing an order is mapped in detail. Cancelling it, refunding it or reversing a mistaken entry is treated as an afterthought, even though it is where most support calls originate.
How We Map a Journey
A journey map is built with the people who actually do the work, not guessed at from a org chart.
One Lane per Role
Each role gets its own line through the map, so it's visible exactly where a task crosses from one person's responsibility into another's.
Decisions Marked as Decisions
Every point where the path could go two ways is drawn as a branch, with the condition that sends it one way or the other written next to it.
Exceptions Included, Not Smoothed Over
The rejected approval and the partial delivery are drawn in full, because leaving them out only pushes the problem into the screen design stage, where it costs more to fix.
Walked Through With the Person Who Does It
We take the draft back to the people interviewed and ask them to walk it, step by step, correcting anything we got wrong before it becomes the basis for a screen list.
Feeding Directly Into the Screen List
The screens that get designed next come out of the steps in the journey, so nothing is drawn that doesn't correspond to a real moment in the work.
What a Journey Map Gives You
A finished journey map is something the whole team can point at during an argument.
- A shared picture that settles disagreements about how a process is supposed to work
- A screen list grounded in real steps instead of a feature wish list written in a meeting
- The handoffs and waiting periods made visible, so they can be redesigned rather than inherited
- A place to test what happens if a step is removed or reordered, before that decision is made in code
What Shapes Journey Mapping Work
The effort scales with how many people and how much variation are involved, not with the length of the eventual screen list.
- The number of roles whose path through the work needs its own map
- How many exception paths actually matter to the business, versus how many are rare enough to design later
- Whether the current process is stable, or still changing while we're trying to map it
- Whether the journey crosses departments, which usually means more people to interview and reconcile
- Whether this is a brand-new process or the mapped reality of workarounds built up around existing software
From Journey Map to Screens
A journey map is a tool for the design stage that follows it, not an end in itself. Once roles and steps are agreed, we move into structuring the product and laying out the screens.
Frequently asked questions
Do you map the process as it currently happens, or as it should happen?
Usually both, in that order. We first map the process as it truly runs today, workarounds included, because that is what tells us where the real friction is. Once that's agreed, we draw a second version showing how it should work in the new software, and the gap between the two becomes the design brief.
What if the process is different in every branch?
That variation is worth capturing rather than averaging away. We map the version that's most common, note where and why other branches diverge, and decide with you whether the software should support one standard process or genuinely accommodate the differences.
Is a journey map the same as a technical flowchart a developer would build from?
No, and it isn't meant to replace one. A journey map describes the work from the point of view of the people doing it — what they're trying to finish and where they get stuck. A developer's flowchart describes system logic. Ours becomes the input to the screen design and, later, to specifications a developer can build from.
What drives the cost of journey mapping?
The number of roles and the number of exception paths worth including. A single-role process with one main path is a short piece of work. A process crossing four departments, each with its own exceptions, takes considerably longer to interview, draw and validate correctly.
How long does mapping a journey usually take?
Interview scheduling is usually the longest part, not the drawing itself. Getting time with people across roles and shifts, especially field staff, sets the pace more than the complexity of the map. We agree a schedule with you before starting so the timeline is based on real availability.
Can you map a journey for a process that isn't software yet — still on paper?
Yes, and it's common groundwork for a first product. Mapping a paper-based or manual process is exactly how we find out what the software needs to do before anyone writes a line of requirement, let alone a screen.
What do you need from us before journey mapping starts?
Time with two or three people per role who do the work daily, permission to ask about the exceptions and workarounds rather than only the official process, and one person who can confirm which version of a disputed step is the one that actually matters.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private