Customer Journey Mapping: How to Validate a Business Idea
Map the experience around your digital product, separate evidence from assumptions, and turn customer journey insights into practical design decisions.
Soulsy Editorial Team · · 8 min
What is a user journey, and why map it before building?
A user journey is the sequence of actions, decisions, and interactions someone goes through to achieve a goal in a particular context. It starts before the first screen and may continue after payment, delivery, or product use.
To map one, choose a person and situation, investigate how they solve the problem today, organize the stages, and attach evidence to the barriers you identify. During product design, that map helps determine which parts of the experience need software, human support, operational changes, or further research.
If you are asking how to validate a business idea, journey mapping offers a specific contribution: it reveals where your proposed experience depends on untested assumptions. It does not, by itself, prove demand or commercial viability.
User journey, customer journey, and user flow
These terms overlap, but they answer different questions:
- User journey: How does someone carry out an activity and reach the intended outcome?
- Customer journey: How does someone discover, evaluate, buy, use, and maintain a relationship with an offering?
- User flow: What steps and interface states support a particular interaction?
- Service blueprint: How do people, systems, and internal processes support the visible experience?
For business software, the buyer may not be the user. Combining them into one imaginary person can hide approvals, onboarding responsibilities, and dependencies on other teams.
Nielsen Norman Group's Journey Mapping 101 defines a journey map around the process someone follows to accomplish a goal. Its Service Blueprints: Definition explains the relationships between customer touchpoints and supporting activities. These sources support the distinctions above, not a claim that making a diagram validates a business.
What journey mapping contributes to business idea validation
A business idea contains several kinds of uncertainty. The problem might matter but occur infrequently. The user might want help but lack purchasing authority. A convenient interface might require more operational effort than the offer can support.
A journey places those uncertainties in concrete situations. Instead of asking, “Would you use this?”, customer discovery can examine a recent episode: what triggered it, which alternative was used, who participated, and what prevented completion.
This connects the proposed offering to actual behavior. However, evidence that a problem exists is not evidence that someone will pay your price. Likewise, completing a prototype task does not establish that delivery will be profitable.
Problem evidence, usability evidence, and commercial evidence answer different questions. A useful journey map keeps those distinctions visible rather than compressing them into a single “validated” label.
A practical framework for mapping the journey
1. Define the person, situation, and outcome
Start with a sentence: “When this situation occurs, this person needs to achieve this outcome despite these constraints.”
Avoid defining the person only by job title or demographic characteristics. People with the same title can have different authority, resources, and reasons for acting.
Set boundaries for the journey. The beginning might be recognizing a need; the end might be confirming that the intended result actually happened. Stopping at payment hides the delivery experience.
If the buyer and user differ, create separate maps and connect the points where information or responsibility passes between them. You do not need a complete map of every stakeholder to investigate one consequential handoff.
2. Investigate the current experience
Before designing a future journey, understand the existing one. Include email, spreadsheets, phone calls, competitors, workarounds, and the option of doing nothing.
Ask people to reconstruct recent situations. With appropriate permission, observe tasks and review materials that clarify the process. Keep identifiable information out of broadly shared maps and collect only what the research requires.
Separate observation from self-report. Watching someone struggle to locate information is different from hearing that they usually struggle. Both can inform design, but they support different conclusions.
The purpose is not to collect enough anecdotes to defend a preferred feature. It is to find where the team's explanation of the problem may be incomplete.
3. Organize stages around goals, not pages
Useful stages might include recognizing a need, comparing alternatives, obtaining approval, getting started, handling a problem, and confirming the outcome.
For each stage, capture the following:
| Field | Practical question |
|---|---|
| Goal | What must the person achieve here? |
| Action | What do they currently do? |
| Touchpoint | Which channel, person, or system is involved? |
| Barrier | What prevents progress? |
| Evidence | What observation or report supports this? |
| Owner | Who is responsible for this part of the experience? |
You can include emotions when there is a basis for describing them. An invented frustration curve adds visual certainty without adding knowledge. Mark uncertainty instead of decorating it.
4. Separate facts, interpretations, and assumptions
A journey map easily blends what the team knows with what it merely believes. To pull them apart, use a CSD matrix — Certainties, Suppositions, and Doubts. The tool comes from Brazilian design practice and is described by Nielsen Norman Group as a simple way to align a team's knowledge at the start of a project and turn it into research questions.
How it works: draw three columns and gather the people involved in the product.
| Column | What goes in | Journey example |
|---|---|---|
| Certainties | Facts backed by evidence: something observed, a usage record, consistent accounts from several people | “Groups book rooms about a week ahead” — from booking records |
| Suppositions | Interpretations and hypotheses that feel true but have not been verified | “The person who books is also the person who pays” |
| Doubts | Questions nobody can answer yet that could change the journey | “What does the person do when no room is available?” |
Step by step:
- Write individually. Each person notes what they know, suppose, and don't know about the audience and situation, one idea per note. This keeps the loudest voice from shaping the group.
- Challenge the certainties. For each item, ask “how do we know this?”. If the answer is “we think so” or “it's always been like that,” the note moves to suppositions. A single observation is not a certainty either: it shows a possible problem, not how often it happens.
- Prioritize by risk. Rank suppositions and doubts by the cost of being wrong. An assumption about who approves the purchase deserves research before a doubt about screen layout.
- Turn them into research questions. Priority suppositions and doubts become the script for the interviews, observations, and tests that follow.
- Revisit after research. Confirmed suppositions become certainties, refuted ones leave the map, and new doubts may appear. The matrix is a living document.
On the journey map, tag each stage with the column its information comes from. Anyone can then see which parts of the experience rest on evidence and which are still bets.
A map becomes valuable when it lets the team challenge a conclusion, not just agree with it.
5. Design the future journey and its supporting operation
Now propose how the experience could work. For every stage, describe both the visible response and the capability needed to deliver it.
If the product promises live availability, what maintains that information? If it promises help, who provides it? If a request fails, how does the person find out and recover?
A service blueprint complements the journey here by exposing operational dependencies, including manual work during a pilot.
Do not automate everything by default. Human intervention may be appropriate early on, provided someone owns it and its capacity and cost are considered. Conversely, calling a task “manual for now” does not remove the obligation to deliver it reliably.
6. Turn the map into testable decisions
Connect each consequential uncertainty to a question, a test, and a possible decision.
A prototype can investigate whether people understand a purchase condition. An assisted simulation can explore a handoff. A real offer can investigate commercial interest, provided its limitations and delivery commitments are represented honestly.
Decide in advance what evidence would lead you to keep, change, or stop the proposal. There is no universal pass threshold: criteria should reflect the decision's risk, context, and evidence quality.
This is a practical way to validate before building. The backlog follows decisions about risk and value, rather than automatically turning every map entry into a feature.
Want help mapping or planning your product's journey? At Soulsy, this is one of Sol's responsibilities as the design specialist: she works with you on the CSD matrix, the journey map, and the move to flows and prototypes, building on what was defined in discovery. Create your account and start
Fictional example: booking rehearsal rooms
The following example was invented solely to illustrate the method. It is not a Soulsy customer case, research finding, or reported result.
Imagine a fictional community arts center that rents rehearsal rooms by the hour. A volunteer coordinator needs to find a room suitable for a group's instruments and confirm access before asking everyone to attend.
An initial product concept might include a calendar, account creation, and payment. A proposed journey also considers comparing room conditions, checking equipment, sharing entry instructions, and handling a door that will not open.
These are assumptions within the example, not findings from interviews.
The team could test whether the coordinator can choose a suitable room using compatibility information. It would also need to simulate receiving access instructions and establish who provides support during the booking.
If the operation cannot guarantee access, making checkout easier does not solve the experience. A reasonable design option might be to offer only supported time slots while investigating a sustainable support model.
The map connects the interface to both the commercial promise and the ability to deliver it.
Common mistakes that weaken a journey map
Mapping only the happy path. Include interruptions, uncertainty, cancellations, and recovery. You need not document every edge case, but consequential failures deserve attention.
Treating desired outcomes as evidence. “The customer sees the value” describes an ambition. Define how that value would become apparent in the person's activity.
Turning every barrier into a feature. Some barriers require clearer information, a policy change, or support rather than another screen.
Combining incompatible contexts. An average journey may represent nobody when authority, experience, and constraints vary substantially.
Leaving handoffs without owners. A transition between software and operations is easy to overlook when neither team is explicitly responsible for it.
What to ask a product design partner
If you are comparing consultants or product teams, do not compare only screen counts. Ask how their work will investigate uncertainty and which decisions each deliverable should support.
A journey-focused engagement might include audience definition, current-experience research, an evidence register, a future journey, operational dependencies, and testing of critical interactions. The scope should explain participant access, responsibilities, and research limitations.
An internal workshop can align assumptions, but it cannot replace relevant customer contact or establish commercial demand. Be cautious about a proposal that promises to validate the business through workshops alone.
Choose the engagement around your next consequential decision, not around the largest possible package of design artifacts.
An action plan for getting started
- Select a concrete situation and the person responsible for its outcome.
- Record what the team knows and what it merely assumes.
- Investigate recent episodes and current alternatives.
- Build a map with identifiable evidence and gaps.
- Choose the uncertainty with the greatest consequence for investment.
- Test the relevant part of the journey and record the resulting decision.
Update the map when new evidence changes your understanding. Its purpose is to support decisions, not to look finished while the underlying experience remains uncertain.
FAQ
When should I map a user journey?
Map it when you need to understand an experience before choosing a solution, or when an existing product has problems between stages. During design, begin before committing to a detailed screen flow.
Can I create a map before conducting research?
Yes. An assumption-based map can organize research questions. Label it as provisional and avoid presenting internal expectations as established customer behavior.
Does journey mapping replace prototyping?
No. A journey map explains context and connections across an experience. A prototype helps investigate specific interactions. The map helps determine what the prototype should test.
Can a customer journey map validate a business idea?
It can reveal assumptions and organize relevant tests, but the map itself is not proof. Demand, usability, delivery capability, and economics require evidence appropriate to each question.
Sources and limitations
Journey Mapping 101, from Nielsen Norman Group, supports the definition and core components of a journey map.
Service Blueprints: Definition, also from Nielsen Norman Group, supports connecting the visible experience to supporting processes.
CSD Matrix, from Nielsen Norman Group, supports using a Certainties, Suppositions, and Doubts matrix to align what a team knows before research.
From journey map to the next decision
A useful journey map makes the relationship between need, interaction, and delivery visible. Its value emerges when a team stops debating isolated features and starts making decisions with explicit evidence and ownership.
If you understand a real problem and want to structure the experience before investing in development, create your Soulsy account and let the specialists guide you — from discovery with Luna to the journey with Sol.