Large journeys rarely need a complete redesign. They need a clear view of where the friction comes from and which changes can be delivered safely.
I use the existing journey as evidence rather than treating it as something to erase.
Map more than screens
I start with the customer steps, then add the decisions, systems, teams, and controls behind them. This turns a screen flow into a simple service map.
Each step is marked with what it needs, who owns it, and what happens when it fails. I also separate known facts from assumptions that still need evidence.
This often reveals that two similar screens exist for different technical reasons, or that a customer question is only there to support a manual process later.
Classify the friction
I group issues into a few useful types.
- Customer confusion
- Repeated or unnecessary input
- Policy or control requirements
- System dependencies
- Operational workarounds
That prevents the team from treating every problem as a user-interface fix. Some need clearer content. Some need a service change. Others need technology or policy owners involved.
Slice the change
We prioritise work that improves the journey without depending on a full platform replacement. This might include reordering questions, reusing verified information, improving recovery states, or replacing a local pattern with a shared component.
I show the target journey alongside the first deliverable slice. Engineering can see what changes now and what remains connected to future work.
The result is a sequence the team can build, test, and learn from. Simplification becomes deliverable work, not a perfect future diagram.