This batch of content covers two sides of the same coin:How to "set up" a UX team (organizational structure), and how to get this group of people to "make the right decisions" (operations and decision quality). It does not teach you how to draw interfaces; it teaches you how to manage people, arrange seating, define responsibilities, hire and onboard people, create research plans, and how to prevent a room full of smart people from collectively making stupid decisions.
One main thread runs through the entire piece:There is no single best structure, only a structure that "matches your current situation"— company culture, size, UX maturity, and the volume of UX work required determine what works. Therefore, all "models/matrices/processes" in this article are options to "select as needed", not something to "copy verbatim from a big tech company".
The full text is divided into seven sections: ① How to structure the team (5 DesignOps structures · 3 design team structures · reporting lines · recommended MUXI model) → ② How to divide responsibilities (RACI) → ③ How to hire people and get them up to speed (onboarding + 30/60/90 days) → ④ How to plan research (PET(S)) → ⑤ How to use design thinking to bind the team together → ⑥ How to prevent the team from collectively making wrong decisions (Confirmation Bias · Groupthink · Ink Thinking) → ⑦ The biggest challenges for UX in organizations and how to solve them (6 levels of maturity · Refine/Remodel/Rebuild).
1. How to structure the team: Structures · Reporting lines · Recommended model
1.1 The 5 team structures of DesignOps (who does the "operational odd jobs")
First, term explanation:DesignOps (Design Operations)= The set of work that manages the "pipeline" of the design team — selecting tools, defining processes, overseeing hiring and onboarding, maintaining design systems and research repositories, so that designers can focus on designing instead of fire-fighting schedule conflicts every day. The 5 structures below are arranged by "who does DesignOps, how many people do it, and whether it is independent".Key reminder: This is not a maturity ladder (it does not mean later structures are more advanced); these are options that "fit the current situation".
| Structure (EN / CN) | What it is | Applicable scenarios | Main challenges |
|---|---|---|---|
| Scattered | There is no formal DesignOps role; operational odd jobs are handled by design managers on top of their core duties | Low UX maturity / limited resources / just starting to experiment with DesignOps | Inconsistent tools and processes across teams; adds burden to design managers and often goes unrecognized |
| Solitary | 1 full-time DesignOps lead supports multiple designers/small teams | Team scaling from small to midsize; DesignOps is recognized but resources are limited | The single person is prone to overload; must continuously prove their value to secure more support |
| Specialized | Multiple full-time DesignOps staff, each responsible for one area (tools / processes / hiring and onboarding) | DesignOps has shown initial results and needs to expand to cover more demands | Roles must collaborate closely to avoid working in silos; coordination with horizontal operations such as PeopleOps/DevOps is required |
| Distributed | DesignOps specialists are assigned to each design team to provide embedded day-to-day support | Large organizations / rapidly scaling design teams | Need to balance priorities between "single-team support" and "global optimization"; strong leadership is required to ensure strategic alignment |
| Elevated | DesignOps becomes an independent team/department, providing centralized tools and resources for the entire design organization (design systems, research repositories, culture building) | The design team has achieved stable cross-team alignment and needs higher-order resources | Do not become a "top-down imposed ineffective process"; collect feedback from the design team; senior leadership needs to prioritize key DesignOps tasks |
Core principle: Select a structure based on "what is the most painful operational problem right now", not "which one other companies use". Why: NNGroup explicitly states that this set is not a maturity model— a small, lean team may work perfectly well with Scattered; forcing Elevated will instead breed bureaucratic processes disconnected from frontline work. Counterexample: A team with low maturity and tight resources directly copies a big company's independent Elevated DesignOps department, ending up with a department that "does not understand frontline work and issues processes top-down", and designers only feel there is an extra layer of approval.
1.2 The 3 structures of design teams (who reports to whom) — 550-person survey
If section 1.1 covers "who is responsible for operational odd jobs", this section covers "which line in the organization designers themselves sit on". Based on a survey of 550+ UX/design professionals, the distribution of the three structures is fairly even (indicating each has pros and cons, and none dominates):
| Structure | Share | What it is | Advantages | Disadvantages |
|---|---|---|---|---|
| Centralized | 29% | All designers belong to one core team and report to the same core manager | Efficient resource sharing, strong design consistency | May lack deep understanding of specific products/businesses |
| Decentralized | 32% | Designers are embedded in cross-functional teams, corresponding to specific product/business lines | More focused on and knowledgeable about specific domains | Prone to resource waste / lack of unified design standards |
| Matrix | 31% | A hybrid of centralized and decentralized: designers are managed by a core manager and also report to product/business line managers | Balances standardization and domain focus | Role conflict under dual management ("who to listen to") |
Alignment dimension: In decentralized structures, designers mostly align by "product" or "internal department/business line"; alignment by "user type" or "customer journey stage" is rare (because design teams tend to mirror the existing organizational structure— which may in turn limit flexibility and innovation).
Reporting lines: The survey shows design teams primarily report to ① Product Management and ② C-suite (company senior leadership); reporting to IT / marketing / engineering / operations is rare. The relatively high proportion reporting to the C-suite indicates that the importance of design is being recognized by senior leadership.
The most counterintuitive conclusion:There is no strong correlation between team structure and reporting relationships, and "whether the team can significantly influence business metrics (usability/satisfaction/revenue)". In other words —Structure itself does not determine success or failure; the ability to efficiently achieve goals does. Core principles: ① There is no best model, do not blindly copy others' successful experiences; ② Choose a structure that allows the team to fully perform at present, while remaining open to future adjustments; ③ Focus on results (support for business goals), do not fetishize structure.
1.3 Recommended structure: Managed-UX Integration model MUXI
The three structures in 1.2 above each have hard flaws; NNGroup recommends a solution that "plays to each strength" —MUXI (Managed-UX Integration). It first answers several classic dilemmas:
- Should UX report to product managers (PMs)? —No.
- Should all UX be centralized under one team? — It is possible, but the risk is UX becomes a "miscellaneous support team" disconnected from product rhythm.
- Should a matrix structure be used for dual reporting of UX? — It easily leads to "not knowing who to listen to", unclear accountability, and UX becoming a weaker party.
The core breakdown of MUXI = embedded for work + centralized for management:
- Embedded work: UX members deeply participate in the daily rhythm of product teams (standups, planning, reviews), working side by side with PMs and developers.
- Centralized Reporting: All UX staff report only to UX leadership for performance, training, and career development,and do not report to product teams. PMs can provide suggestions but cannot directly manage UX; when there are priority disagreements, UX leadership and product leadership negotiate,so that designers are not left to survive in the crack between two bosses.
| Model | Reporting structure | Problems |
|---|---|---|
| Centralized | All UX report to UX leadership | UX easily becomes an ad-hoc support team, disconnected from product rhythm |
| Matrix | UX reports dually to UX + PM | Priority conflicts, ambiguous accountability, UX as weaker party |
| Decentralized | UX is fully affiliated with respective product teams | Lack of professional community, limited growth space |
| MUXI (Recommended) | UX reports only to UX leadership, but is long-term embedded in product teams | Maintains professional consistency + achieves deep collaboration |
Why MUXI works: Early and sustained participation (involved from initial planning, not brought in for "final polish"), clear professional sovereignty (not overridden by product decisions), equal three-party collaboration (UX/PM/development), smoother communication, elimination of structural weakness.
Implementation pitfalls and solutions(Copying verbatim does not work; these pitfalls must be addressed):
| Pitfall | Description | Solution |
|---|---|---|
| UX manager disconnect | Does not understand members' daily work, making coaching difficult | Regular 1:1s, participation in design reviews, hosting community of practice events |
| PMs have no feedback channel for UX | PMs cannot influence UX work | UX managers regularly collect feedback from PMs/developers and incorporate it into performance reviews |
| UX members are "neither here nor there" | UX is treated as an outsider | PMs/developers treat UX as formal members and invite them to all key discussions |
| Lack of flexibility in allocation | UX is permanently pinned to a single product team and hard to reassign | Reserve flexible roles, review assignments regularly, and encourage cross-skill training |
Implement according to company size: Startup = 1 UX lead supports multiple product teams to build the most basic structure; Small = set up key support teams, with UX staff "floating" but under unified management; Midsize = embed UX into every core product line, with a UX director overseeing overall coordination; Large = multiple layers (VP-Director-Manager-Designer) plus specialists such as content strategy and accessibility, all unified under UX for cross-team support.
Roll out in 4 steps: ① Start from problems, not from structure (first identify current UX pain points: marginalization / lack of voice / limited growth); ② UX + Product + Engineering jointly build the case for reform and evaluation criteria; ③ Create clear collaboration mechanisms (how to co-set priorities, UX participation scope, how to measure outcomes); ④ Build a strong UX community (shared tools / research processes / design systems / team norms).
II. How to divide responsibilities: RACI matrix
Two RACI articles have been merged: One covers "what RACI is and what it looks like", the other covers "why, when, and how to assign responsibilities". They are integrated into one section below.
RACI (Responsibility Assignment Matrix)= A table that maps "each stage/task in product development" to "how each role participates", specifically solving the problem of "unclear responsibilities, no one being sure who should do what". The four letters stand for:
| Letter | Meaning | Rule |
|---|---|---|
| R = Responsible | The person who actually executes the task | There can be multiple |
| A = Accountable (ultimately responsible / oversees) | The person who does the final review and bears overall responsibility for completion | Each task has exactly one A; A can also be R at the same time |
| C = Consulted | People who provide advice and professional input (e.g., UX managers, domain experts) | —— |
| I = Informed | People who only need to know progress and do not participate in decision-making (often senior leadership or people outside the team) | —— |
How to build it: List development stages/tasks in the first column (one per row), list roles in the first row, and fill R/A/C/I in the intersecting cells;Ensure every task has at least one R and one A(so the responsibility chain is complete). RACI is not for scheduling waterfall plans; it serves agile collaboration and delivering value to users.
Example matrix:
| Task/Stage | UX Designer | Product Manager | Development Team | Marketing Manager | Senior Leadership |
|---|---|---|---|---|---|
| Requirements gathering | R | A | C | I | I |
| Prototyping | R | C | I | I | I |
| Usability testing | R | C | I | I | I |
| Product launch plan | C | A | R | C | I |
| Post-launch feedback and optimization | R | A | C | C | I |
Scope of tasks that can be covered: Strategy phase (vision/goals/strategy), exploration phase (user interviews/stakeholder interviews/contextual observation), design phase (brainstorming/prototyping/usability testing), delivery phase (launch plan/quality testing/demo sessions). Roles are not limited to UX (product designers/UX researchers/UX managers), but also include PMs/engineers/Scrum Masters, etc.
When assigning, do not only look at job descriptions; also consider 4 factors: Skills (who is actually good at it), historical knowledge (who knows this product/organization better), availability (who has time), interest and ambition (who wants to grow through it). Example: If a PM is good at interviews, they can be both R and A for "user interviews"; even if the UX team has no time to participate in interviews,they should at least be marked I to ensure interview results are shared.
When to use it: ① When a retrospective (retro) finds "missing roles / key roles brought in too late"; ② When a new task starts (new Scrum Sprint / product increment development).How to use it: Fill it out together through team meetings or online workshops; the UX team can take the lead in proposing and driving it.
The most important cultural meaning: RACI is a visualization tool to prevent "one-way handoffs between departments"— it promotes "design as a process that everyone participates in", rather than "design as a service where you submit requests and I deliver outputs". Usage recommendations: Use it frequently at first; after team collaboration matures, you can gradually reduce reliance on it (role awareness will become natural); update it regularly when projects/requirements change. Benefits: Clarifies responsibilities to avoid overlap, improves collaboration efficiency, strengthens decision-making mechanisms (the single A ensures clear decisions), and ensures all relevant parties receive information at the appropriate stage.
III. How to hire and onboard people: Onboarding + 30/60/90
Onboarding is to new employees what an app's onboarding tutorial is to users — good onboarding creates a positive first impression, eases anxiety, prevents new hires from getting lost searching for files everywhere, and helps them quickly build a professional network. It is especially important for UX teams (a key to retaining scarce talent).
Steps to create an onboarding process from scratch: Audit the current onboarding experience and note strengths and weaknesses → Identify pain points (where new hires commonly get stuck) → Create/update onboarding documents (FAQs, tool usage, team culture) → Define document storage and distribution methods → Introduce documents and activities to new hires → Communicate regularly to answer questions → Collect feedback for continuous optimization. If a process already exists, customize it to the UX team's characteristics (tool training, workflow introductions).
Before the first day (organizational preparation):
- Assign an onboarding lead— this can be: a member who recently went through onboarding / a peer designer or researcher / a DesignOps person / a key contact who can help the new hire build an internal network.
- Priority preparations: Access to and usage guidance for software tools, locations of key resources (design system/research repository), best practices for getting work done and team culture, and key contacts to meet.
- Document storage: Place them in easily accessible locations (Confluence / Basecamp / Google Docs) and keep them updated.
After the first day (first week):
- A welcome kit (sticky notes/souvenirs) builds a sense of belonging; clearly explain the company mission and how the UX team serves business goals; list core tasks and evaluation criteria in detail.
- First-week tasks: Familiarize with system tools, understand existing design and research outputs, adapt to the culture by participating in activities, and establish initial connections with colleagues you will collaborate with regularly.
- Ongoing support: Regular check-ins, set up fixed learning and sharing meetings.
30 / 60 / 90 day goals (maintain development momentum):
| Stage | Goals |
|---|---|
| 30 days (Month 1) | Understand core tasks, build a work foundation; complete tasks in close collaboration with the manager/team |
| 60 days (Month 2) | Focus on key tasks on top of the foundation; begin to take on more work independently |
| 90 days (Month 3) | Complete tasks independently, adapt to organizational processes;Propose optimization suggestions and demonstrate your own value |
Trello / Confluence can be used to track goals and progress. Mindset: Good onboarding is a "retention investment" rather than an "administrative procedure"; UX leaders should personally participate in designing the onboarding process to make it targeted.
IV. How to plan research: PET(S) principles
Why write a research plan: It is the "map" of the entire research project — it helps the team think structurally (clarify goals and methods), reduces repeated meetings and misunderstandings, and forms shared understanding to prevent rework. In one sentence:Plans are for alignment, not for checking a box.
The four elements of PET(S)(that a qualified research plan must answer):
| Letter | Element | What to specify clearly |
|---|---|---|
| P = Purpose | Research goals + success criteria | Who/what product to research, what methods to use, why the research is being done;Specific metrics for usability goals(e.g., maximum task completion time, success rate) |
| E = Expectations | Deliverables and timeline + team division of labor + observation guidance | Schedule/deliverables/milestones; participating members (including note-taker and observer roles); note-taking and question-asking guidance for observers (to ensure data accuracy and not disrupt sessions) |
| T = Test Setup | Equipment and tools + recruitment plan | List all required tools and equipment; screener questionnaire + participant recruitment process |
| (S) = Script | Moderator script | Introduction, instructions, question prompts, task scenarios, participant consent form; every step from introduction to task execution is clear |
Beyond the plan, 3 more things must be done:
- Obtain stakeholder approval: Provide written goals, user personas, and task scenarios in advance, and get verbal or written approval to avoid later disputes.
- Nail down logistics Reserve enough time for each participant (including pilot runs, lunch breaks, debriefs); confirm venue, equipment, tables and chairs; if there is compensation (cash/gift cards), clarify the distribution method and timing.
- Prepare a Consent Form: Clearly state the research content/purpose/date, who is conducting the research, participant compensation, the type and use of collected information, and the non-disclosure agreement (NDA); use clear, easy-to-understand language to ensure true understanding and genuine consent.
Long-term planning: Create reusable research plan templates(covering common goals/methods/script frameworks) and share the templates across the team to reduce preparation time for each study and turn experience into accumulated assets. Mindset: Research plans organize thinking, improve efficiency, and ensure quality — from clarifying goals to logistics, they are both key to running studies smoothly in the moment and reusable experience for the future.
For research methods themselves (how to choose qualitative/quantitative, the 5-user rule, task scenario design, etc.), see NNGroup Qualitative Research and Research Methods Toolkit (Method Landscape/Interviews/Empathy Maps/Sample Size/Task Design/Moderation/Expert Evaluation/Workshops/Ethics) / NNGroup Usability Testing and the Ten Usability Heuristics (Full 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 Bias/Competitive Evaluation).
V. Use design thinking to pull the team together
Design Thinking is usually treated as an "innovation method", but this NNGroup article takes a different angle: it is also a team-building method — through a structured, inclusive collaboration process, it incidentally builds trust and cohesion. There are three mechanisms:
| Mechanism | Challenge | How design thinking solves it |
|---|---|---|
| Shared vocabulary | Members have different backgrounds and experiences, understand the same concept differently, creating communication barriers | Use workshops to let members participate in key links from the start, gradually forming a common language; let the team focus on "how to do it" rather than getting stuck on "what to do" |
| Tangible outputs | Complex ideas are hard to articulate and easily misunderstood | Outputs such as empathy maps, user journey maps, storyboards, and wireframes = visualize complex ideas, serve as a "physical dictionary" of shared concepts for the team, and each output symbolizes a collective success, thereby improving cohesion |
| Trust-based team culture | Differences in role hierarchy make junior/introverted members afraid to speak up | Equal participation regardless of hierarchy;Anonymous idea sharing + public voting ensures everyone's voice is heard → transparency and inclusiveness → builds trust and motivates participation |
Mindset: On the surface design thinking "promotes innovation", at its core it "builds trust" — its structure and inclusiveness exactly provide the ideal atmosphere for team collaboration.Why: Tangible outputs ground abstract discussions; anonymity + voting breaks the monopoly of authority (this point fully connects with Chapter 6 "preventing groupthink").
VI. Team decision quality: Three cognitive traps of "collective stupidity"
This section is the highest-value, most counterintuitive part of this article:A room full of smart people often collectively makes wrong decisions because of cognitive biases. The three traps are progressive: "confirmation bias" at the individual level, "groupthink" at the group level, and the tool to counter both: "written thinking".
6.1 Confirmation Bias (individual level)
Definition: When searching for or analyzing information, people tend to favor content that matches their existing beliefs, and ignore or reject opposing information — even when the opposing information is factual. It can be understood as a kind of psychological priming: existing beliefs affect how you find and interpret new information; it is efficient but limits acceptance of new perspectives and hinders objective judgment. The stronger the emotion and the more deeply held the belief (politics/religion/climate, etc.), the more pronounced it is.
It is especially dangerous in UX:The more a designer invests in a hypothesis, the stronger the confirmation bias — if you've only been working on a design for a day, you can look at test results objectively; if you've invested months, you'll desperately want to believe feedback that supports your design and ignore feedback that points out problems.
Typical manifestations: Leading questions (testing only focuses on your own hypothesis), ignoring contrary evidence (disregarding inconsistent feedback in usability tests), biased interpretation (forcing ambiguous results to read as "supporting me").
Counterexample (leading question): E-commerce conversion rate is low, and the designer assumes it is because "the checkout button is poorly designed", so they ask users —
❌ "Is the red checkout button hard to find?" The problems are: ① Over-focusing on the "button" while ignoring other possible causes; ② Negative wording ("hard to find") leads users to focus on button problems; ③ Closed-ended questions without context do not let users raise other pain points. ✅ Rewrite as an open question: "How would you evaluate the entire checkout process? Please explain what you liked or disliked."
5 tips to avoid pitfalls:① Research, don't validate——Set the goal as "exploring the unknown" rather than "proving hypotheses"; comprehensively review objectives at the start of research to ensure methods are not biased; ② Collect data early——Gather data from target users before investing large amounts of time or emotion; ③ Ask non-leading questions——Use open-ended, non-leading questions; do not let questions imply answers; ④ Triangulation across multiple sources——Cross-verify using user testing + analytics data + quantitative research + customer service logs (for example, surveys may say a button is fine, but behavioral data shows users drop off in subsequent steps, indicating a need to re-examine the root cause); ⑤ Introduce "fresh perspectives"——Ask colleagues not involved in the project to review the research plan or participate in data analysis; a neutral perspective can identify biases.
6.2 Groupthink (Group Level)
The two Groupthink articles have been merged(One article uses "groupthink" translated as "tuanti siwei", the other uses "groupthink" translated as "qunti siwei"; these are two translated versions of the same concept, with highly consistent frameworks and recommendations, so they are integrated and deduplicated here).
Definition: Team members suppress personal views and alternative options in order to maintain consistency or harmony, leading to suboptimal decisions. Common in highly cohesive teams — members are unwilling to disrupt unity, so they avoid dissent, ignore alternative viewpoints, and sacrifice critical thinking to reach consensus. Characteristics: strong cohesion + desire for consensus and harmony + avoidance of disagreement.
Among the 8 symptoms summarized by Irving Janis (social psychologist, spelled Yanis in the original source), 4 are most common in UX work:
| Symptom (EN / CN) | Meaning | Example |
|---|---|---|
| Collective Rationalization | Making excuses for negative evidence instead of facing and discussing it | When someone points out a design problem, the team tends to rationalize it by saying "users will get used to it" instead of solving it |
| Illusion of Unanimity | Treating silence as agreement and ignoring possible dissent | Assuming everyone supports the plan because no one objects in the meeting |
| Self-Censorship | Staying silent because one feels "everyone has already reached consensus", even doubting oneself | A designer has concerns about a feature's usability but dares not speak up because the team enthusiastically supports it |
| Direct Pressure on Dissenters | Pressuring opponents to change their stance | People who raise objections are interrupted or told "we've already discussed this" |
5 Common Scenarios + Preventive Measures:
| Scenario | Problem | Prevention |
|---|---|---|
| 1 Team brainstorming | Authority figures or those with strong sketching skills dominate, others dare not speak up | Set clear norms ("there are no stupid ideas" + "when raising objections, state reasons and validate the other party's starting point");Brainstorm independently first, then share(gives space to introverts, avoids early opinion interference) |
| 2 UX workshops | Mistaking the facilitator for the decision-maker and being led astray by their authority | Explain groupthink risks at the start, clarify that the facilitator only guides and does not make decisions;"Diverge-converge (individual independence → group discussion)";dot voting; use blind dot voting |
| 3 Focus groups | Dominant participants take over, others are suppressed | Balance goals and backgrounds during recruitment to ensure diverse perspectives; start with low-pressure warm-up activities to build rapport and increase willingness to speak |
| 4 Following design trends | Blindly following the latest trends without assessing whether they suit one's own users | Use user testing to verify whether a trend fits target users (can test on competitor websites); weigh costs and added value together with cross-disciplinary stakeholders before deciding |
| 5 Virtual/remote environments | The facilitator dominates, others stay silent due to screen fatigue or inconvenience | Rotate facilitators to avoid authority monopoly; use tools like Google Forms for anonymous follow-up feedback; clarify the purpose of each tool before the meeting (e.g., "type questions in the chat box") |
Core principle: The universal solution to prevent groupthink = independent work first, then convergence + anonymity + voting + rotating facilitation——Essentially, this creates a safe channel for "minority opinions" that will not be crushed by authority and conformity (this is the same tactic as "anonymous sharing + public voting" in Chapter 5's design thinking).
6.3 Ink Thinking (Personal Tool to Hedge Bias)
Definition: a "journal-style" method — regularly recording decisions and predictions, then reviewing and comparing them after the fact, to continuously improve decision-making ability. It carries forward Peter Drucker's idea that "keeping a journal improves awareness of one's own strengths and weaknesses", using reflection to optimize intuitive judgment.
Why it works: Research shows reflection is more effective than mere practice——In experiments, the reflection group completed23% more tasks in subsequent tests than the practice-only group; it also counteracts Hindsight Bias(overestimating one's original predictive ability after the fact), forcing you to extract real lessons from experience rather than flattering yourself.
How to do it (two steps, left and right pages for comparison):
| Step | Timing | What to do |
|---|---|---|
| Step 1: Decisions and Predictions (Left Page) | At the moment of making a decision | Write the date → Describe recent important work decisions in 2–3 sentences → Predict possible outcomes in 2–3 sentences → Review previous records to reinforce learned lessons |
| Step 2: Reflection and Recommendations (Right Page) | When predicted outcomes are known | Write the date → Objectively describe actual results (2–3 sentences) → Compare predictions with reality, analyze differences, identify omitted key factors → Write recommendations for similar situations (2–3 sentences) → Use visual markers such as boxes, circles, or stars to highlight recommendations for easy retrieval |
Example: Left page (2022-01-01) "Recommended simplifying a design feature; predicted the team would see it as more efficient but worried users would be unhappy about the missing feature"; Right page (2022-01-15) "Result: user acceptance was high, efficiency improved, but some users wanted more customization options; Recommendation: next time consider users' need for flexibility, cover more scenarios in feature testing".
Tool preparation: Small and portable (3.5×5.5 inches / 9×14 cm), thin and simple (few pages so it is not intimidating), lined, no pre-printed templates, dedicated and not mixed with other content, kept within easy reach; set aside 5–10 minutes daily (mark "busy time" in the calendar, choose a relaxed period as a mental break). Long-term benefits: Identify "when to trust intuition, when to change strategy or seek help," and cultivate more mature professional intuition.
VII. UX's Biggest Challenges in Organizations and Transformation Strategies
7.1 Five Challenges + 6-Stage Maturity (Survey of 126 Practitioners)
For 126 practitioners found that almost all UX dilemmas stem from one root cause: misunderstanding of UX(equating UX with visual design/beautification, ignoring its actual impact on business functions and conversion, so it is treated as "optional" and cut first when budgets tighten).
| # | Challenge | Current Situation |
|---|---|---|
| 1 | Misunderstanding of UX | Equated with visuals/aesthetics; the organization stays at a low maturity stage; first to be cut during budget adjustments |
| 2 | Lack of measurable impact | UX's ROI is not as easy to quantify as marketing/sales, making it hard for management to understand its value; lacks hard data |
| 3 | Lack of stakeholder support | Because business value cannot be proven, executives/clients do not support UX processes and decisions, blocking resources and culture |
| 4 | Insufficient resources | Lack of time/funding/support; in agile environments, "feature development" often overrides "experience optimization" |
| 5 | Intensifying market competition | Fewer positions, uncertainty brought by AI, inflation and economic downturn make enterprises conservative about technology investment |
6 Stages of UX Maturity——A yardstick to judge how severe the "misunderstanding" is:
| Stage | Name | Description |
|---|---|---|
| 1 | Absent (Missing) | There is no UX at all in the organization (ignored/nonexistent/undiscovered) |
| 2 | Limited | Occasional, scattered, unsystematic (uneven/chaotic/has vision but no action) |
| 3 | Emergent | Begins to show potential but is inconsistent and inefficient (has functions and potential/inconsistent/inefficient) |
| 4 | Structured | Partially systematized, with mixed results (starts building process frameworks/differentiated results) |
| 5 | Integrated | Fully integrated, present throughout the organization (comprehensive/widespread/universal) |
| 6 | User-driven | UX is the core driver of organizational development (welcomed/reproducible/habitual) |
The second challenge mentions that "low-maturity organizations often stay at Stage 2 (Limited) or Stage 3 (Emergent)" — this is the reality for most companies. For a detailed breakdown of the maturity model, see NNGroup Product and UX Collaboration (Empirical Evidence of PM×UX Responsibility Differences · Root Causes of Overlapping Work · PM Role Model · RACI Division of Labor · Five Collaboration Recommendations · UXers Thinking Like Product Leaders · PLG · Glossary) / NNGroup UX Maturity Model (6 Stages · 4 Factors · Living Systems Perspective).
Recommendations: Core = Improve understanding of UX.
- Raise maturity: Use self-assessment tools to determine the current stage; use small pilot projects to demonstrate value and gradually build support.
- Build a supportive culture: Accumulate supporters through case studies and "small wins"; integrate UX into strategic conversations.
- Optimize processes: Use systematic methods to ensure consistency, build a research repository to reuse insights, and use lean methods to deliver results quickly.
- Specific strategies: ① Focus on high-impact projects (prioritize those that can produce measurable impacts on business metrics); ② Maximize existing resources (use A/B testing for quick validation, maintain design systems and research repositories to reduce repetition); ③ Collaborate with stakeholders (involve them in research design,speak their language to link UX goals with business optimization); ④ Develop team capabilities (provide UX training for cross-functional teams, standardize design quality metrics and continuously track and communicate them).
7.2 Refine / Remodel / Rebuild: Three Tiers of Experience Improvement Strategies
When an organization decides to "start improving experience," choose one of the three tiers based on current situation, budget, and risk tolerance.Prerequisite understanding: The overall Customer Journey has a greater impact on satisfaction than individual touchpoints, so optimization should focus on the overall journey rather than isolated pages.
The first step is always "Explore the Opportunity Space": ① Select a key customer journey that is critical to the business and has high improvement potential; ② Conduct longitudinal qualitative research to understand the current experience and identify opportunities; ③ Draw a Journey Map to communicate findings and recommendations to stakeholders. Factors to consider: current journey quality, investment readiness, organizational willingness and ability to transform, risk tolerance, unmet market needs, competitive threats.
| Strategy | Investment/Impact | Metaphor | Goal | Improvement Opportunities / Examples |
|---|---|---|---|---|
| Refine | Low investment / Low impact | Fixing the edges of a house (painting, oiling hinges) | Eliminate journey pain points through a series of low-cost small adjustments | Resolve brand/visual inconsistencies across channels; ensure clear information at each touchpoint to meet needs; reduce support calls; improve overall efficiency |
| Remodel | Medium investment / Medium impact | Redesigning the house structure to fit needs | Retain core concepts, restructure components to improve efficiency and convenience | Speed up task completion; improve transparency of service delivery; increase relevance with personalized recommendations; proactively provide additional services/touchpoints after users achieve their goals |
| Rebuild | High investment / High impact | Building a dream home from scratch | Use new technologies/new business models to create entirely new experiences and meet undiscovered needs | Examples: Casper Mattress (cutting out middlemen to deliver mattresses directly), Rent the Runway (clothing rental replacing traditional retail), Lemonade Insurance (technology redefining insurance), Netflix (mail-order DVDs → streaming). Requires high investment + major organizational change, with large return potential (can dominate emerging markets) |
Final step: Identify a Vision for the Future——Ensure strategic goals match the organization's actual capabilities; after exploring and evaluating each strategy, choose a direction that fits current capabilities and future vision to ensure sustainability and competitive advantage. Core principle: The three tiers are not "the more expensive the better," but "match your budget, courage, and current situation"; but no matter which tier, always start with "explore the opportunity space + draw a journey map," improving journeys rather than isolated touchpoints.
Sourced from NNGroup Topics / Managing UX Teams (a subset on team organization, 13 articles; two Groupthink articles merged into one, two RACI articles merged into one). For research methods and usability testing, see NNGroup Qualitative Research and Research Methods Toolkit (Method Landscape/Interviews/Empathy Maps/Sample Size/Task Design/Moderation/Expert Evaluation/Workshops/Ethics) / NNGroup Usability Testing and the 10 Usability Heuristics (Full List of 10 Heuristics · Application to Complex Applications · User Delight Hierarchy · Testing Methods: 5-User Rule/Recruitment/Remote/Task Scenarios/Step-by-Step Tasks/Attitude vs. Behavior/4-Step Analysis/Small-Sample Bias/Competitive Evaluation); for UX maturity and product perspective, see NNGroup Product and UX Collaboration (Empirical Evidence of PM×UX Responsibility Disputes · Root Causes of Overlapping Work · PM Role Models · RACI Division of Labor · Five Recommendations for Collaboration · UXers Thinking Like Product Leaders · PLG · Glossary) / NNGroup UX Maturity Model (6 Stages · 4 Factors · Living Systems Perspective); for UX influence and career development, see NNGroup UX Upward Influence, Metrics, Strategic Tools, Roadmaps, and Careers (13 Articles: Proving UX Value Upward — How to Sell UX, the "If…Then…" Formula, Rhetorical Triangle ethos/pathos/logos, UX & Marketing Collaboration / UX Metrics: Aligning with Organizational Goals Workshop, UX Goals vs OKRs vs KPIs, CASTLE 6 Dimensions for Mandatory-Use Software / Stakeholder Analysis: Power-Interest Matrix + Attitude, SWOT Four Quadrants / Roadmapping: 6 Steps, 5 Prioritization Methods, Journey Mapping Time Cost 73.8h / Career: STAR, METEOR Interview, Portfolio). Images (DesignOps 5 structure diagram, MUXI structure diagram, Google Docs onboarding example, maturity gradient diagram, Refine/Remodel/Rebuild investment-impact diagram, etc.) and original files are kept in sources.
Sources and Related Materials
- NNGroup UX Maturity Model (6 Stages · 4 Factors · Living Systems Perspective)
- NNGroup UX Upward Influence, Metrics, Strategic Tools, Roadmaps, and Careers (13 Articles: Proving UX Value Upward — How to Sell UX, the "If…Then…" Formula, Rhetorical Triangle ethos/pathos/logos, UX & Marketing Collaboration / UX Metrics: Aligning with Organizational Goals Workshop, UX Goals vs OKRs vs KPIs, CASTLE 6 Dimensions for Mandatory-Use Software / Stakeholder Analysis: Power-Interest Matrix + Attitude, SWOT Four Quadrants / Roadmapping: 6 Steps, 5 Prioritization Methods, Journey Mapping Time Cost 73.8h / Career: STAR, METEOR Interview, Portfolio)
- NNGroup Product and UX Collaboration (Empirical Evidence of PM×UX Responsibility Disputes · Root Causes of Overlapping Work · PM Role Models · RACI Division of Labor · Five Recommendations for Collaboration · UXers Thinking Like Product Leaders · PLG · Glossary)
- NNGroup Qualitative Research and Research Methods Toolbox (Method Landscape/Interviews/Empathy Maps/Sample Size/Task Design/Moderation/Expert Evaluation/Workshops/Ethics)
- NNGroup Usability Testing and the 10 Usability Heuristics (Full List of 10 Heuristics · Application to Complex Applications · User Delight Hierarchy · Testing Methods: 5-User Rule/Recruitment/Remote/Task Scenarios/Step-by-Step Tasks/Attitude vs. Behavior/4-Step Analysis/Small-Sample Bias/Competitive Evaluation)