NNGroup UX Strategy · Roadmap · Maps · Risk & Debt · Retrospective · Stakeholders (21 articles · UX Strategy/Three Stages of Complex Applications/CASTLE/Mood Board · Roadmap Roles & Timing + 5 Prioritization Methods + Pareto · Interactive Maps/Asset Mapping/Journey Map Creation Time 73.8h/Skill Map · 6-Step Design Risk + UX Debt + Breakage Tracking RAS · 4-Step Retrospective/7 Elements of Postmortem · Stakeholder Power-Interest Matrix + Interviews + Cross-Team + RACI + Scrum Responsibilities)

This batch is not about "how to design a button", but about "how UX teams turn a vague set of intentions into prioritized, owned, deliverable work that can be reviewed after completion". It covers a complete closed loop:

Set direction (strategy/mood board) → Prioritize order (roadmap + 5 prioritization methods + Pareto) → Turn research into communicable maps (interactive maps/asset mapping/journey maps/skill maps) → Manage downside risks (design risk/UX debt/breakage tracking) → Learn after the fact (retrospective/postmortem) → Get people on board (stakeholder analysis/interviews/cross-team/RACI/Scrum responsibilities).

First, lay the groundwork for key terms:Stakeholder= Anyone who has an interest in the project, or whom you need to collaborate with to complete the project (CEOs, PMs, technical architects, your direct manager all count);Roadmap= The strategic layer of "which problems to solve in the future", it does not specify "how to do it" (that is the project plan);UX Debt= Known experience issues that are set aside due to priority or time constraints, which grow larger over time like credit card debt;Retrospective= Regular self-reflection after an iteration ends,Postmortem= In-depth post-project review after a single project ends. Each section provides Core principles + Why + Counterexamples.

1. UX Strategy: Setting Direction (Three Stages of Complex Applications · CASTLE · Mood Board)

The strategy layer answers "where we are going, what we measure by, and how we align on visual feel". The three articles cover respectively: research approaches for complex scenarios, measurement frameworks for work software, and rapid alignment tools for visual direction.

1.1 Three Stages of Complex-Application Design (UX Strategies for Complex-Application Design)

Users of complex applications (healthcare, warehousing, logistics, financial risk control, scientific research tools) are domain experts, whose decisions are constrained by company rules, professional tools, and industry regulations — therefore studying only "the individual user" is not enough; you must study "the entire work environment the user operates in". It follows the three stages of design thinking, but requires upgraded methods at each stage:

Stage	Common Practice	Complex Application Upgrade	Example
Understand	Interview a few users	Study the entire industry(goals/terminology/roles/constraints) + Observe at real work sites(shared devices, collaboration, noise) + multiple roles and multiple methods	Before building software for a hospital, shadow nurses at work and sit in on medical meetings to understand clinical workflows and protocols
Explore	Free brainstorming	Turn constraints into creative guidelines(list regulatory/security/data requirements first before diverging) + simple prototypes (sketches/storyboards) + Co-design with experts	For a medical decision tool, first organize privacy requirements, then design alerts that "remind without disturbing"
Materialize	Lab usability testing	Add real-scenario dialogues/contextual interviews/long-term observation(test "whether it delivers value" not just "whether it is usable") + collaborative review with professionals + if experts are unavailable, first use internal colleagues (note limitations)	When testing a financial risk control tool, have users process the real scenario of "assessing high-risk loans"

Core principle: In complex applications, "whether it is used correctly" is far more important than "whether it looks good" — the cost of error is high, and domain knowledge is deep.Why: Lab testing cannot capture the judgment and professional knowledge in real environments; the tacit decisions experts make in real work are lost in lab tests.Counterexample: Testing a warehouse system in a clean lab completely misses the factors that truly determine success or failure, such as "workers wearing gloves, viewing screens in bright light, operating handheld devices while walking".

1.2 The CASTLE Framework: Evaluating "Involuntary Use" Work Software

Google's HEART framework(Happiness/Engagement/Adoption/Retention/Task success) was designed for consumer products — where users can freely choose whether to use the product. But internal enterprise software and government tools are mandatory to use, so metrics like retention rate are meaningless (employees have no choice). NNGroup proposed CASTLE the CASTLE framework specifically to fill this gap:

Letter	Dimension	What it measures	Example metric
C	Cognitive load	How much mental effort is required to complete tasks (frequent page jumps, mental arithmetic, and information overload all increase it)	NASA-TLX questionnaire to measure mental workload
A	Advanced feature usage	Whether users use non-essential but efficiency-enhancing features (personalization, acceleration tools)	Share of users who customize their dashboard
S	Satisfaction	Work software does not seek "delight", it seeks "less frustration"	SEQ questionnaire, analysis of "rage clicks"
T	Task efficiency	How much time and how many steps are needed to complete a process	Quantitative usability testing to measure completion time
L	Learnability	How quickly new employees get up to speed, and their reliance on help documentation	Longitudinal usability testing to observe completion time decreasing over time
E	Errors	User operation mistakes + system error frequency	Analyze system validation error logs

Core principle: Like HEART, each dimension must be implemented using the Goals → Signals → Measures three-step approach (dimensions are too broad to quantify directly).Why: Consumer products care about "making you want to come back", work software cares about "letting you leave with less frustration", so the measurement axes must change.How to choose: Do not track all 6 dimensions; pick the few that are currently most painful; quantitative data only tells you "where the problem is", root causes still require qualitative research (interviews, usability testing). CASTLE is a complement, not a replacement.

1.3 Mood Board: Rapidly Aligning Visual and Emotional Direction

A mood board = a collage made of images, video frames, patterns, and text that conveys a certain "feel" at a glance. In UX it is used to let people who do not understand design also grasp "what temperament the product should have", and define the main UI colors and visual identity.

When to use: In the "Define / Ideate" stage of new product design or major redesigns,before building prototypes to align on style first.
Who leads: Initiated by UI/visual/interaction designers, bringing in product owners and content managers. It is recommended to create multiple mood boards to compare and select a direction.
6 steps: ① Review existing style guides → ② Choose tools (physical boards are good for in-person but hard to share; digital boards Miro/Mural/FigJam are good for remote) → ③ Select 4-5 mood keywords(group synonyms with sticky notes) → ④ Collect visual materials (Pinterest/Google Images, ensure consistent themes, do not mix styles) → ⑤ Arrange layout (enlarge key materials and place them center, use white space to separate sections) → ⑥ Share and clearly explain "why these were selected".

Counterexample: Piling up a large number of product screenshots as a mood board — that biases the board toward "functional reference" rather than "emotion", and should instead be called a "competitive analysis board/reference board". The core job of a mood board is to convey feeling(inspiring/energetic/bright), not to copy interfaces.

2. Roadmap: Prioritizing Order (Scope · Who Builds It and When · 5 Prioritization Methods · Pareto)

2.1 Roadmap vs Project Plan + Three Layers of Scope (UX Roadmaps: Who, When, How Much Time)

Comparison	Roadmap	Project Plan
Nature	Strategic, vision-oriented, dynamic	Execution-focused, tracks outputs
Content	Which problems to solve in the future, goals, Objectives	Specific tasks and steps, how to do it

Three layers of scope (from broad to narrow):

Type	Coverage	Who is responsible	How long to build
Product Roadmap	All future issues across UX + marketing + development	PM (in high-maturity teams, co-built by product/design/development leads)	Several days to weeks/months (including executive discovery research, vision, alignment)
Domain Roadmap	Only the UX domain, aligns all UX departments	UX director/lead	Most within 1 day
Initiative Roadmap	A subset of a single UX domain (e.g., user research)	Team lead/individual	Most within 1 day

When to build: New project kickoff (set shared vision), goal deviation (realign), leadership change (show direction to new leadership),annual planning (most common).
How often to update: Monthly routine updates — move completed themes to the "Done" column, update priorities, add new themes; record all versions for new team members' reference. Only 34%34% of people reported spending more than 1 week building a roadmap; most people update weekly to monthly.
How to present (three-column storytelling method): ① Set the context (where we came from) → ② Show recently completed progress → ③ Present current/upcoming tasks in two columns: "Now" and "Next" → ④ Only show the long-term vision at the end. Unfold content gradually to avoid information overload, and anchor discussion focus on current priorities.

Core principle: A roadmap is "the bridge between strategic execution and task management."Counterexample: Writing a roadmap as a detailed Gantt chart packed full of tasks and dates — that is a project plan, which will drag stakeholders into execution details and lose the strategic conversation of "what problem are we actually trying to solve."

2.2 Five Prioritization Methods (5 Prioritization Methods in UX Roadmapping)

There are many candidate issues on the roadmap — what do you use to rank them? These 5 methods replace "gut feel" with "objective assessment"; which one to choose depends on project characteristics and team culture:

Method	How to score	Output	Best for
Impact-Effort Matrix	Two-dimensional voting (user value × implementation difficulty)	Four quadrants: Quick Wins (low effort, high impact · prioritize) / Big Bets (high effort, high value · proceed cautiously) / Money Pit (high effort, low impact) / Fill-Ins (low effort, low impact)	Teams that want intuitive visualization and cross-functional voting (developers vote on effort, designers vote on impact)
Feasibility-Desirability-Viability Scorecard (IDEO)	Score against three criteria: Feasibility (technology/resources), Desirability (how much users want it), Viability (whether it benefits the business long-term)	Ranked by total score	Teams that want to balance "can we build it / do users want it / will it make money"
RICE Method (Intercom)	Reach×Impact×Confidence/Effort(Reach × Impact × Confidence / Effort)	Ranked by numerical score	Teams with large project volumes, technically oriented, that want purely numerical decision-making
MoSCoW Analysis	Four categories: Must have / Should have / Could have / Won't have	Weighted voting grouping	Teams with clear time/resource constraints that need to guarantee delivery of "Must have" items
Kano Model (Noriaki Kano, 1984)	Categorized into four types by functionality × satisfaction: Attractive (exceeds expectations) / Performance (more = higher satisfaction) / Indifferent / Must-Be (absence causes dissatisfaction)	Requires user research data to assess satisfaction	Teams that value user expectations and want to distinguish "delight features" from "baseline requirements"

Core principle: There is no "best" method; once you find a suitable one,adjust it to your team's needs, and involve stakeholders in scoring (participation = buy-in).How to choose: If you need visualization to align people → Impact-Effort Matrix; if you have many items and need sortable numbers → RICE; if you have hard time constraints and need to guarantee baseline delivery → MoSCoW; if you want to separate baseline vs. bonus features → Kano.

2.3 Pareto Principle (80/20 Rule) to Focus on the Vital Few (Focus Your Design Tactics)

80% of outcomes come from 20% of causes(Pareto observed that "80% of the peas in his garden came from 20% of the pods"; Juran applied it to management). It is widely applicable: 20% of customers generate 80% of revenue / 20% of products account for 80% of sales / 20% of problems cause 80% of complaints / 20% of websites get 80% of traffic.

UX application: When facing massive data from analytics platforms, surveys, traffic, etc., it is easy to fall into "analysis paralysis." First identify the 20% with the greatest impact.Example: An app's CSAT (Customer Satisfaction Score) dropped; analysis of bug tracking and support tickets found 80% of bugs were concentrated in 4 core features — prioritize fixing these 4 to gain the largest experience improvement with less investment.
Advantages: Reduces ineffective data processing, optimizes limited resource allocation, and quickly improves user satisfaction.

Caution: Do not over-rely on it.Counterexample: Only focusing on issues that "immediately affect 80% of outcomes" will cause you to overlook emerging needs that have small current impact but large future value — reserve a portion of resources for exploration, balancing "optimizing the known" and "exploring the unknown."

III. UX Maps: Turning Research into Communicable Artifacts (Interactive Maps · Asset Mapping · Journey Maps · Skill Maps)

The shared purpose of map-type tools: visualize research findings to align the team and help stakeholders understand.

3.1 Interactive UX Maps (Building Interactive UX Maps, two articles combined)

Use Figma/Sketch to turn user research into high-fidelity, clickable maps — clicking a theme pops up corresponding user verbatims, videos, and photo evidence.

Advantages: Can overlay multimedia, filter different journeys by user type, help audiences understand complex content, and increase stakeholder engagement.
Disadvantages: Time-consuming and budget-intensive; requires proficiency in advanced design software features (lack of skill will instead produce hard-to-use maps).When not to make one: If you already have a non-interactive map and the presentation is imminent — it is more cost-effective to keep it as is.
Production steps (complemented across two articles, merged into a complete 8 steps):
1. Consolidate low-fidelity data: Link each finding (e.g., "Users worry about the cost of new software")item by item to evidence (interview videos/verbatims).
2. Build a visual design system: Reuse brand styles or create new ones (fonts/colors/icons + Figma text styles/color styles/variables/component libraries); create multiple states for interactive buttons (normal/hover/clicked).
3. Group by content category: Use Figma's Section tool to block out photos/videos/quotes.
4. Use Auto Layout to build the skeleton (titles/swim lanes/quadrants): when collapsible panels expand, content below is automatically pushed down without overlap.
5. Add real content: Replace placeholder text and icons (use Swap Instance icon plugins to quickly swap icons).
6. Prototype mode to wire interactions: select an element → define interaction type (e.g., click to show overlay) → set target.
7. Test and adjust: Pull in at least one colleague to test; if overlays are not named correctly, go back to the component library to check naming and fix; use Figma comments to note items needing changes.
8. Save as a template: Remove content and leave only the framework + add prototype notes (explaining interactions and limitations), publish components to the team library for reuse next time.

3.2 Asset Mapping (Asset Mapping for Experience Consistency)

Chronologically record all interfaces and elements a user encounters when completing a task (webpage screenshots, emails, SMS, push notifications, self-service kiosk photos), used to check omnichannel consistency.

Comparison	Asset Map	Customer Journey Map
What it looks at	Concrete interfaces/elements (screenshots, emails)	Overall user experience (thoughts, emotions, motivations)
Scope	Small flows, company-owned channels	Journeys from large to small, may extend beyond company control
Purpose	Check cross-channel consistency	Understand overall user experience, provide context
Workload	Low (only need to supplement materials if a journey map already exists)	High (requires in-depth user research)
Limitations	Does not include emotions/motivations (unless combined with a journey map)	Does not include interfaces users actually see (unless combined with an asset map)

5 steps: ① Select a flow (from an existing journey map or an important task such as sign-up) → ② Walk through all channels and take screenshots, arrange them in operation order and label the channel → ③ Check 5 types of inconsistency (core functions/process steps/data content/tone and style/visual design) → ④ Circle and annotate problems, discuss root causes with relevant departments → ⑤ Prioritize fixes (start with low-cost, high-impact ones: revise copy, unify visuals).
Benefits: Quickly identifies problems, breaks down departmental silos, and provides reference for finding duplicate/missing components for design systems.Example: After a user ordered pet food, they received 6 emails with identical content in a short time — asset mapping revealed the redundancy at a glance, and the recommendation was to merge them into 1–2 emails.

Core principle: Add real interface screenshots to a journey map, and it becomes an asset map — the two complement each other. Asset mapping is a low-cost quick win tool; even if organization-level big problems are not solved, it can demonstrate the results of small, rapid iterations.

3.3 Time Investment, Roles, and Methods for Journey Maps (How Much Time + How Practitioners, two articles based on a survey of 343 people)

Two articles based on the same survey of 343 practitioners, answering "how long does it really take to make a journey map, who participates, and how to do it."

(A) Time investment — average work hours for the five steps (geometric mean, 95% confidence interval):

Step	Work hours
Conducting external user research	20.6 h
Synthesizing research insights	16.4 h
Collecting internal stakeholder data	10.2 h
Producing the journey map deliverable	9.9 h
Building support/securing resources	8.9 h
Total	73.8 h ≈ two weeks of working time

Agencies vs. in-house teams: In-house teams spent slightly more at 79.8h vs. agencies at 71.7h; agencies spent more on "producing the deliverable," while in-house teams spent more on "securing support/collecting data/synthesizing insights";collecting data from users takes about 20h (baseline ≈ at least half a week).
Small companies vs. large companies: Large companies (≥500 employees) averaged 87h, small companies 64.9h; large companies took longer at every stage.Insight: Regardless of size, investment in "securing support and resources" is high — which shows large company size ≠ high UX maturity; everyone has to spend time communicating value to stakeholders.
Research-first vs. assumption-first: Assumption-first does not save time; instead, the overall process takes longer — skipping preliminary user research is not a valid way to shorten a project.

(B) How to do it — typical method trends:

Dimension	Findings
What experience to map	89% assess the current state of existing products / 73% envision the future state after optimization / 61% conceptualize entirely new products
Initiation approach	62% assumption-first (cross-functional workshops use existing knowledge to generate an assumption map) / 35% research-first (recommendation: follow up assumption-first with research to validate)
Research methods	Interviews are most common (86% external / 76% internal); diary studies are least common (12% external / 6% internal)
Who participates	Led by UX/design; cross-disciplinary: Product 70% / Marketing 46% / Customer Support 42%; 64% collaborative creation, 36% independent; 34% use physical tools (sticky notes), 30% use digital tools (Miro/Mural/Sheets)
Component sources	Personas: 49% use existing personas, 27% develop during project research, 14% create in workshops; Journey stages: mostly determined during user research (31%) or workshops (31%), rarely identified at the outset

Core principle: Research shows that all differences (agency/in-house, large/small company, research/assumption-first) are statistically not significant — so there is no universal "standard duration."How to use: Use this set of benchmarks (total about two weeks, data collection about half a week) to help your team judge "whether we should make a journey map, how deep to invest, and which approach to use."

3.4 Skill Mapping (Skill Mapping: A Digital Template for Remote Teams)

Use radar charts to visualize the strengths and weaknesses of individual team members and the whole team (axes = skills, values = proficiency), overlaying individual charts into a team chart.

3 major uses: ① Understand team composition (find skill gaps) ② Hiring (have candidates self-assess, see fit with the team) ③ Track individual development (quarterly/annual self-assessment, set learning goals).
Two types of analysis: Skill gaps (the team completely lacks a certain skill; assess whether it is necessary) + single-point dependencies (only one person has a certain skill; decide whether to train others or hire).
How to use the template: Make a copy of the Google Sheets template (the Excel version's radar chart may have conversion errors) → Customize skills (8 preset items; can be broad such as "user research" or specific such as "ANOVA data analysis") → Up to 10 members → 1–5 point self-assessment (1 = only know terminology, cannot do independently; 3 = can occasionally apply independently; 5 = excellent performance across multiple projects, can mentor others) → Fill in current state + future goal (set a time frame such as within 1 year) → View the auto-generated team chart → Download and archive.

Core principle: The comparison between current state and future goal is exactly the lever for team discussions on "who to train, who to hire." As team size and project needs change,update it dynamically.

IV. Risk and Debt: Managing the Downside (Design Risk · UX Debt · Breakage Tracking)

4.1 Design Risk (Design Risks: Assess, Mitigate, Manage)

Design risk = the likelihood that some aspect of a new or existing design will negatively impact the business or users.Risk = Probability of occurrence × Impact severity.

6-step process: ① Establish organizational goals (why the risk is worth taking, align on key success criteria) → ② Identify risk factors (behavioral/attitudinal research, flowcharts, ticket data; for new products, review competitor research) → ③ Assess risk (use the risk assessment matrix to "plot" risk levels by severity × frequency) → ④ Develop mitigation measures (reduce probability or reduce impact) → ⑤ Implement controls or make risk decisions → ⑥ Evaluate and monitor (reassess regularly, as measures can become outdated).

Risk assessment matrix(adapted from U.S. Army ATP 5-19, cell value = product of severity × likelihood):

Impact \ Probability	Unlikely	Seldom	Occasional	Likely	Frequent
Minimal	Low	Low	Medium	Medium	High
Moderate	Low	Medium	Medium	High	High
Critical	Medium	Medium	High	High	Very High
Catastrophic	Medium	High	High	Very High	Very High

"One-click purchase" example(e-commerce goal = increase revenue per visitor):

Risk factor	Mitigation measure	Before mitigation → After mitigation
Increase in accidental transactions → higher support costs	Provide immediate confirm/cancel options, delay shipping by 12 hours	Medium → Low (both probability and impact reduced)
Increase in fraudulent transactions → data risk	Require verification and confirmation within 12–24 hours	High → Medium
Increase in small-batch orders → logistics costs / carbon emissions	Offer two options: "ship immediately" / "ship with next batch"	High → Medium

Key principle: Developing a mitigation measure does not mean you must implement it— Step 5 requires weighing costs and benefits (if a measure slows down the process without significant benefit, do not do it).Counterexample: Trying to "hypothesize every possible risk" is counterproductive; for hard-to-control external risks,prioritize monitoring(adapt quickly when risks first appear) rather than exhaustively trying to eliminate them.

4.2 UX Debt

UX debt = known experience issues that are deprioritized due to priorities, time, or resource constraints — like financial debt, it accumulates over time into larger experience barriers.

4 key steps: ① Acknowledge that the problem exists (do not ignore or forget it) → ② Track(log it in a backlog, spreadsheet, or database; in large companies with many tasks, debt is easily buried by new features, so first prioritize in a spreadsheet before moving to the backlog) → ③ Communicate and report(use consistent language, share status/severity charts so stakeholders and leadership can see priorities and remediation progress) → ④ Create a remediation plan(continuous improvement strategy: allocate some story points each sprint to address at least 1–2 debt items).story points each sprint to address at least 1–2 debt items).

Prioritization and visualization: Use a priority matrix to plot a scatter chart by "user value × fix difficulty" —prioritize fixing items that "have high user impact + low fix cost"(to quickly improve experience).

Key principle: UX debt cannot be completely avoided, but it can be effectively managed through acknowledgment, tracking, communication, and planned remediation, ensuring continuous improvement of the product experience.

4.3 Breakage Tracking and Recommendation Adoption Score (RAS) (Why We Need to Track Breakage)

The traditional question for research is "what did we learn," but the more important question is "what did we do."Track Breakage = identify at which stage research recommendations fail to be implemented.

Value Chain of Research: Data → Finding → Insight → Recommendation— the further right you go, the higher the value; the most valuable are directly actionable recommendations. If any link breaks, the recommendation fails and the research is wasted.

Example chain: HelpZone homepage click data → "Only 0.03% of users clicked the 'Featured Articles' area" → Insight "Users don't look at this area, it wastes space" → Recommendation "Remove it and replace with self-service features".

Early warning signs of breakage: The team says "let's do more research" but cannot explain what decision it will change / the most important recommendations are glossed over / designers bypass recommendations and make do with existing components / lots of documentation is written but no tasks, owners, or launch plans exist / management only says "we are doing research" and cannot name "what changes we made because of research" / researchers are no longer invited to meetings.

How to fix it: Turn insights into specific, actionable recommendations (clearly state what/who/when/how, avoid phrasing like "we could consider…") → add recommendations to the product plan as concrete tasks → continue tracking impact after launch (set goals such as "reduce churn rate from X% to Y%") → identify organizational barriers (seek executive support, form cross-departmental teams, track continuously in planning meetings) → set tracking points at every stage (research → insight → recommendation → launch) (record owner/status/priority/delivery time).

RAS (Recommendation Adoption Score)— measures whether recommendations are adopted, fully implemented, and whether value reaches users, similar to OKRs:

RAS = (Adoption × 0.5) + (Fidelity × 0.3) + (Impact × 0.2)

Dimension (weight)	Meaning	0 → 1 scale
Adoption (50% · most critical)	Whether it was implemented	0 Not adopted / 0.25 Weakened / 0.5 Partially adopted / 0.75 Mostly adopted (watered down) / 1.0 Fully adopted
Fidelity (30%)	Implementation quality	0 Deviates from the user problem / 0.5 UI interaction does not match the plan, reducing effectiveness / 1.0 Fully implemented as intended
Impact (20% · hardest to measure immediately)	Whether it changed user behavior	0 Not launched or no impact / 0.5 Trend exists but not verified / 1.0 Clear improvement in data

Interpreting results: 0.6–0.75 Normal (healthy with room for improvement) / 0.75–0.9 High (excellent team) / 0.9–1.0 Very high (top-tier maturity).

Key principle: The focus is not on assigning blame, but on treating "recommendation implementation" as a manageable goal. The value of research is not just finding problems, but also driving change— make adoption rate a team performance metric, and review quarterly which recommendations were done / not done / why.

V. Retrospectives and Postmortems: Learning from Success and Failure (Retrospectives · Postmortems)

Both are "looking back," but at different levels:Retrospective is a regular reflection held after an iteration ends (cadence-based), while Postmortem is a deep post-project review(event-based) held after a single project ends.

5.1 Four-Step Retrospective Meeting Method (Retrospectives 101)

A retrospective is a meeting where the team regularly reflects on recent work and finds ways to improve (often associated with Agile/Scrum, but applicable to any process).

When to hold + who to invite: For Scrum teams, after every Sprint; for non-iterative teams, every two weeks/month/quarter.Full team participation— invite even roles that only participated in part of the work (to get comprehensive feedback).
Four steps:
1. Set expectations: Send the agenda before the meeting, set ground rules during the meeting —avoid blame(say "we didn't achieve this this time" instead of "you caused…"), focus on team improvement, keep an open mind; use sticky notes for anonymous idea writing or take turns speaking.
2. Discuss what went well: What went well? What did you like? What did you learn? Which tools/techniques were helpful? (Individuals can be recognized, but the focus is on team success.)
3. Discuss areas for improvement: What was lacking? What would you like to reduce? What to do differently next time? Which issues blocked progress? (Sailboat metaphor: What pushes the team forward / what slows it down / what threatens success.)
4. Create an action plan: For each improvement item,assign an owner + completion date; split tasks that are too large; record them in a place accessible to the team.
Follow up after the meeting: At the next retrospective,first review the previous action plan, mark completed items, and continue unfinished ones.
Tips: Rotate facilitators, track long-term recurring issues, encourage everyone to participate (sticky notes let introverts contribute anonymously), keep a fixed cadence. You can also hold a Meta-retrospective— reflect on whether your retrospectives themselves are useful.

Counterexample: If no one raises issues for a long time,it does not mean there are no problems — it may mean people are afraid to speak up— you need to re-examine the meeting environment to ensure it is a "safe space with no risk of retaliation."

Different teams: Product teams use them most often (close daily collaboration); UX teams focus on design processes/evaluation methods; leadership teams reflect on the effectiveness of new strategies.

5.2 Seven Essential Elements of Project Postmortems for UX Teams

A postmortem is a systematic review after a project ends of "what happened, which decisions worked/failed, and why." Many teams write success case studies but rarely document failures — yet failures better expose real constraints(organizational collaboration, time pressure, technical constraints, misjudgments of user behavior).The goal is to learn systemic causes, not to assign blame.

Six analysis dimensions(do not attribute outcomes to a single draft or individual): Research (was research early and accurate enough, did conclusions actually influence decisions) / Problem & Goals (were requirement metrics clear, was there goal drift) / Design (rationale for solutions, records of tradeoffs) / Development (technical constraints, smoothness of handoffs) / Process (were milestones reasonable, was there frequent rework) / Communication (was information given to the right people at the right time).

7 necessary conditions for a high-quality retrospective/postmortem:

Element	Standard
1 The right people present	Core members + PM/lead + stakeholders involved in decision-making + (optional) external perspective representatives;limit to 6–10 people
2 Clear success criteria	Ideally define metrics before the project; if not, align at the start of the postmortem on "what we originally wanted to achieve"
3 Psychological safety	Clearly state "understand and improve the system, do not blame individuals"; if necessary, find a neutral facilitator with no stake in the outcome
4 Root cause analysis	Use 5 Whys / timeline review / resource analysis / external factors to trace "why the process failed to catch this" rather than "who made a mistake"
5 Actionable outputs	Things that change the system: new checklists, added review gates, updated documentation, fixed tools;avoid empty phrases like "improve communication" or "be more careful"
6 Owner + deadline	Define owner and deadline on the spot; recommend monthly reviews of implementation status
7 Document and archive	Keep it to 2–3 pages: Overview of goals, success metrics and results, key root causes, action items (with owners), (optional) timeline

Typical 7-step process: Pre-meeting preparation and alignment → Collect evidence (research/design/prototypes/testing/launch metrics/feedback) → Reconstruct the timeline (requirements → research → design → development → launch, mark key decision points) → Identify outcomes and phenomena → Analyze root causes → Define action items (3–5 most critical, specific, and verifiable items) → Share and archive (so future projects can search and reuse it).

Key principle: Continuous postmortems/retrospectives build an "organizational experience library" — reducing repeated errors and improving process maturity.The prerequisite is psychological safety: otherwise teams will tend to hide problems, and the retrospective/postmortem loses its meaning.

VI. Stakeholders: Managing People (Analysis · Interviews · Cross-team · RACI · Scrum Responsibilities)

6.1 Stakeholder Analysis: Power-Interest Matrix (Stakeholder Analysis for UX Projects)

When to do it: When starting a new project with new stakeholders, or when low-UX-maturity teams want to increase organizational acceptance of user-centered design. First ask yourself: Who is interested in the project? Who has influence/control/decision-making power?

Power-Interest Matrix (Mendelow's Matrix):

Quadrant	Position	Strategy	Example
Manage Closely	High power + High interest	Communicate regularly, actively seek support	Department heads who allocate resources, CEOs with personal opinions on design
Keep Satisfied	High power + Low interest	Update progress regularly, ensure potential needs are met	Executives indirectly related to the project but with high authority
Keep Informed	Low power + High interest	Invite to participate in design reviews or observe research	Support teams related to the project
Monitor	Low power + Low interest	Do not spend too much effort, check periodically to watch for status changes	——

Add an "attitude" dimension(power/interest alone is not enough): Positive (supporter) / Neutral (undeclared) / Negative (critic). Mark with "+/−" or create a table tracking current attitude vs desired attitude:

Stakeholder	Power	Interest	Current attitude	Desired attitude
Jane Smith (Account Manager)	High	Low	Neutral	Positive
Joe Bloggs (Product Manager)	High	High	Positive	Positive
Javinder Singh (Technical Architect)	Low	Low	Negative	Neutral

Key principle: People with high power but a negative stance are the most worth investing effort to convert;negative stakeholders with low power and low interest can be temporarily ignored. A stakeholder map is dynamic (leadership changes and shifts in project priorities will alter power/interest levels), so it must be updated regularly with corresponding strategy adjustments. After completing the analysis, develop a management plan (weekly one-on-ones, regular email updates, trackable strategy evaluations).

6.2 Stakeholder Interviews (Stakeholder Interviews 101)

Conversations with people who have a vested interest in the project, to gather information that drives project success (similar to user interviews, but with stakeholders as the subjects).

Why do it: ① Gather context/history (project origins, known constraints, prior attempts; in large organizations, identify political and historical factors to avoid later friction) ② Clarify business goals ③ Align on a shared vision ④ Strengthen support (make the other party feel heard).
When to do it: The earlier the better — at project kickoff, when new stakeholders are brought in, or when the project encounters problems.
How to do it: 5 steps: ① Define objectives (identify concerns/obstacles, technical constraints, competitive landscape, communication preferences) → ② Prepare questions (semi-structured, with a loose framework to guide deeper discussion; ask about role responsibilities, work priorities, success criteria, main challenges, previous similar projects, desired level of involvement) → ③ Build rapport (introduce yourself, state that discussions are confidential and there is no need to please the interviewer, clarify the duration) → ④ Conduct the interview (one-on-one, stay neutral, use open-ended follow-ups such as "Can you elaborate on that?" "Why is this important to you?" "Can you give a specific example?") → ⑤ Summarize and follow up (ask "Who else should I speak to?" to expand your network, send a thank-you email).
Fallback options: If the other party has no time → send core questions via email; for large groups → use surveys (but response rates are low).
How to use insights: ≤5 people: organize themes into a simple document;>5 people: use a systematic method (Thematic Analysis) to tag findings and sort out core themes. Regardless of scale, the insights help optimize research, prioritization, timelines, and resource planning.

6.3 Cross-Team Research Collaboration (Partner with Other Research Teams)

Having the UX team shoulder all user research alone is time-consuming and labor-intensive; cross-departmental collaboration improves efficiency and increases insights.

Identify partner teams: Data analytics teams (behavioral data: traffic, click-through rates, bounce rates), SEO teams (keywords/search intent), customer service teams (pain points, common issues, satisfaction levels).
Deeper advantages: Multi-dimensional data perspectives (UX leans qualitative + these teams lean quantitative), refined user personas, supplementary hypothesis validation, fast decision support (no need to collect data from scratch).
Reciprocity mechanisms: Participate in the other party's research (add questions customer service cares about to interviews), co-develop research plans,publicly recognize the other party's contributions (to build trust).
Strategic ambition: Position the UX team as the central hub for user research across the entire company — build a unified research database, establish research standards, hold regular data sharing sessions, and ultimately drive the organization toward a "user-centric" culture.

Key principle: This is a strategic action one level above "doing a research project" — by integrating cross-departmental data, the UX team upgrades from "executor" to "the organization's user data orchestrator", increasing long-term influence.

6.4 RACI Responsibility Assignment Matrix (Setting UX Roles and Responsibilities)

RACI = a tool to clarify "who does what" at each stage of product development, to anticipate collaboration points and avoid confusion and duplication:

Letter	Role	Meaning
R	Responsible (the doer)	Personally executes the task (can be multiple people); for example, a researcher executes quantitative usability testing
A	Accountable (ultimately answerable)	Reviews and decides whether the task is complete;only one person per task
C	Consulted	Provides advice/expertise (can be cross-disciplinary); for example, a UX manager gives feedback on a research protocol
I	Informed	Kept updated on progress; usually includes stakeholders and leadership (customer service, legal, marketing)

When to use it: After a retrospective (when missing roles or late joiners are identified) + project kickoff phase (filled out and aligned on by the whole team). It is especially effective during strategy setting and discovery phases (who defines vision and goals, who conducts interviews, who does competitive analysis).
How to use it: When assigning responsibilities, go beyond job descriptions and look at skills/time/experience (a PM with interview skills can also take R/A, a UX lead can act as C on an issue); even if they cannot participate directly, UX team members should be marked as I at minimum (to ensure findings influence UX work); people who share R must collaborate and clarify divisions of labor; R/A must ensure C and I are involved at the right times.

Key principle: RACI helps teams form a "design as process" culture, avoiding the assembly-line model of sequential handoffs. Over time, the team will naturally understand how to collaborate and may no longer rely on RACI — but it is an excellent foundation for building open communication.

6.5 UX Responsibilities in Scrum Events (Responsibilities in Scrum Events)

Scrum = an agile method that delivers in phases through short 2–4 week Sprints.UX should participate in all Scrum meetings — otherwise, UX will lose grasp of the big product picture, reduce collaboration efficiency, and cause a disconnect between design and development.

Scrum event	Timing	UX responsibilities
Daily Scrum	~15 minutes every day	Sync on three things (what was done yesterday/what will be done today/what blockers are encountered); use the opportunity to invite developers to design reviews/brainstorms; blockers are resolved with help from the Scrum Master
Backlog Refinement	Mid-Sprint	Use research feedback to help the PM adjust priorities; present sketches/prototypes/preliminary research findings; ensure UI/UX-related tasks have sufficient context, design documentation, and test results (to prevent developer delays from insufficient information)
Sprint Planning	Start of each Sprint	Estimate design workload (using "T-shirt sizes" S/M/L); ensure design tasks are recorded in the backlog (so they are not overlooked); plan user testing (for large studies, suggest reducing Sprint workload so developers can participate)
Sprint Review/Demo	Last one or two days of the Sprint	Support the Product Owner in presenting outcomes and explaining design rationale; collect and categorize feedback ("to be completed/needs clarification/needs persuasion")
Sprint Retrospective	End of each Sprint	Discuss design-development collaboration issues, propose process optimization suggestions (add time for design reviews/user testing), and call out experience details sacrificed to meet deadlines

Key principle: UX work in agile is not just drawing prototypes ahead of time for the next round; more importantly, UX must fully participate in meetings during the current Sprint and maintain close collaboration with developers — meeting participation is key to "maintaining big-picture awareness + ensuring designs are implemented correctly".

Sourced from NNGroup Topics / Organization & Design Process - UX Design Work (Strategy & Roadmap subset, 21 articles). For usability testing and the ten heuristics, see NNGroup Usability Testing and the Ten Usability Heuristics (complete table of 10 heuristics · application to complex applications · user pleasure hierarchy · testing methods: 5-user rule/recruitment/remote testing/task scenarios/step-by-step tasks/attitude vs. behavior/4-step analysis/small-sample error/competitive evaluation); for design process, UX team management, and UX maturity, see NNGroup Design Process and Deliverables (17 articles · exploratory mindset/CSD matrix/project kickoff · wireframes and collaborative sketching/Promptframes · low-fidelity vs. high-fidelity prototypes · design specs/50+ deliverable terms/most commonly used deliverables · expert reviews/workshop facilitation · storyboards · in-process questionnaires) / NNGroup UX Team Organization and Operations (DesignOps 5 structures · centralized/embedded/matrix reporting · MUXI · RACI · roles and responsibilities · 30/60/90 onboarding · UX research plan PET(S) · strong design-thinking teams · team decision quality: confirmation bias/groupthink/thinking by writing · 6-stage UX maturity and biggest challenges · Refine/Remodel/Rebuild) / NNGroup UX Maturity Model (6 stages · 4 factors · living systems perspective). "Building Interactive UX Maps" was originally two articles (guide + case-study steps) and has been merged into the complete 8-step process in §3.1. Images, videos (interactive-maps-recording.mp4, etc.), PDFs, and original files are retained in sources.