AI Ready
User Journey card, MethodKit for AI Readiness
Card 44 of 48 · MethodKit for AI Readiness
  • ThemePut to Use
  • CardCard 44 of 48
  • Questions5 to explore
Put to Use

User Journey

How the user uses the solution, from start to finish

The user journey is the step-by-step path a real person takes through your solution, from the moment they need it to the moment they are done.

Most solutions are designed from the inside out: here is the thing we built, figure out how to use it. The user journey design goes the other way. You start with a real person, a real moment when they need help, and you trace exactly what they do. Each step should be something you can observe, not an assumption about what users probably do.

For AI-assisted solutions, the journey often has a seam: the point where AI takes over from the user and the point where the user takes back control. Mapping that seam clearly is one of the most useful things a journey does. It tells you where trust needs to be built and where a human review step belongs.

A journey does not have to be a diagram. A numbered list of six to ten steps, written in plain language, is usually enough for a first solution. The goal is to catch the gaps before you build into them.

Make it visiblePick one real person who would use this solution and walk through the journey with them out loud, step by step. Write down the actual steps they describe, not the steps you intended. Note any step where they pause or say they are not sure.

Why AI needs this

Each part of your work matters to AI in a specific way. Some of it is context a tool needs before it can help, some of it is work a tool can take on, and some of it is judgment that should stay with you.

Handover clarity

AI needs to know exactly when to act and what to do. The journey makes the human-to-AI handover explicit, so nothing falls into a gap between steps.

Finding the stuck points

Steps that are hard to describe in plain language are usually steps that are also hard to automate. The journey surfaces these early, before you have built around them.

A test script in disguise

Once the journey is written, you have a ready-made way to check whether the solution actually works: walk through it step by step with a real user and see where it breaks.

Scope as a side effect

Mapping the full journey often reveals steps that do not need to be in the first version. Cutting them early keeps the solution small enough to ship.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

  1. What triggers a person to reach for this solution in the first place?

  2. Where in the journey does the user hand off to AI, and where do they pick the work back up?

  3. Which step in the journey are you least sure about, and have you actually watched someone do it?

  4. What happens if a step fails or produces something unexpected: where does the user go?

  5. Is there anything in the journey that currently requires access a user or AI does not have?

Readiness traps

  • Journeys written without watching a real user almost always skip the friction steps, the ones that matter most for whether the solution gets used.
  • A journey that treats AI as a black box in the middle has a gap where quality control should be: map the review step explicitly or it will not happen.
  • Happy-path journeys show only the ideal case. If you have not mapped what happens when something goes wrong, the first real user will find the gap for you.