Every system your organisation builds starts life as a set of assumptions about who will use it, and how. Most of those assumptions are sensible, and plenty of them turn out to be right. The ones that cause trouble were written into requirements before anyone sat down with the people doing the work, and nobody went back to check them.
When a new platform goes live and adoption stalls, the first explanations on the table are usually training and resistance to change. Sometimes that diagnosis is fair. Before you book another round of training, though, it’s worth ruling out a simpler possibility. The system may do exactly what the specification asked for, and the specification may describe a process that nobody follows.
Where Assumptions Come From.
Every engagement works through ten assurance domains, because your AI product’s readiness is never a single-iAssumptions get into a project early. The business case describes the process as leadership understands it, and requirements discovery tends to rely on whoever was easiest to get time with, which usually means managers rather than the people who capture the orders or process the claims each day. By the time the backlog is written, every user story has inherited whatever was missed further up.
Nobody along that chain has done anything wrong, and each decision was reasonable with what people knew at the time. Leadership just rarely gets to see the gap between how a process is meant to work and how it actually runs on a busy afternoon with a queue building up. When that gap does show itself, it’s usually after launch, and it arrives as change requests and rework.
What User Journey Mapping Makes Visible.
User journey mapping follows one person through one real piece of work, from the moment the task lands to the moment it’s done. Alongside as-is and to-be process mapping, it records the hand-offs between people and teams, the systems the work passes through and the places where it stalls or gets sent back. You end up with a picture of how work happens now and how it should happen once the new solution is live, and your stakeholders can agree on that picture because they helped draw it.
It isn’t always a comfortable exercise. Some of what it shows will contradict a business case that has already been signed off, and someone has to be willing to say so out loud. That conversation costs far less before build than after it. Changing a journey map takes an afternoon with the right people in the room, while changing the same decision after go-live can mean going back into design and development while your users wait.
The Friction That Tends to Surface.
The first thing a journey map usually turns up is a set of manual workarounds. Someone keeps a spreadsheet open next to the official tool because the tool doesn’t hold a field they need, and someone else re-keys the same reference number into two different systems. Every one of these is a requirement that never made it onto paper.
Shadow processes sit a layer deeper. They’re the informal routes people use when the formal process is too slow, like an approval handled over email or a WhatsApp group that tells the next team a job is ready. They work well enough for the people using them, and they don’t appear in any process document. If you design a new system around the documented process alone, you’ll switch off the shadow process without replacing what it was doing.
Mismatched mental models between departments are the hardest to spot from outside. Finance and operations can use the same word for different things, or open the same customer record for completely different reasons. If each team describes its needs separately, the requirements line up on paper and then collide during user acceptance testing (an expensive place to find out). The same happens with integrations, where each team assumes another system holds the data it needs and nobody has mapped where it really lives. Mapping the journey end to end puts both views on the same wall while there’s still time to reconcile them.
Clarity Before You Commit Budget.
If you have a defined product, platform or modernisation challenge, Discovery & Strategy is where we would start with you. It’s a paid front-door engagement that helps you create clarity before committing to build. User journeys and process design sit at the centre of it, next to architecture direction, a prioritised backlog and a roadmap for the first delivery wave.
What you get out of it is evidence. Your delivery team builds against requirements that have been tested with the people who will use the system, and your leadership team signs off the investment knowing far more about scope and risk than a business case on its own can tell them. We work alongside your subject matter experts and technical teams throughout, so the understanding stays in your organisation after we’ve finished. When you’re ready to build, that same evidence becomes the starting point for delivery, and we take it into Build & Transform with you.
Test Your Assumptions Before You Build.
If you’re scoping a build, platform or modernisation initiative, write down the assumptions your plan depends on and ask who has checked each one with the people doing the work. If the answer is nobody, book a Discovery & Strategy consultation with us and we will work through them with you.Â
