This set of notes answers the same core problem that UX practitioners (and product managers who advocate for UX) encounter repeatedly:Good design does not get recognized on its own; you have to make the people who control resources and decision-making power "understand it, trust it, and buy into it." Around this core problem, the 13 articles approach the topic from five angles:
(1) Proving UX value upward— Translating "user language" into "business language." Representative tools: the "If…Then…" formula from How to Sell UX, the Rhetorical Triangle (ethos/logos/pathos), and how to keep UX and Marketing from working at cross purposes. (2) UX metrics— Stop checking the box with vanity numbers no one uses. Representative tools: the workshop for aligning metrics with organizational goals, the three-tier distinction between UX Goals/OKRs/KPIs, and the CASTLE framework purpose-built for "mandatory-use software." (3) Strategy and stakeholder tools— Deciding "who to invest energy in winning over, and where the product stands in the market." Representative tools: stakeholder analysis (Power-Interest Matrix), SWOT. (4) Roadmap fundamentals— Turning a pile of requirements into an executable plan. Representative tools: the 6-step roadmap process, 5 prioritization methods, and how many work hours journey mapping actually takes. (5) Individual career— Selling yourself. Representative tools: the STAR/METEOR interview answer frameworks, and how to tell stories in a portfolio.
Connecting it all in one sentence: Metrics (2) give you ammunition → rhetoric and translation (1) help you hit decision-makers with that ammunition → strategic tools (3) help you choose your battlefield → roadmaps (4) turn consensus into action → career (5) is applying that same set of "proving value" skills to yourself.
1. Proving UX Value Upward: Translating User Language into Business Language
Core mindset: Stakeholders (stakeholder = anyone who has an interest in the project or holds decision-making/resource authority) speak the business language of "cost, revenue, efficiency"; designers speak the user language of "pain points, processes, experience."Nine times out of ten, UX fails to sell not because the solution is bad, but because it is not translated. The three tools in this section are all different forms of "translator."
1.1 How to Sell UX: The "If…Then…" Formula
Fit every design proposal into this four-part structure, which forces you to trace user improvements all the way through to financial/operational metrics:
If we create W (solution), then we will solve X (problem); to achieve this, we need Y (resources), and the result will be Z (business benefit).
| Segment | Must answer | Key discipline | Example |
|---|---|---|---|
| W Solution | What we will do for users | Simple, straightforward, highlight direct user benefits | More intuitive navigation / optimized onboarding / simplified customer service workflow |
| X Problem and opportunity | Where the current pain point is, and which core metric will improve if we fix it | Must be quantifiable, supported by data/user feedback | 60% of users abandon the registration flow mid-process / bounce rate on key pages is too high |
| Y Resource requirements | How much investment is needed (time/budget/team) | List in three categories, quantify as much as possible, avoid vague language | Redesigning navigation requires 25 hours of development + two weeks of user testing; optimizing onboarding requires roughly one month of collaboration across design, development, and PM |
| Z Business benefit | What concrete return the company will get | Tie directly to cost/revenue/satisfaction, make the calculation transparent | See the three examples in the table below |
Three standard calculation formulas for the Z segment (always remember to convert improvements into monetary terms):
| Improvement | Conversion logic | Business benefit |
|---|---|---|
| Simplify customer service workflow | Save $5 per call eliminated × projected 1000 fewer calls | $5000 cost savings |
| Optimize user onboarding | Registration success rate +10% | $2000 additional monthly revenue |
| Redesign navigation | Bounce rate -20%, retention increases | Approximately $50,000 increase in customer lifetime value (CLV) |
Why: When stakeholders decide whether to approve resources, they are not looking at "whether the user experience is good," but at "what this investment will return." Stating Z clearly in monetary terms is equivalent to calculating ROI for them, which drastically lowers their decision-making cost. Counterexample: Only saying "The navigation is messy, the experience is bad, we should redo it" — without numbers for X, without financial conversion for Z — is equivalent to asking someone who reviews budgets to vote based on aesthetics, and it will most likely be shelved.
1.2 The Rhetorical Triangle: ethos / logos / pathos
Aristotle’s persuasion model, used in UX to structure a communication aimed at "asking for resources."The triangle cannot stand if any side is missing: Only talking about data (logos) feels cold; only telling stories (pathos) feels unprofessional; only citing credentials (ethos) feels empty.
This article appeared in the original source material in two versions(same NNG article, identical content, merged into one here).
| Side | Chinese term | What it is | How to do it | Notes / counterexamples |
|---|---|---|---|---|
| Ethos | Ethos (Credibility) | Making people believe "you are capable of handling this" | Highlight credentials ("I’ve spent 3 years doing UX optimization for this platform and led multiple successful projects"); if you lack authority yourself, cite authorities ("According to NN/g research, simplifying checkout significantly reduces cart abandonment rate") | False citations or unclear sources will directly destroy credibility; citations must be real and verifiable |
| Logos | Logos (Logical appeal) | Using data and rational reasoning to prove the solution solves a real problem | Present quantitative data (user research/analytics/customer feedback); provide industry or competitor comparisons; frame "user value" as tied to "business value" from the other party’s perspective | Recommended phrasing: "If we [do something], we can solve [user problem], which will in turn bring [business value]" |
| Pathos | Pathos (Emotional appeal) | Building an emotional connection with the other party to motivate support | Tell a specific story of a user encountering frustration; show video clips/screenshots of users struggling;Invite stakeholders to participate in user testing themselves, so they can see the problem firsthand | Turn abstract research findings into "visible people suffering"; empathy drives action more effectively than numbers alone |
Integrated case example (using all three sides to persuade the marketing lead to redesign the checkout flow and reduce cart abandonment rate):
- Ethos: State that you have more than 3 years of e-commerce UX optimization experience and have conducted usability testing and customer interviews;
- Logos: Present the data — "Our checkout abandonment rate is 60%, while competitors are at only 30%"; structure the argument "Simplify checkout → reduce friction → increase purchase completion rate → directly increase revenue";
- Pathos: Show a video clip of a user abandoning a purchase because the form is too complex, and invite the lead to join the next user testing session.
Why: For the same set of facts, structuring them as "credible + evidence-based + resonant" is far more likely to win resource approval than single-point bombardment. This naturally dovetails with the "If…Then…" formula in 1.1 — the formula provides the content for the logos side, while ethos and pathos serve as the packaging.
1.3 UX & Marketing: Not enemies, but naturally in tension
In many companies, UX and Marketing do not see eye to eye. First recognize that they are very similar, but differ in target audiences and methodologies, then use 4 tactics to get them to collaborate instead of expending energy on internal conflict.
Similarities and differences:
| Dimension | Marketing | User Experience (UX) |
|---|---|---|
| Focus | Promotion and sales: understanding the market, attracting prospects, increasing engagement | Designing the overall experience of all touchpoints (e.g., app/website/physical store/advertising) between users and the company, using a human-centered approach to help users achieve their goals efficiently |
| Common ground | Both are user-centered, both study behavior; methods overlap (interviews/surveys/fieldwork/focus groups); both prioritize customer retention | Same as left |
| Retention path | Attract users through incentives (discounts) | Attract users through seamless interactions to build brand trust |
| Target audience | May be buyers (parents, schools) | Are actual end users (students) |
Three tensions (root causes of conflict):
- Marketing elements weaken experience— Pop-ups, feedback forms, and promotional ads interrupt user flows and increase interaction cost;
- Marketing goals intrude on UX research— Forcing promotional evaluation questions into user testing leads to biased responses and lower research quality;
- Methodology conflict— Market research mostly happens before product development and relies on self-reporting; UX research spans the entire lifecycle and relies on observed behavior; when the two are misaligned, marketing methods are misused to test interface design.
4 collaboration strategies:
| Strategy | How to implement |
|---|---|
| 1 Improve communication, avoid silos | Maintain transparency with monthly updates; educate each other on respective research methods and goals |
| 2 Share research insights | Marketing provides market data (overall user segment trends); UX provides initial user feedback (e.g., how new promotions affect users) |
| 3 Create shared user personas | One shared persona that reflects both "existing users + potential buyers" to avoid misaligned goals |
| 4 Align KPIs | Adjust KPIs to encourage collaboration: UX improvements can lift conversion rates, while marketing-acquired customers can provide new design opportunities for UX |
Counterexample: The UX team blocks all marketing requests outright in the name of "pure experience," or Marketing forces promotional satisfaction questions into usability testing surveys — the former makes Marketing feel UX ignores business needs, the latter contaminates research data, and both sides lose.
2. UX Metrics: Stop Checking the Box with Vanity Numbers No One Uses
Core mindset: The sole purpose of metrics is to help people make decisions. A metric is a liability if no one acts on it or it does not align with company goals, no matter how good it looks. The three tools respectively address: how to choose the right metrics (2.1 Workshop), how many layers metrics have (2.2 Goals/OKRs/KPIs), and how to measure mandatory-use software (2.3 CASTLE).
2.1 Aligning UX Metrics with Organizational Goals: A Workshop
Three Common Pitfalls(Root causes of UX teams choosing the wrong metrics):
| Pitfall | Symptom |
|---|---|
| Vanity Pitfall | The numbers look good but are useless — NPS/satisfaction scores are high, yet users still churn |
| Silo Pitfall | UX defines metrics behind closed doors, without aligning with product/data/customer service/management |
| Noise Pitfall | Too much messy data that cannot support decision-making |
Solution: Run a Collaborative UX Metrics Workshop——
- Who attends: UX, product, data, customer service, management, preferably all responsible for the same product;
- Duration: 3–4 hours;
- Preparation: Send a survey in advance asking 4 things — what are your team's main goals and KPIs / how does UX affect these goals / what difficulties do you encounter when evaluating UX / which metrics do you hope to track.
Workshop Steps:
- Clarify the purpose—— The facilitator poses the question "Are the things we are measuring really important?" and gives counterexamples (usability scores went up but conversion rates went down / satisfaction went up but customer service costs did not drop);
- Connect metrics to company goals—— Participants share each team's goals and metrics, categorize them by revenue/retention/cost reduction, and compare against existing metrics to find those that "do not align";
- Find UX contributions and gaps—— Answer one by one: how UX helps achieve goals (e.g., optimizing the help center to enable user self-service and reduce customer service costs), what data can prove it (tests show 70% of users can self-serve after optimization, compared to only 40% before), what is missing from current metrics (ticket counts are recorded, but not whether users tried self-service first), which data is collected but unused (satisfaction scores collected after every customer service interaction are never analyzed, nor linked to help center improvements);
- Define and rank "the truly important metrics"—— Distribute UX metric reference cards, and apply three screening questions to each metric one by one: Can it reflect UX's actual contribution to company goals? Is it trackable? Will management recognize it and make decisions based on it?
- Embed metrics into usage scenarios—— Clarify who is responsible for each metric, how often it is updated, in which meetings (sprint review/OKR meetings) it is discussed, how to use it to prioritize work, and adjust it as circumstances change.
8 UX Metric Flashcards:
| Metric | What it measures | Goal linkage (why management cares) | Research methods |
|---|---|---|---|
| Conversion Rate | Proportion of users who complete a target behavior (register/purchase/donate) | Directly drives revenue, customer acquisition, and growth | Data analysis, A/B or multivariate testing, cohort analysis |
| Completion Rate | Proportion of users who successfully complete a task along the defined path | Higher rate → fewer drop-offs in self-service flows → reduced reliance on human support | Funnel/event analysis, A/B testing, cohort analysis |
| Time on Task | Average time to complete a task | Shorter time → simpler process, cost savings | Quantitative usability testing, data analysis, benchmark comparison studies |
| Success Rate | Proportion of users who achieve the expected task outcome (regardless of path) | Higher rate → reduced costly support and rework | Quantitative usability testing scored on a "pass/fail" basis |
| SUS (System Usability Scale) | 10-item standardized questionnaire, scored 0–100 | Validates usability improvements, builds long-term benchmarks | Post-test questionnaire; cross-version/competitor benchmark comparison |
| Satisfaction Rate | User ratings of the experience (e.g., 1–5) | Higher score → improved loyalty and reuse | Feedback surveys, post-task questionnaires, immediate post-interaction feedback |
| Confidence Rate | Users' self-reported confidence in completing a task | Higher confidence → less uncertainty and frustration | Post-task rating (1–5); collected alongside satisfaction |
| True/False Knowledge Check | Whether users understand content or instructions | Ensures content is accurate, compliant, and safe | Post-test/post-task questions, post-training quizzes, questionnaire comprehension items |
What to do when someone insists on using the "wrong" metric: Ask three questions — What user experience does this metric reflect? Can it tell us where to improve? Can it be improved through design or research? If you cannot persuade them,try both metrics at the same time to see which is more useful, then ask someone who understands data to check whether the final metric is measurable and reasonable.
2.2 UX Goals vs OKRs vs KPIs: Three Layers, Do Not Mix Them Up
| Layer | What it is | Nature | Question it emphasizes | Example |
|---|---|---|---|---|
| UX Goal | A qualitative vision that defines success criteria for experience, derived from the corporate vision and mission | Qualitative, non-quantified, high-level direction | "What do we want to achieve" | Provide an intuitive, engaging omnichannel user journey |
| OKR(Objectives & Key Results) | OKR | Qualitative objective + quantified key results | "How do we achieve it" | O: Improve mobile interaction experience; KR: Grow monthly active users (MAU) by 15% in Q4 |
| KPI(Key Performance Indicator) | KPI | Quantitative, tracked over time | "How are we doing right now" | Increase annual customer cross-channel journey completion rate from 25% to 40% |
An end-to-end example: UX Goal "Intuitive, engaging omnichannel experience" → OKR "Improve mobile interaction (O) / Q4 MAU +15% (KR)" → KPI "Journey completion rate 25%→40%".Core principle: The vision sets direction, OKRs define plans, KPIs monitor progress; the three cascade from high level to implementation; do not treat KPIs as OKRs (KPIs are an ongoing pulse, OKRs are time-bound sprint goals), and do not let UX Goals remain forever at the slogan level without being broken down further.
2.3 CASTLE: A Measurement Framework Specifically for "Mandatory-Use Software"
Background: Google's HEART framework (Happiness, Engagement, Adoption, Retention, Task success) is suitable for consumer products. But for mandatory enterprise/work software (hospital medical systems, government e-government systems, ERP, internal work platforms), users have no choice — metrics "based on voluntary use" such as engagement, adoption rate, and retention rate become distorted: users have to use it, so high retention does not mean it is easy to use. CASTLE fills this gap.
Six Dimensions of CASTLE:
| Dimension | Chinese | What it measures | Measurement method | Improvement goal |
|---|---|---|---|---|
| C ognitive Load | Cognitive Load | The mental effort required when users use the product (complex menus, memorizing data entry) | Questionnaire scales to assess perceived complexity and points of confusion | Make operations more intuitive and reduce mental burden |
| A dvanced Feature Usage | Advanced Feature Usage | Whether users can discover and use efficiency-enhancing additional features (batch processing, automation) | Data analysis to record advanced feature usage frequency, compared against overall usage | Increase adoption rate through guidance/demonstration |
| S atisfaction | Satisfaction | Overall feelings about the software (not only whether tasks can be completed, but also whether it is pleasant and unobstructed) | Questionnaires such as NPS, user feedback | Reduce frustration and strengthen positive emotions |
| T ask Efficiency | Task Efficiency | The time or number of steps required to complete a task | Usability testing to record time spent and steps, compared against benchmarks | Reduce redundant steps and optimize layout |
| L earnability | Learnability | How quickly new users can get started and complete tasks effectively | Quantitative usability testing to observe new users' time spent and pain points | Shorten the learning curve and reduce training costs |
| E rrors | Error Rate | User misoperations + system errors | Data analysis to record errors and failures, or observe deviations during testing | Reduce errors → boost confidence and improve data quality |
How to Choose Between CASTLE and HEART:
| HEART | CASTLE | |
|---|---|---|
| Applicable to | Consumer-facing products (e-commerce, social media) | Mandatory work software, forced-use tools (ERP, government systems) |
| Core focus | Emotional experience, engagement, retention | Productivity, task efficiency, cognitive load, errors |
Counterexample: Using "retention rate" to measure the success of a government e-government system — users must use it, so retention is naturally 100%, making this number meaningless; instead, use CASTLE's task efficiency, satisfaction, and cognitive load.Core principle: The two frameworks are not substitutes but complements; choose based on "whether users have a choice."
III. Strategy and Stakeholder Tools: Choose Your Battlefield, Win Over Key People
Shared core principle: These two tools are "maps" — stakeholder analysis (3.1) helps you see "who to invest your energy in," and SWOT (3.2) helps you see "where the product stands in the market, where to attack and where to defend." Both can easily devolve into subjective guesswork, so both emphasize using real data to reduce bias.
3.1 Stakeholder Analysis: Power-Interest Matrix + Attitude Dimension
First identify (who is a stakeholder = anyone who has an interest in the project or needs to collaborate): internal (CEO, marketing director, PM, direct supervisor) + external (customers, partners). Two identification questions:Who is interested in the project? Who has power/influence/control over the project?
Then categorize: Mendelow Power-Interest Matrix (vertical axis: power low→high, horizontal axis: interest low→high, four quadrants):
| Quadrant | Strategy | How to do it | Example |
|---|---|---|---|
| Manage Closely | Close attention + active communication | Prioritize relationship-building, strive to turn them into project supporters | CEO with high power and high interest in the project |
| Keep Satisfied | Ensure their interests are met | Consult their needs, do not let the project affect their work and cause problems | Senior executives with high influence but low interest |
| Keep Informed | Regularly update progress | Invite them to participate in user research, send relevant information | Colleagues who are interested but have low power |
| Monitor | Low priority, observe periodically | Check in regularly to respond to role changes | Department employees with low power and low interest |
Add an "attitude" dimension (positive support / neutral / negative opposition): mark each person with + / - in the matrix, or use a "current attitude vs. desired attitude" table:
| 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 |
Core principle/Counterexample:Converting a high-power opponent to neutral/support is more valuable than continuing to preach to those who already support you—— don't waste time "preaching to the choir." Dynamism: When leadership or the project changes, power and interest can shift dramatically,so the map must be updated regularly. For high-power/high-interest stakeholders: explain basic UX concepts and emphasize UX's ROI. After analysis, define a communication plan (frequency: weekly 1:1s or biweekly emails; content: adjusted according to their power/interest/attitude), and continuously improve based on feedback.
3.2 SWOT Analysis: See Offense and Defense Clearly with Four Quadrants
SWOT = Strengths / Weaknesses / Opportunities / Threats, formed by the intersection of two axes:
| Axis | Meaning |
|---|---|
| X axis | Whether the factor is helpful or harmful |
| Y axis | Whether the factor is internal or external |
| Category | Definition | Example |
|---|---|---|
| Strengths | Internal, favorable: our unique value proposition relative to competitors | Aspects users are satisfied with / factors that strengthen brand loyalty / unique team skills or resources |
| Weaknesses | Internal, unfavorable: shortcomings relative to industry standards | High-frequency items in negative user feedback / gaps in funding or technical capabilities / performance lagging behind competitors |
| Opportunities | External, favorable: exploitable paths for growth/improvement | Emerging industry trends / innovative practices not yet widely adopted / underutilized market demand |
| Threats | External, unfavorable: external risks that may harm success | Economic uncertainty / potential competitor entry / changes to infrastructure or regulations |
Construction process: First list internal factors (strengths + weaknesses), then identify external factors (opportunities + threats), and finally visualize them in the four-quadrant framework to facilitate discussion.
The biggest pitfall — subjectivity: SWOT is often done in meetings/workshops, and is easily skewed by groupthink and the HiPPO effect (HiPPO = Highest Paid Person's Opinion), leading to overly optimistic results. 3 ways to improve objectivity: ① Support with real data (satisfaction metrics such as NPS, SUS, CSAT); ② Incorporate employee feedback as a basis for internal factors; ③ Use STEEPLE analysis (Social/Technological/Economic/Environmental/Political/Legal/Ethical) to expand understanding of external opportunities and threats. Practical application: Competitive research (user surveys, industry trends) can intuitively demonstrate gaps relative to competitors and provide key inputs for SWOT; use clear criteria + objective data during discussions to reduce bias.
IV. Roadmap Basics: Organizing Requirements into an Executable Plan
Shared Core Principle: A roadmap is not a Gantt chart, nor a table of committed dates; it is a dynamic carrier of consensus on "which problems we intend to solve, in what priority, for whom, and in exchange for what business outcomes". Section 4.1 is the process skeleton, 4.2 is the toolbox for the "prioritization" step within it, and 4.3 provides a frequently underestimated work-hour benchmark (for journey maps).
4.1 6 Steps to Roadmap Development
| Step | What to Do | Key Points |
|---|---|---|
| 1 Define Goals | Define the purpose(raise awareness / cross-disciplinary alignment / show stakeholders problems to be solved / schedule future work / develop UX vision or identify MVP), define the scope(product / discipline / specialty), and form the core team(cross-disciplinary + secure stakeholder support) | First clarify "who this map is for, and what decision you want them to make" |
| 2 Gather Inputs | Extract problems to be solved from previous roadmaps, product roadmaps, user journey maps/service blueprints, support logs/customer feedback, and quantitative and qualitative research | When data is limited, interview stakeholders to fill gaps |
| 3 Create Themes | List candidate problem inventory → cluster with affinity diagrams to find patterns → for each theme, specify three things | Three-part set: Beneficiary (end users / internal employees / stakeholders) + Need (problem to be solved) + Business goal (outcome after completion, e.g., revenue increase / user growth) |
| 4 Prioritize Themes | Select 2 criteria each for user-facing and business-facing dimensions to rank themes (see below) | Pick 2 user-facing and 2 business-facing criteria to avoid single-dimensional bias |
| 5 Visualize and Share | Choose fidelity based on goals and audience | Low fidelity(spreadsheet/whiteboard) for internal teams;High fidelity(clear visuals + context + version number) for stakeholders; when sharing, provide context and specify what kind of feedback you want (resource support or requirement alignment) |
| 6 Update Regularly | A roadmap is a dynamic tool | Update completed themes monthly, adjust priorities; add details;Retain old versions to demonstrate progress |
Example Prioritization Criteria for Step 4(select 2 user-facing + 2 business-facing):
- User-facing: Impact on users / Percentage of affected users / Severity of pain points / Availability of alternatives;
- Business-facing: Alignment with company strategy / Market differentiation / ROI / Effort (time + cost estimate).
4.2 5 Methods for Roadmap Prioritization
To make the "ranking" in Step 4 concrete, there are 5 mature tools; choose based on team culture and task volume:
| Method | How to Calculate/Categorize | Best For | One-Sentence Mnemonic |
|---|---|---|---|
| Impact-Effort Matrix Impact–Effort | Two-dimensional four-quadrant:Quick Wins(high impact, low effort, prioritize)/ Big Bets(high impact, high effort, validate cautiously, can become competitive advantage)/ Money Pits(low impact, high effort, do not invest)/ Fill-ins(low impact, low effort, limited value) | Scenarios requiring fast collaborative ranking and shared visualization to build consensus | Grab the "high impact, low effort" quick wins first |
| Desirability-Feasibility-Viability Scorecard(IDEO) | Score 1–10 on three criteria, sum for ranking: Feasibility (can it be technically built)/ Desirability (how much users need it, unique value)/ Viability (business value and long-term sustainability) | Complex projects requiring synthesis of multiple factors; criteria can be adjusted as needed | Want vs Can Build vs Can Sustain |
| RICE(Intercom) | Priority = (Reach × Impact on users × Confidence in estimate) ÷ Effort | Engineering-oriented teams, large task volumes requiring detailed evaluation | Multiply three, divide by one to get the score |
| MoSCoW | Four categories: Must Have (project fails without it)/ Should Have (important but not essential)/ Could Have (nice to have)/ Will Not Have (not doing this cycle); team weighted voting (each person gets 1/2/3 point votes) to categorize | Projects with clear timeframes (e.g., short-term agile planning) | Must/Should/Could/Won’t (MoSCoW is not the city of Moscow) |
| Kano Model | Categorize into four types by "feature implementation level" (-2 to +2) × "user satisfaction" (-2 to +2): Attractive / Performance / Indifferent / Must-be; ranking order:Performance > Must-be > Attractive > Indifferent | User-centric priority discussions, especially in environments with strong political or traditional development cultures | Skipping Must-be features costs points; adding Attractive features is a pleasant surprise |
How to Choose (Decision-Oriented): Need speed and immediate team consensus → Impact-Effort Matrix; many tasks, engineering-leaning team, need calculability → RICE; have hard deadlines, need to clearly define what will definitely not be done in the current iteration → MoSCoW; need to balance technical, user, and business perspectives → IDEO Scorecard; need to reverse the political dynamic of "the boss deciding features on gut instinct" and bring discussions back to user satisfaction → Kano.Counterexample: Forcing the RICE formula in a highly politicized team where HiPPOs call the shots — numbers will be artificially manipulated; instead, Kano, which frames the conversation around "is this a must-have or a delightful surprise for users," is better able to break the deadlock.
4.3 How Long Does One Journey Map Actually Take? (Work-Hour Benchmark)
A survey of 343 practitioners provides a benchmark for estimating the time and cost investment of a journey map.
Average Work Hours Across Five Phases:
| Phase | Average Work Hours |
|---|---|
| Securing support or resources | 8.9 hours |
| Collecting internal stakeholder data | 13.7 hours |
| Conducting user/customer research | 20.6 hours |
| Synthesizing research insights | 16.4 hours |
| Producing the journey map artifact | 14.2 hours |
| Total | 73.8 hours ≈ two weeks of full-time work (at 40h/week) |
Comparisons and Conclusions:
- Agencies vs In-House Teams: In-house teams spent 79.8h, slightly higher than agencies’ 71.7h; agencies spent more on "producing the artifact," while in-house teams invested more in the "research phases"; both spent roughly 20 hours on user data collection (a standard investment).
- Large Companies vs Small Companies: Large companies (≥500 employees) averaged 87h vs small companies (<500 employees) at 64.9h; large companies were slightly higher across all phases (due to more complex approval processes and formal policies). It is worth noting:Regardless of company size, "securing support" takes substantial time — indicating company size ≠ high UX maturity; educating stakeholders and promoting projects is a universal necessity.
- Research-First vs Assumption-First: Research-first (conduct user research before synthesis) did not significantly increase total time, but provided more actionable research data; assumption-first (cross-functional workshops building assumption maps from existing knowledge) actually had slightly higher total time (not statistically significant).Skipping preliminary user research does not save significant time, and may instead make subsequent work more time-consuming due to insufficient data.
Core Principle: Journey maps are often criticized as "too expensive and too slow," but their value in aligning stakeholders and identifying experience gaps and opportunities usually justifies the investment; using this benchmark for expectation management (73.8h ≈ two weeks) and resource requests is more reliable than guessing it can be "done in a few days."
V. Personal Career: Applying "Proving Value" to Yourself
Shared Core Principle: Interviews and portfolios are essentially also about "proving value to stakeholders (hiring managers)" — they equally require logos (clearly explaining what you did and what the results were) and pathos (telling stories that people remember).A portfolio gets you the interview, but landing the offer depends on communication skills, especially storytelling.
5.1 Interviews: Use STAR for Behavioral Questions, METEOR for Situational Questions
Two types of questions (per research: 80% of UX teams use behavioral questions, 63% use situational questions):
- Behavioral Interview Questions: Ask you to share past experiences, using "behavioral consistency" to predict future performance. Examples: "Tell me about a time you compromised on a feature design with the development team" "Describe a time you presented research insights to stakeholders and the outcome."
- Situational Interview Questions: Present hypothetical scenarios to test problem-solving and decision-making logic. Example: "You just joined an agile team and find that design is led by the PM and you haven’t been invited to meetings — what would you do?"
- Why Use These Two Types: Validity (strong predictive power for ability and potential), fairness (avoids bias from brain teasers), consistency (standardized evaluation of good and bad answers).
STAR for Answering Behavioral Questions:
| Letter | Meaning | Key Points | Example (compromising on feature design with development) |
|---|---|---|---|
| S Situation | Situation | Briefly describe background: company, role, constraints | In my previous job as a UX designer, the development team encountered technical issues and faced tight deadlines |
| T Task | Task | Your specific responsibilities and goals | Balance business requirements and user research to deliver a feasible new design within two weeks |
| A Action | Action | Describe what you did in chronological order | Convened a design workshop with the product owner and developers, produced Figma wireframes after generating solutions, and planned follow-up usability testing |
| R Result | Result | Quantify outcomes and emphasize teamwork | The design was delivered early, the team completed the feature on schedule, and subsequent testing found no critical issues |
What If You Lack Experience: Talk about similar experiences (family/school project management), explain what you learned from failures, and demonstrate self-reflection and improvement ability.
METEOR for Answering Situational Questions:
| Letter | Meaning | Key Points | Example (not invited to design meetings) |
|---|---|---|---|
| M Muse | Mull | Ask for a moment to think through the key attributes of the problem | Request time to consider the root cause of the issue |
| E Enquire | Enquire | Ask the interviewer clarifying questions about ambiguous points | Ask whether the team has UX collaboration experience and who is responsible for meeting scheduling |
| T Theorize | Think (Hypothesize) | Make reasonable assumptions based on what is known | Assume the team is unfamiliar with UX processes and trust needs to be built |
| E Endeavor | Execute (Action) | Describe your concrete action plan | Set up a 1:1 with the team lead, share UX methodology, and propose piloting usability testing on high-risk features |
| O Outcome | Outcome | Expected benefits and how to measure them | Win trust → secure more UX involvement → improve product quality |
| R Recap | Recap | Concise review of your thinking and answer | Summarize your hypothesis, action plan, and expected results |
10-Step Exercise to Improve Answers with Storytelling: ① Find a trusted friend familiar with UX to do a mock interview → ② Set up a 30-minute online interview → ③ Prepare 5 questions covering common UX challenges → ④ Record the entire session → ⑤ Afterward, collect feedback and adjust your answers and on-camera performance → ⑥ Transcribe the audio and organize it into STAR/METEOR format → ⑦ Check and fill in details to improve coherence → ⑧ Do a second mock interview (you may reference your optimized answers) → ⑨ Compare the two videos to summarize improvements → ⑩ Organize your answers into reusable materials.
Why: Research shows that answering behavioral questions with stories significantly improves interviewer ratings, but most job seekers do not have a habit of storytelling — so deliberate practice is required.
5.2 UX Portfolio: Interview Preparation
A good portfolio follows the case study structure: high-level project details + your role and activities + final design screenshots/photos, research plans, and other materials.
| Don't | Do |
|---|---|
| Too much detail— hiring managers will skip important information during initial screening; save deep discussion for the interview | Tell the story behind the project— pick 1–2 of the most important projects to cover in depth (e.g., how you adjusted the app when trying new technologies, how you overcame tough challenges) |
| Only do "show and tell"— don’t repeat content hiring managers already saw during screening, don’t only talk about deliverables and the final design | Show process and decisions— let the other person see how you think, how you found solutions from challenges, and how you contributed within the team |
| Demonstrate confidence and professionalism— prepare clear case studies so interviewers understand how you bring value to a team |
Core Principle: The portfolio is the "door-opener" (to win interview opportunities); communication and storytelling during the interview are what "close the deal" (land the offer). The two steps have different roles — the screening stage requires conciseness (letting people quickly grasp key skills), while the interview stage requires depth (clearly explaining the decision-making process).
Sourced from NNGroup Topics / Managing UX Teams - Managing UX Teams (upward influence and career subset, 13 articles; duplicate versions of the original rhetorical triangle article have been merged into one). For remaining topics under "Managing UX Teams," see NNGroup UX Team Organization and Operations (DesignOps 5 Structures · Centralized/Embedded/Matrix Reporting · MUXI · RACI · Role Responsibilities · Onboarding 30/60/90 · UX Research Plan PET(S) · Strong Design Thinking Teams · Team Decision Quality: Confirmation Bias/Groupthink/Written Thinking · UX 6-Level Maturity and Biggest Challenges · Refine/Remodel/Rebuild); for the UX maturity model, see NNGroup UX Maturity Model (6 Stages · 4 Factors · Living Systems Perspective); for product and UX collaboration, see NNGroup Product and UX Collaboration (Empirical Evidence of PM×UX Responsibility Disagreements · Root Causes of Overlapping Work · PM Role Model · RACI Division of Labor · Five Collaboration Recommendations · UXers Thinking Like Product Leaders · PLG · Glossary); for analytics and quantitative metrics, see NNGroup Analytics & Metrics (Choosing the Right Metrics/Conversion Funnels/Statistical Significance and Confidence Intervals/Four Steps to UX ROI/Sampling and Confounding/Triangulation/Vanity Metrics/Benchmarking). The metric definitions in Sections 2.1/2.3 of this article and 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/Task Scenarios/Step-by-Step Tasks/Attitude vs Behavior/4-Step Analysis/Small Sample Error/Competitive Evaluation) complement each other in terms of usability testing methods. Images (schematic diagrams of each matrix, metric flashcard PDFs, portfolio videos) and original files are retained in sources.
Sources and Related Materials
- NNGroup UX Team Organization and Operations (DesignOps 5 Structures · Centralized/Embedded/Matrix Reporting · MUXI · RACI · Role Responsibilities · Onboarding 30/60/90 · UX Research Plan PET(S) · Strong Design Thinking Teams · Team Decision Quality: Confirmation Bias/Groupthink/Written Thinking · UX 6-Level Maturity and Biggest Challenges · Refine/Remodel/Rebuild)
- NNGroup UX Maturity Model (6 Stages · 4 Factors · Living Systems Perspective)
- NNGroup Product and UX Collaboration (Empirical Evidence of PM×UX Responsibility Disagreements · Root Causes of Overlapping Work · PM Role Model · RACI Division of Labor · Five Collaboration Recommendations · UXers Thinking Like Product Leaders · PLG · Glossary)
- NNGroup Analytics & Metrics (Choosing the Right Metrics/Conversion Funnels/Statistical Significance and Confidence Intervals/Four Steps to UX ROI/Sampling and Confounding/Triangulation/Vanity Metrics/Benchmarking)