This entire set of notes revolves around one sentence:How to map out, make sense of, and improve "the entire process of a real person interacting with your product or service across multiple days and multiple channels to achieve a certain goal". The key phrase is "across time, across channels, see the whole journey" — this is not the same as "which steps a user clicks inside a single interface (User Flow)", nor is it the same as "which internal department does what (Service Blueprint)".
The full text is divided into eight sections along a chain that goes "from the surface to the core":
① The journey map itself(What a Journey Map is, its five elements, how to read problems from it) → ② A whole table of mapping methods(Journey maps are only one type; how they divide work with experience maps/empathy maps/service blueprints/ecosystem maps/process maps) → ③ Journey vs Flow vs Story Map(The three groups most often confused) → ④ Service Design and Service Blueprints(Shifting the lens to inside the enterprise) → ⑤ How to actually run a journey project(As-is/To-be, assumption/research, fidelity, interactive maps, empirical survey evidence) → ⑥ Scaling to the organizational level(CX transformation, journey-centric design) → ⑦ Research foundations(CUEs observation framework, user panels) → ⑧ Three practical journey cases(Luxury, healthcare, AI image generation) + narrative techniques.
One-sentence core principle:Journey maps answer "which segment of life/experience the problem occurs in", process maps answer "which step on which interface the problem occurs at", and service blueprints answer "where our internal handoffs broke". All three layered together give the full picture.
I. The Journey Map Itself: Five Elements + Three-Section Structure + Seven Analysis Methods
Definition of a Journey Map: A visualization tool laid out along "the timeline of user actions", overlaid with the user's thoughts and emotions to form a complete narrative. Terminology note: "user journey map" and "customer journey map" are interchangeable; both refer to "a visualized process of a user using a product/service".
Three-section structure (top to bottom):
| Position | What to place there |
|---|---|
| Top | The specific user (who) + scenario + expectations/goals (why they came) |
| Middle | High-level "phases" composed of user actions, thoughts, and emotions (the main body of the process; emotions drawn as a curve) |
| Bottom | Key insights, opportunities, internal responsibility assignments (so what we need to do, and who does it) |
Five core elements(Required regardless of format):
| # | Element | What it is | Core principle |
|---|---|---|---|
| 1 | Actor | Whose perspective the journey is viewed from | One map depicts only one perspective. Align with Personas and ground in data. A university must map separate journeys for students and staff, not mix them |
| 2 | Scenario + Expectations | What situation this map addresses, what expectations the user arrives with | Suitable for "chains of events" (shopping/travel) or multi-channel interactions |
| 3 | Journey Phases | High-level major segments that form the skeleton for other information | Buying a speaker on e-commerce = Discover → Try → Purchase → Use → Seek support; buying a luxury car = Exposure → Educate → Research → Evaluate → Decide |
| 4 | Actions / Mindsets / Emotions | Actions = what the user actually did; Mindsets = thoughts, questions, motivations (ideally use verbatim user quotes from research); Emotions = the high-low curve of mood | The emotion curve is the main battlefield for later "pain point identification" |
| 5 | Opportunities | Optimization insights distilled from the map | Three questions: How do we use this knowledge? Who is responsible for the improvement? How do we measure the effect? |
Core principle: The value of a journey map is not in "being beautifully drawn", but in "it forces the team to string the whole journey together from the user's perspective, then translate findings at the bottom into who should do what".
Seven methods for analyzing a journey map(NNGroup uses car-buying user Eric's journey on yournextcar.com as a running example throughout):
| # | Analysis angle | What you are looking for | Eric example | How to fix it |
|---|---|---|---|---|
| 1 | Unmet expectations | Places where the actual experience falls below the expectations the user brought (even if they don't explicitly state dissatisfaction) | Saw a TV ad expecting detailed car condition info on the website, which was missing → friction right at the start of the journey | Align promotions with actual features, do not mislead |
| 2 | Redundant touchpoints/steps | Unnecessary links that add burden | Refreshed the website repeatedly every day to see new cars → anxiety + time cost | Send automatic notifications for new cars, don't make people monitor manually |
| 3 | Emotional lows | The "valleys" of the emotion curve = priority pain points to optimize | The comparison and test-drive stage was the lowest point (manually organizing car info, planning routes) | Provide better comparison tools and test-drive itinerary planning |
| 4 | High-friction channel switch points | Information loss or process breaks when switching devices/channels | Switched to the App and found missing features → disappointed and abandoned | Consistent features across channels, seamless cross-channel experience |
| 5 | Time consumption | Which step takes so long that there is risk of abandonment | The comparison stage dragged on for1 month(manual comparison in Excel) | Simplify comparison with smart recommendations + filters |
| 6 | Moment of Truth | A single point that significantly determines overall success or failure | Abandoned the App early → missed the "new car notification" feature that could have eliminated the biggest pain point | Highlight key feature value, guide correct usage |
| 7 | Highs / Exceeds expectations | Don't only focus on problems; also find already successful bright spots | Two points in the journey where useful features were found and mood rose | Reinforce their presentation, replicate them in other stages |
Why look for highs at the same time: Only fixing lows will make a product "not hard to use but also unmemorable". Lows identify what to fix, highs identify what to amplify, time consumption reveals efficiency opportunities, Moments of Truth find turning points — these four dimensions combined form a complete diagnosis.
II. A Whole Table of Mapping Methods: Journey Maps Are Only One (UX Mapping Landscape)
Empathy maps, user journey maps, experience maps, and service blueprints are the four most common UX mapping tools; they have different goals and scenarios but all serve to "build shared team understanding".
| Method | Perspective | Tied to a specific product? | Structure/Columns | When to use | Primary purpose |
|---|---|---|---|---|---|
| Empathy Map | Psychology of a single user type | No (not time-based) | Four quadrants: Says / Thinks / Feels / Does | Early design stage, when organizing interview notes | Build empathy, reach consensus on "who the user is" |
| User Journey Map | User perspective (time-based) | Yes, for a specific product/service | Phases/Actions/Thoughts/Emotions | Any stage, as a team reference point | Identify pain points/bright spots at key touchpoints, build cross-department consensus |
| Experience Map | General "ordinary person" perspective (time-based) | No, product-agnostic | Phases/Actions/Thoughts/Emotions | Before drawing journey maps, to first understand general behavior | Establish a "product-agnostic" experience baseline |
| Service Blueprint | Organization/employee perspective (time-based + layered) | Yes, for a specific service | Customer Actions/Frontstage/Backstage/Support Processes | After journey maps, before organizational change | Optimize cross-department collaboration, identify weak service links |
Classic distinction between Experience Maps and Journey Maps: Before ride-hailing emerged, you could first draw an experience map of "commuting" (walking/cycling/riding all count), identify pain points (unpredictable time, single payment method), then draw a journey map for a specific product (such as Lyft) based on that.Experience Map = industry baseline, Journey Map = specific to your own product.
Why map in the Discovery stage + three discovery-stage methods: Mapping helps you in the earliest project phase to ① manage complexity (break big problems into smaller ones, highlight key actors and causality) ② enhance memory (images are easier to remember than text, the "picture superiority effect") ③ create alignment ④ reveal information gaps (questions like "we don't know about this part" will emerge during drawing). Three commonly used diagrams in the discovery stage:
| Method | What it is | When to use |
|---|---|---|
| Ecosystem Map | Place the user at the center, draw all people/organizations/products/services they might interact with | When facing unfamiliar domains, initial discovery period (e.g. agents/banks/lawyers around "family home buying") |
| Chronological Map | Experiences unfolding over time (experience maps, service blueprints, and journey maps all fall into this category) | Want to understand "how the user's experience changes over time" |
| Process Map | Break down how a process operates (can be a user process or a business process) | Need to dig deep into the details of a specific process |
Core mindset: These methods are not a single-choice question; they exist at different levels of abstraction,to be flexibly combined. Before starting any mapping, make three decisions first (see Section 5). The "process value" of mapping (alignment during team discussions) is often greater than the "outcome value" (the map itself).
III. The Three Most Easily Confused Groups: Journey vs Process vs Story Map
This is the terminology pitfall that product managers most often step into. All three describe "the user's interactions with a product to achieve a goal"; the only differences lie in how broad the scope is, how long the time frame is, how granular the detail is, and from whose perspective.
User Journey vs User Flow:
| Dimension | User Journey | User Flow |
|---|---|---|
| Scope and channels | Spans multiple channels | Inside a single product |
| Time span | Long cycle (weeks to months) | Short-term, immediate goals |
| What is captured | Behaviors + thoughts + emotions | Sequential operation steps (key actions + system responses), no emotions included |
| Perspective / level | Macro: broad and high-level (e.g., the entire process of "becoming a new patient at a clinic") | Micro: concrete and detailed (e.g., "registering on the website to receive reminders") |
| Output artifact | Journey map | Wireflow / process map / task diagram |
| Best research methods | Context Methods (field research, diary studies) + user interviews | Usability testing (direct observation of operations); heatmaps etc. as secondary supplements |
Classic example: A parent "finding a kindergarten for their child" = one user journey (viewing the official website → calling to book an appointment → repeated email exchanges → on-site visit → filling out an online form, cross-platform, lasting weeks to months); within this, the step "submitting a form on the parent portal" itself is suitable to be broken down with a user flow.A journey tells you which segment of life the problem is in; a flow tells you which interface and which step the problem is at. Combining the two prevents you from getting lost in details or talking about experience in empty abstractions. In reality, most teams lack a systematic process to connect these two perspectives (gaps in team structure, lack of an overall measurement plan, lack of capability).
Which to choose: If you want to ask "Is the overall experience smooth? Are there breaks across multiple systems?" → User Journey; if you want to ask "Why can't users get through this feature? Which step is most error-prone?" → User Flow.
User Story Map(The third artifact, popularized by Jeff Patton, belonging to Lean UX): Using sticky notes / sketches,from the product perspective map out the interactions users complete to achieve goals in a digital product, replacing lengthy waterfall-style requirement documents. It has a three-layer structure:
| Layer | What it is | Example for a banking app "depositing a check" | Visualization |
|---|---|---|---|
| Activities | The user's core tasks in the product (top level, no more than a few) | View balance, deposit check | Arranged horizontally at the top, same-color sticky notes |
| Steps | Subtasks to complete an activity (in order) | Enter deposit information → take photo of check → submit → confirm | Below the activities, different-color sticky notes |
| Details | The finest-grained interactions for executing each step | Enter username when logging in, enter password | Use yet another color |
How to use it for planning: Draw a Release Line on the map — items above the line go into the current release (e.g., build a prototype to verify "can users understand the process and successfully deposit a check"), items below go into future iterations. Steps → Epics in the Agile backlog; Details → split into user stories and tasks with acceptance criteria. Advantages: easy to adjust (changing sticky notes is more flexible than changing documents/code), promotes collaboration, maintains user-centricity, improves visibility and priority discussions. It can also expose high-risk areas(sticky notes that turn users off or take too long to develop), so you can experiment with simpler alternatives before investing.
Relationship between Story Maps and Journey Maps(The three can evolve into each other):
| Comparison | Customer Journey Map | User Story Map |
|---|---|---|
| Perspective | User perspective (emotions / channels / devices) | Product perspective (features / steps / priorities) |
| Use case | Output of exploratory research, understanding pain points | Development planning, replacing requirement documents, feature prioritization |
| Stage | Early exploration | Product development / Agile iteration |
Bidirectional evolution: "User logs into account" in a journey map can be broken down into specific product operations (enter username → password → click login) → becoming a story map; conversely, if a step in a story map is found to frequently confuse users, adding emotion/device/channel information → becoming a journey map.Journey maps show marketing/customer service the overall experience; story maps show engineering/product the development roadmap; combining them enables more effective cross-functional communication.
IV. Service Design and Service Blueprints: Turning the Lens to the Inside of the Enterprise
Definition of Service Design: The activity of planning and organizing an enterprise's resources (people, tools, processes), with the goals of ① directly improving employee experience ② indirectly improving customer experience. First proposed by Lynn Shostack in 1982. Three components =People(employees / customers / people indirectly affected) +Tools(physical venues / digital environments / physical or digital products) +Processes(workflows / procedures, such as withdrawing money, contacting customer service).
An easily confused pair of terms:
| Concept | Focus | Core question | Restaurant example |
|---|---|---|---|
| User Experience (UX) | External touchpoints | "What did the user encounter?" | The entire process from the customer finding the customer service chat entry to interacting with customer service |
| Service Design | How the experience is created internally | "How are these experiences created?" | Customer service backend checking databases, recording, changing configurations, etc.; how the kitchen passes "allergy information" to the chef |
Why UX alone is not enough: Enterprises divide teams by product/channel → departmental silos (marketing/sales/product/customer service each manage their own) → ① gaps between customer expectations and reality ② wasted resources from duplicated work. Service Design breaks down silos and ensures that the designed experience is "sustainably delivered" on internal processes. The two should be optimized in parallel, and the connection point is the service blueprint.
Definition of Service Blueprint: A diagram that shows the relationships between service components (people, physical/digital tools, processes) directly related to "specific customer journey touchpoints".It is a continuation of the journey map— especially suitable for complex services (omnichannel) with multiple touchpoints that require cross-departmental coordination. Example: Dine-in and delivery touchpoints at a restaurant are different, so a separate blueprint should be drawn for each.
Key elements of a blueprint (four swimlanes + three dividing lines + evidence):
| Element | What it is | Example |
|---|---|---|
| Customer Actions | Steps and decisions the customer makes when interacting with the service | Browse website, arrive at store, find salesperson, purchase |
| Frontstage Actions | Actions that are visible to the customer | (person-to-person or person-to-technology) |
| Backstage Actions | Behind-the-scenes actions that support the frontstage | Waiter greeting, self-service device |
| Support Processes | Internal steps that support employees in delivering the service | Credit card verification, quality inspection |
| Evidence | Tools and venues where customer/employee interactions take place | Merchandise, website, physical store, video tutorials |
Three dividing lines (the soul of the Service Blueprint):
- Line of Interaction: Direct interactions between the customer and the organization occur along this line.
- Line of Visibility: Above the line = visible to the customer (frontstage), below the line = invisible (backstage).
- Line of Internal Interaction: Distinguishes between "employees who directly support customers" and "internal support processes that do not directly support customers".
Optional auxiliary elements: Arrows (one-way flow / two-way dependency), time (estimated duration of each step), policies and regulations, emotions (locating pain points via employee/user emotional states), metrics (time spent / cost).
5 steps to draw a blueprint:
| Step | What to do | Key points |
|---|---|---|
| 1 Seek support | Build a cross-functional team + win support from stakeholders (management / leaders / customers) | Without backing, the work is in vain |
| 2 Define goals | Select scope and focus (one scenario + corresponding customer goal), define business goals, define type | As-is (show current state to find pain points) vs To-be (explore innovation) |
| 3 Gather research | Customer research (can be taken from journey maps) + internal research (choose at least two: employee interviews / direct observation / contextual inquiry / diary studies) | A blueprint is a qualitative framework, so it requires qualitative research, with quantitative data as a supplement |
| 4 Draw the blueprint | 2–4 hour workshop to draw low-fidelity version → start with customer actions → then frontstage → then backstage → add support processes and evidence | On-site use sticky notes + large paper; remotely use digital whiteboards such as Mural |
| 5 Refine and distribute | Add time / arrows / metrics / regulations → second workshop to produce high-fidelity version → distribute widely | Limit scope (draw each core service separately), base on first-hand data, iterate and optimize |
Blueprint practice survey(97 practitioners across multiple industries): There are three perceptions of "what a service blueprint is" —Output / diagram 56%(only looking at the final map, most likely to miss the "process value"),Framework / method 20%(looking at the process of analysis and improvement),Collaboration tool 15%(looking at cross-departmental alignment). Design teams most often lead, followed by product/project management and research teams; but the participation rate of executives, customer service, marketing, and sales is less than half— this is a hidden risk (lack of key information, affecting implementation and buy-in).
How long does it take to make a blueprint / how high fidelity should it be(from the "Top Questions" Q&A):
| Question | Answer |
|---|---|
| Who should participate | Positively correlated with scope: the broader the scope, the more cross-departmental participation is needed; prioritize inviting people with organizational influence / broad resource access |
| What research to use | Primarily qualitative (quantitative as supplement); Cognitive Mapping interviews are especially effective at revealing employee mental models |
| How high fidelity | Early stage low fidelity (sticky note wall) emphasizes understanding; later stage high fidelity (digitalized) facilitates trust and sharing |
| How long to complete | Focused type (≤3 touchpoints): research <2 weeks + creation 1 week; panoramic type (cross-departmental large scope): <1 month. It is recommended to start small to build trust |
| How to sell it to the organization | ① Involve stakeholders early and frequently ② Track successes as evidence ③ Translate user needs into business impact (saving time / improving satisfaction) |
Core mindset: Service blueprints and journey maps share the "Customer Actions" swimlane, but blueprints are more concerned with "how the enterprise supports these actions". Its biggest output is often not the map itself, but the common language built across departments during the mapping process and the holistic awareness that "oh, my part affects that customer step".
V. How to Actually Run a Journey Project: Three Decisions + Interactive Maps + Empirical Evidence
Three decisions that must be made before starting(applicable to all mapping):
| Decision | Option A | Option B | How to choose |
|---|---|---|---|
| Current vs Future | As-is: Map the real current state, find pain points / breakpoints / emotional ups and downs, build consensus, persuade stakeholders | To-be: Map the ideal experience or a new experience that does not yet exist, to serve as the team's "North Star" | Want to fix existing problems → Current; want to completely reshape / set a new vision → Future |
| Assumptions vs Research | Assumption-First: First hold a 1–3 day workshop to draw an initial draft using existing knowledge, then validate with research | Research-First: First conduct interviews / observations to collect new data before drawing | Team is new / time is tight / cost-saving → Assumption-First; need rigorous persuasiveness / small scope → Research-First |
| Fidelity | Low fidelity: Sticky notes, early stage, easy to collaborate and modify | High fidelity: Polished, easy to share and spread but not flexible | Use low fidelity for early exploration, high fidelity for external sharing |
Recommended hybrid three-step method: ① Quickly draw an "As-is assumption map" using existing knowledge to align the team and identify initial opportunities → ② Validate and update using interviews / diary studies → ③ Based on the validated current state, draw a "To-be map" as the North Star.Both fast and accurate, suitable for teams with limited resources that still want to produce results.
Interactive UX Maps (made with Figma/Sketch): Use overlay layers to gradually reveal research evidence (photos / videos / direct user quotes). Advantages = can embed photos and videos, can add filters to sort by persona / theme, make large and complex maps easier to understand; disadvantages = time-consuming, has a technical threshold (unskilled implementation can create awkward interactions that actually detract).
| Step | What to do |
|---|---|
| 1 | Create a low-fidelity map, linking each finding to its supporting evidence (e.g., "users worry about price" links to a related video) |
| 2 | Build a visual design system (typography / colors / icons / components; in Figma use styles / variables / component libraries) |
| 3 | Group key elements (photos / videos / quotes) by theme or type, all clearly labeled |
| 4 | Use Auto Layout to build a flexible structure (titles / swimlanes / quadrants), skeleton first then content |
| 5 | Replace placeholders with real content (use Figma "swap instance" to replace icons) |
| 6 | Connect interactions in prototype mode |
| 7 | Test and troubleshoot with at least one person (layer names in Figma must be correct). The first diagram can be kept as a template. |
Core principle: Research-based interactive maps that show the "current state" (such as journey maps) are more effective than static maps, because they can intuitively present specific users' verbatim quotes and behaviors. However,assess scope/budget first——if you already have a well-made static map and need to present it immediately, your time is better spent elsewhere; simple maps can be equally effective.
Impact of Journey Mapping: Empirical Evidence from Industry Research(NNGroup surveyed over 300 UX professionals; the following is based on 259 valid responses, with data collected in November 2020 during the COVID-19 pandemic):
| Empirical Findings | Numbers |
|---|---|
| Collaborative creation vs independent creation | 64% created collaboratively by teams, 36% created independently (collaboration performed slightly better in "building internal alignment", p=.1) |
| Digital tools vs physical tools | 56% used digital tools(Miro/Google Sheets), 44% used physical tools (sticky notes); there was no significant difference in success rate between the two——it also works to start with physical tools then convert to digital. |
| Success rates across seven outcomes | Self-assessed on a 1–5 scale, with 3.5 as the "success threshold": performance was best on "presenting pain points" and "building team alignment", and weakest on "persuading management to make internal optimizations". |
Importance ranking of 8 success factors(rated by 234 people, 1–8 scale, higher score = more important):
| Factor | Ranking score |
|---|---|
| Customer involvement in the process | 6.08 |
| Involving cross-functional teams | 5.81 |
| Choosing the right journey to map | 5.21 |
| Choosing the right persona/segment | 4.85 |
| Choosing the right research method | 4.46 |
| Executive sponsorship | 3.84 |
| Rigor of the research used for mapping | 3.75 |
| Polished, visually attractive graphic design | 2.18 |
Why this table matters for PMs:"Pretty design" ranked last (2.18), while "customer and cross-functional team involvement" took the top two spots. Don't blow your budget on visual polish——the priority is bringing in the right people, selecting the right journey, and defining the scope well. It's okay if the first version isn't perfect; its purpose is to help you identify priorities.
VI. Scaling to the Organizational Level: CX Transformation + Journey-Centric Design
When "drawing a journey map" escalates to "reorganizing the entire company around customer journeys", you enter the domain of CX transformation and journey-centric design.
A Framework for CX Transformation: Shifts enterprises from "product-centric" to "customer-centric", delivering consistent experiences at scale. The root cause of problems is that old organizations were designed for in-person/phone interactions, then digital departments were added as siloed units → leading to fractured experiences when customers switch channels. The framework =4 change domains × 4 building blocks = 16 improvement tasks:
| 4 domains (what to change) | 4 building blocks (how to change) |
|---|---|
| Vision and Strategy (leadership commits to long-term customer orientation) | Experience Design Operations (standardize experience design processes) |
| Employees (break down silos, build collaborative networks) | Customer Insights and Metrics (continuously monitor with data/feedback/metrics) |
| Operations (new processes drive cross-functional, journey-centric efforts) | Culture Management (cultivate a customer-centric culture) |
| Technology (infrastructure that supports cross-functional operations and journey management) | Leadership and Governance (clarify decision-making mechanisms) |
In the early stages of transformation, foundational changes should be prioritized first (establishing leadership, research operations, and technology infrastructure).
Journey-Centric Design vs Journey Management(two terms often used interchangeably):
| Term | What it is |
|---|---|
| Journey-Centric Design | A philosophy/framework: Organizing business and design operations around customer journeys, emphasizing "placing journeys at the center of operations". |
| Journey Management | A ongoing practice: The day-to-day operations of researching, measuring, optimizing, and orchestrating customer journeys. |
Why shift from product-centric to journey-centric: Product-centric approaches can only optimize at a small scale (single interfaces) and cannot create major value in complex ecosystems; journey-centric approaches apply user-centered design at both the micro level (product interfaces) and macro level (overall service delivery), bringing four key benefits = ① More design innovation opportunities ② More strategic/business-driven service delivery ③ More advanced behavioral data and design ROI measurement (journey-level analytics demonstrate business impact better than single-step analytics) ④ Creates opportunities for AI personalization (but AI is a complement to, not a replacement for, user-centered design).
Party-Hat Model: Journey-centric design introduces a "journey design strategy layer" on top of product design strategy, connecting cross-functional contributors from product teams with other silos (business/marketing/technology/operations) to collaborate and jointly optimize journey performance. Implications for PMs:Product priorities will be influenced by journey needs, and product managers must balance dual priorities of both "product" and "journey"; organizations typically start with small-scale pilots and iterate. NNGroup conducted two studies for this: a 6-month diary study + in-depth case studies of 4 organizations.
VII. Research Foundation: Observation Framework CUEs + User Panels
These two pieces form the "raw material collection" layer that supports all the mapping above——the accuracy of a journey map depends on field observation and the ability to consistently find the right users.
Context CUEs Framework (for Field Studies): Its theoretical foundation is Distributed Cognition (DCog)——in 1998, Clark and Chalmers proposed the "extended mind" theory, arguing that "thinking" occurs in interactions between people and between people and objects, not just inside the brain (classic example: pilots rely on physical "marker bugs" on speed indicators to reduce memory load). CUEs categorizes messy field qualitative data into three types, used as an observation checklist:
| Letter | Category | Definition | Observation prompts |
|---|---|---|---|
| C | Culture | Implicit/explicit behaviors, beliefs, rules, and values shared by a group | How does the user complete X? When do they ask for help? How do they understand X? Why do they do it that way? |
| U | Unspoken | Tacit knowledge, deeply ingrained practices, underlying assumptions (that will not be stated explicitly) | How were recent internal conflicts resolved? Are there specific language/vocabulary constraints? What do new hires encounter that no one helps with? Are there barriers to accessing key information? |
| E | Environment | Physical/social/online environment | Where does it happen? What is the visual and olfactory atmosphere? Is it the only space? How accessible is it? |
Core principle: CUEs is a "flexible reminder of where to look", not a fixed checklist to tick off; some elements cross categories (a laptop is both a tool and part of the environment). It helps you discover "how users use external memory/workarounds/environmental scaffolds to reduce cognitive load"——these are exactly product improvement opportunities (seeing users frequently flip through a physical address book → build an online directory). Good design = reducing cognitive load and supporting "external thinking".
User Panel 101: A group of users willing to participate in research long-term, plus a management system (to record information, track participation, and facilitate repeated invitations)——it is not just a contact list; its value lies in sustainable reuse.
| Dimension | Key points |
|---|---|
| When it is valuable | When you frequently recruit similar groups, recruitment takes up a lot of time, or you rely on other teams to coordinate users. Suitable for high-frequency, small-scale, rapid-validation research |
| Core benefits | Saves time (pre-screening + centralized management), saves money (reduces external platform/agency fees + hidden coordination costs), and strengthens ongoing connections with real users |
| Key limitations | Panel users are familiar with the product, so their representativeness is limited——this is "research with acquaintances"; for new markets/unfamiliar groups you still need external recruitment, the two run in parallel and are not mutually exclusive |
Two types + driven by business model:
| Type | Composition | Suitable for |
|---|---|---|
| Customer Panel | Existing product users | Evaluating experiences/processes/long-term usage issues; their background is clear but their perspective can become fixed |
| Target-user Panel | People who meet the criteria but have not used the product yet | Understanding needs and discovering opportunities; but recruiting and maintaining them is more labor-intensive |
The form of the panel is determined by "what you sell and who you serve":B2C (e.g., Duolingo) emphasizes scale and diversity, focuses on usability/satisfaction;B2B (e.g., Atlassian) emphasizes clear roles and domain depth, focuses on efficiency/process;Platform/two-sided market (e.g., Airbnb) must cover both sides of the ecosystem (changes on one side directly affect the other). Panel maturity is essentially an outward manifestation of UX maturity: low maturity = spreadsheets/ad-hoc lists just to "reduce recruitment friction"; high maturity = with systems/segmentation/permissions/automation, becoming a cross-team shared asset——its role evolves from "a tool to facilitate research" to "a long-term mechanism connecting the organization and users".
6-step setup: Recruit → Organize & Segment → Contact & Schedule → Incentivize & Engage → Reengage & Manage → Govern & Improve. Tool selection: mature teams use professional research platforms (end-to-end but expensive), CRM systems (only basic information management and segmentation), general tools such as spreadsheets (usable in early stages, risk rises sharply as scale grows).
VIII. Three Practical Journeys + Narrative Techniques
Apply the preceding methods to three real research cases——see how NNGroup uses a journey perspective to deconstruct an industry.
Case 1: Luxury Shopping. Qualitative research with 9 participants (new customers/loyal customers/stylists/consultants), shopping covered brands including Jimmy Choo, Hermès, Chanel, LV, Burberry, Cartier, Tiffany, BMW, Rolex, Golden Goose, etc.Four types of shoppers(can shift over time and across categories; for example, a lawyer may be a big spender on suits but an occasional splurger on cars):
| Type | Characteristics |
|---|---|
| Window shoppers | Young fans who cannot afford the brands but follow them (aspiring to buy one day) |
| Occasional splurgers | Buy durable goods (bags/shoes) for special occasions, treating them as enjoyment, investment, and family heirlooms |
| Big spenders | Frequent multi-brand core customers who account for the majority of sales; deeply familiar with brand history (research brand leadership teams), build exclusive relationships with brands (personal sales representatives), and enjoy membership privileges (free repairs/event invitations) |
| Professional stylists | Experts who buy for clients, mostly using platforms like Farfetch/Net-a-Porter rather than single-brand official sites, buying in bulk then returning unwanted items |
Four-stage journey (Discovery → Consideration → Purchase → Use), key conclusions:"Consideration" is the longest and most critical stage(for all user groups), and pain points are concentrated here——cannot find product names and purchase channels, lack of detailed photos and real-life displays, unclear return policies (risk for high-priced items), poor information architecture, useless recommendation systems.Luxury brands' websites/apps are most important in the "consideration" stage, and resources should be concentrated here to improve the experience. An interesting counterintuitive point: many luxury websites deliberately limit information/hide prices (e.g., Maison Goyard), using "high price + limited information" as a threshold to filter out customers who truly understand and love the brand; the use stage also splits into two mentalities: "want prominent logos to show status" vs "quiet luxury" (afraid of encountering fakes/afraid of becoming a target/think prominent logos are tasteless).
Case 2: Digital Interactions in Healthcare. Longitudinal diary study with 9 participants, recording every healthcare interaction over one month, totaling 93 interactions. Key numbers:
| Finding | Number |
|---|---|
| Device: smartphones dominate | Of the 93 interactions, 78 used a phone (convenient, especially when out); computers were used for 14 (complex tasks such as filling out forms, logging into virtual appointments, where the interface is more stable) |
| Channel: patient portals most used | Portals (e.g., MyChart) 32 times; digital channels far outnumbered traditional (72 digital vs 21 traditional) |
| Pain point: digital is actually more complex | Nearly half of journeys contained at least one pain point, more common in digital interactions (1/3 encountered barriers on traditional channels,2/3 encountered problems on digital channels) |
Main pain points: hard to find information, missing features, technical glitches, hard-to-understand information (lack of result explanations), and most occurred early in the journey.Core lesson: Digital channels have advantages in efficiency and convenience (asynchronous communication, pre-filled forms), but virtual appointments have low satisfaction (lack of nonverbal communication, difficulty building rapport); fragmented integration instead increases complexity. Guidelines: offer asynchronous communication options, choose mobile-friendly tools that are consistent across devices, create seamless transitions between digital and in-person experiences,set expectations when switching touchpoints and ensure subsequent experiences deliver on those expectations.
Case 3: The 4 Stages of AI Image Generation——An "experience map of expert users". Contextual inquiries with 9 users, all of whom independently chose to use Midjourney. The four stages:
| Stage | What the user is doing | Key details |
|---|---|---|
| 1 Define | Set goals + figure out how to achieve them | Goals are divided into inspiration-oriented(searching for inspiration to find concepts) vs deliverable-oriented(needing high-quality finished products); starting points use past images / genAI chatbots (asking ChatGPT to write prompts) / external resources (Midlibrary) |
| 2 Explore | Generate a large number of images that roughly match the vision | Typically generate 20–80 images; two strategies = prompt repetition (exploring multiple directions with the same prompt, using --r 10 batches of 10 outputs at a time) + prompt variation (changing prompt wording); "happy accidents" often lead to new directions |
| 3 Refine | Adjust images to get closer to the goal | Even experts find this difficult — "It's a generator, not an editor"; AI randomness causes every small tweak to change related elements (changing the sofa fabric results in the entire sofa changing), making the process time-consuming and frustrating, and the finished product is often imperfect |
| 4 Export | Export the satisfactory image | May use Photoshop for retouching, AI upscaling to increase resolution, or add text |
Nonlinear variations: Not everyone goes through all four stages.Inspiration-oriented users spend more time in the Explore stage(they only want creative ideas, often skipping Refine/Export and finishing in Figma);Deliverable-oriented users spend more time in the Refine stage(pursuing perfect details, limited control makes the process full of frustration), and the overall time spent is much longer. Implications for designers: pain points are concentrated in the Refine stage, and the direction for improvement = giving users more control.
Narrative techniques: Two tips for making UX stories more compelling(Two Tips for Better UX Storytelling) — After finishing a journey, you need to tell it to others; here is how to tell it:
| Tool | What it is | How to use it |
|---|---|---|
| Story Triangle | Three elements: story / narrator / audience, emphasizing that storytelling is two-way communication not one-way lecturing | The audience will fill in details with their own experience, so the narrator should leave space for them to share assumptions and feedback.The amount of detail should be adjusted according to the goal: If you want to highlight a specific problem (usability barrier) → provide more details; if you want to inspire new ideas → provide only the basic plot |
| Story-Mountain | Derived from 19th-century German playwright Gustav Freytag's "Pyramid", with five segments: Exposition → Rising Action → Climax → Falling Action → Resolution | Organize the user experience into a complete narrative (using the example of Mary choosing between a bus and a taxi to catch the last train), making the user the core of the narrative, with clear logic and full emotion, and giving the audience specific action recommendations |
Core principle: Journey maps / research data themselves will not persuade people;wrapping them in a story with a protagonist, conflict, and turning points will. But details are a double-edged sword — too many limit imagination, too few lead to misunderstanding; decide based on "Do I want to solve a specific problem or inspire new solutions?".
Sourced from NNGroup Topics / Customer Journeys (29 articles). For user personas and journey subjects, see NNGroup Personas (Essence / Three Types / Scope Hierarchy / Creation / Comparison with JTBD-Prototypes-Segmentation / Application / Maintenance / 5 Major Failures); for qualitative methods such as contextual inquiry / diary studies / field studies for journey mapping, see NNGroup Qualitative Research and Research Methods Toolbox (Method Landscape / Interviews / Empathy Maps / Sample Size / Task Design / Moderation / Expert Evaluation / Workshops / Ethics); for the positioning of mapping in the entire UX research method spectrum, see NNGroup UX Research Method Selection (Quick Reference for 23 Methods / Four-Quadrant Positioning / Selection by Problem-Stage-Budget / Five Major Families: Qualitative Exploration · Quantitative Validation · Expert Evaluation · IA · Behavioral Analysis). Images / original files are retained in sources.
Sources and related materials
- NNGroup Personas (Essence / Three Types / Scope Hierarchy / Creation / Comparison with JTBD-Prototypes-Segmentation / Application / Maintenance / 5 Major Failures)
- NNGroup Qualitative Research and Research Methods Toolbox (Method Landscape / Interviews / Empathy Maps / Sample Size / Task Design / Moderation / Expert Evaluation / Workshops / Ethics)
- NNGroup UX Research Method Selection (Quick Reference for 23 Methods / Four-Quadrant Positioning / Selection by Problem-Stage-Budget / Five Major Families: Qualitative Exploration · Quantitative Validation · Expert Evaluation · IA · Behavioral Analysis)