Start with one person and one goal
A user journey map is a picture of the steps someone takes to reach a goal with a product or service. It includes more than the screens they tap: expectations, decisions, delays, and help from other people can all shape the experience. For a smart thermostat, the goal might be to set a comfortable overnight temperature, not simply to finish the setup wizard.
Before drawing anything, define whose journey you are mapping and where it begins and ends. A first-time owner connecting a thermostat to home Wi-Fi may face different obstacles from an experienced owner changing a schedule. If you combine both into one map, important differences can disappear. Choose a specific situation and state the user’s goal in ordinary language: “I want the house to be warm when I wake up without adjusting it every morning.”
Set boundaries that match the decision you need to make. If you are improving onboarding, follow the person from opening the box through their first successful use. If you are improving daily controls, begin when they notice a problem and end when they know it is resolved. A focused map is easier to act on than a diagram of every possible interaction.
Lay out actions, expectations, and touchpoints
Create a simple sequence of stages, such as discover, choose, set up, use, and get help. Under each stage, write what the person does and what they expect to happen. Then add the touchpoints they encounter: packaging, a device display, an app, an email, a support article, or another person. A paper table or shared document is enough; specialized software is optional.
Keep actions separate from interpretations. “User enters the Wi-Fi password twice” describes an action. “User is confused” is an interpretation that needs support. If you have observations from a test or customer feedback, note where they fit. If you do not, label assumptions clearly and plan to check them rather than presenting a plausible story as a fact.
Include moments outside the product interface. Someone may need to find a router password, ask a housemate for permission to change a shared setting, or wait to see whether a schedule works. These details can reveal why an apparently simple task feels difficult in real life.
Look for friction at transitions
Friction is anything that makes progress slower, less clear, or less trustworthy than it needs to be. It can be a long form, an unfamiliar term, a button that is hard to find, or a missing confirmation. It can also be a mismatch between what a person expects and what the product actually does. Friction is not always a flaw: a pause before deleting a schedule may prevent an unwanted action.
Review the map one step at a time. Where must the person stop and guess? Where do they repeat an action, switch devices, wait without an explanation, or seek help? Pay special attention to transitions, such as moving from printed instructions to an app or from an app command to a physical device response. Each transition can introduce a new question: Did my action go through, and what happens next?
Write each potential friction point as a specific observation or testable question. “The screen says connected, but the device still shows setup mode” is more useful than “setup is bad.” Specific wording helps a team investigate the cause without jumping straight to a favored fix.
Prioritize the problems worth solving
Not every rough edge deserves the same attention. Consider how strongly a problem blocks the user’s goal, how often it might occur, and whether it leaves the person able to recover. A slightly awkward label may be less urgent than a setup failure with no clear next step. When you do not yet know frequency or impact, mark those judgments as uncertain.
Separate the symptom from its possible causes. If people abandon setup when asked for location access, the answer is not automatically to remove that step. They may need a clearer explanation, a different point at which to ask, or a way to continue with limited features. List a few plausible causes and check them with users or product behavior before choosing a change.
For each priority, propose a small improvement tied to the journey: clearer instructions, a more visible status indicator, or a recovery path after an error. Describe what the user should be able to do afterward. That makes it easier to judge whether the change improves the experience rather than merely making a screen look cleaner.
Use the map as a working tool
A journey map is most useful when people can revise it. Walk through the experience yourself, observe a few people attempting the same goal if possible, and compare what happens with the map. Ask what they expected at uncertain moments without assuming that their first suggestion is the only solution. Update the steps and friction points when new evidence changes your understanding.
Keep the map readable enough for designers, engineers, support teams, and others to discuss together. It should show the user’s goal, the sequence of actions, the most important uncertainties, and the opportunities to improve. It does not need decorative detail to be valuable.
After making a change, revisit the journey rather than checking only the altered screen. A shorter setup flow may create confusion later if it skips a useful explanation. The aim is not to remove every pause; it is to help people move toward their goal with clear choices, useful feedback, and a reasonable way forward when something goes wrong.
