User Journey Mapping Workshop: Find Friction Before Redesigning Screens

A journey map is useful when it describes what actually happens, not when it is a poster of what a team hopes customers do. In many redesign projects, the visible screen is only one part of the issue. A prospect may understand the offer but not trust the next step. A customer may submit a request but receive no useful follow-up. A staff member may copy the same information between a form, spreadsheet, CRM, and WhatsApp chat before the request becomes actionable.

A journey-mapping workshop helps a team decide where the experience is breaking and which part of the operating system should change first. It should answer where the journey starts, who owns each transition, what a person is trying to achieve, what information or reassurance they need, which systems are involved, and how the business knows the outcome happened. The output is not a general diagram. It is a prioritised improvement plan.

Start with one high-value path such as requesting a consultation, booking an appointment, onboarding a new user, approving an internal request, or resolving a service issue. Invite the people who see different parts of that path: sales, support, operations, product, design, technology, and where possible a real customer perspective. Map the trigger, actions, channels, emotions, questions, records created, rules, handoffs, and failure states. Then highlight the moments where a person has to wait, repeat information, guess what happens next, or contact support.

A lead journey is rarely contained in a website. The visitor may arrive through search, an ad, a referral, or a WhatsApp conversation; the enquiry may land in email, a CRM, a calendar, or a spreadsheet; and the next step may depend on working hours, team capacity, or qualification rules. Put those transitions into the map. The right improvement may be content clarity, a different form sequence, a service-level agreement, a routing rule, or an automation rather than a new page design.

1. Choose one user, one meaningful task, and one outcome for the first map.
2. Collect live evidence: analytics, enquiries, support issues, handoff notes, and example records.
3. Map the current trigger, steps, channels, systems, owners, and exception paths.
4. Mark friction by user impact, operational cost, and evidence strength.
5. Agree the next three to five changes and identify what requires more validation.

Turn the workshop into a future-state journey with no more detail than the team can own. Name the critical moments, the intended user outcome, the business owner, the supporting system, the risk, and the measurement. Then separate near-term fixes from work that needs research, technical discovery, or a broader product decision.

• Current-state journey map with evidence and ownership
• Friction and handoff log ranked by impact
• Future-state journey and operating assumptions
• Prioritised backlog with measurement and decision owners

Common risks include mapping an idealised process, allowing the loudest stakeholder to speak for users, missing offline or post-submission work, failing to include a responsible owner, and producing too many opportunities to prioritise. Avoid these by grounding each step in evidence and by ending the workshop with a short list of accepted actions, not a long collection of observations.