One sentence: Agile was originally designed to "let developers deliver faster," and UX was a late guest that squeezed its way in. These 13 articles all talk about the same thing —how to make the slow, careful work of "understanding users" keep up with the fast pace of "two-to-three-week Sprints and continuous delivery"without getting squeezed out.
First, clarify a few recurring terms that will not be re-explained later:
- Agile: A development philosophy whose core is "small fast steps, continuous delivery, and embracing change"; its opposite is the "Waterfall model" (which lines up requirements → design → development → testing in a straight line and completes them one after another in a single pass).
- Sprint / Iteration: Agile cuts work into small 2–3 week cycles, each delivering something usable.
- Scrum: The most popular framework for implementing Agile is Scrum, with a fixed set of ceremonies (daily scrum, planning meeting, retrospective, backlog refinement).
- Product Backlog: A prioritized "to-do list" whose items are usually written as "User Stories" — in the format "As <a type of user>, I need <to do something>, so that <I can achieve a goal>."
- MVP (Minimum Viable Product): The biggest point of controversy in the entire piece, covered in its own section.
Six sections:Current state + Top 10 Tips → Discovery → Three-school MVP debate → Integrating research into the backlog → Lean UX documentation → Collaborative activities / Content / Design Thinking / Mozilla ROI evidence.
1. Current state inventory: How is UX actually faring in Agile
A profile from NNGroup surveys of project managers, designers, researchers, and engineers.Core mindset: Agile is neither a natural enemy nor a paradise for UX — it surfaces problems early and delivers fast, but because it was "built for developers," UX naturally has weaker voice and must earn it back through maturity and proactivity.
| Data points | Number | Explanation |
|---|---|---|
| Agile adoption rate | 69% of projects use Agile (only 40% in 2008) | It is already mainstream, but far from universally dominant |
| Hybrid model | 22% of teams "do requirements and design in Waterfall + development in Agile" | Shows pure Agile is still hard to implement; many teams compromise |
| UX share on teams | 17% of members are UX professionals | Higher than in the past, but "adding people ≠ guaranteed success" |
| Maturity threshold | Most successful teams have>3 years of Agile experience | Agile requires years of refinement; new teams should not be discouraged by early chaos |
| UX influence score | Average4.0 / 7 points | UX is still relatively weak in Agile, with room for improvement |
6 characteristics of mature Agile UX teams: ① >3 years of Agile experience; ② Collaborative culture, clear roles, shared responsibility for quality; ③UX work leads development Sprints(with clear consensus on handoff points); ④ UX practitioners are proactive (they do not wait for requirements to come to them, but actively conduct research and identify market opportunities); ⑤ Establish formal processes to approve user stories, block sudden external requests, and protect user-centered design; ⑥ The UX role expands from "drawer of pictures" to "leader/facilitator" (translating user needs into business needs and communicating them to stakeholders).
Counterexample: Only stuffing UX headcount into a team without giving them voice and lead time leaves UX as an appendage to development, and influence scores will not rise.
Top 10 practical Tips (summarized from 125 Agile practitioners)
A compilation of experience from 125 frontline practitioners (designers / developers / product owners / PMs).How to use: These 10 items are not a list sorted by importance, but a "toolkit" — depending on team maturity, start with the few that address the most painful problems.
| # | Tip | Mindset / Why | Implementation key points |
|---|---|---|---|
| 1 | Reserve time for release planning + Story Mapping | Upfront planning saves rework later | Map user journeys, identify opportunities, and categorize and prioritize stories at the start of the project |
| 2 | Complete UX activities before the Sprint starts | Design and development are hard to finish synchronously within the same Sprint | Designers deliver wireframes / user flows / prototypes1–2 Sprints ahead, and developers code based on those |
| 3 | Cultivate a collaborative culture | Agile Manifesto: "Individuals and interactions over processes and tools" | Use design thinking, brainstorming, and experience journey maps to break down information silos |
| 4 | Emphasize iteration over perfection | Low-fidelity for fast feedback; finding problems early avoids major rework | Start with sketches/wireframes; do not get stuck on aesthetic details too early |
| 5 | Participate in the daily scrum | Trade a little time for full-team alignment and fewer misunderstandings | Limit speaking time to keep it efficient and concise |
| 6 | Turn user research into a team activity | When everyone sees real users, design decisions gain shared consensus | Bring developers and PMs along to observe usability testing |
| 7 | Ensure strong stakeholder participation | Early participation = clear direction + support for key decisions | Build a leadership team, invite customers to testing, and give regular executive updates |
| 8 | Clarify roles and responsibilities | Traditional Agile does not define the UX role, which easily causes confusion | Designers proactively clarify where UX sits in the process; assign a strong scrum master |
| 9 | Run training + onboarding | Teams often rotate and restructure; alignment is needed | Use lightweight formats such as "lunch-and-learns" for cross-functional training |
| 10 | Keep adjusting until you find what fits | Agile is a framework, not dogma; self-reflection is allowed | Use retrospectives to remove unnecessary complexity and let the team choose Agile elements autonomously |
2. Discovery: Narrow the scope, don't skip it
Discovery = Before development starts, first figure out "what the problem is, where the opportunities are, and whether the key assumptions hold." The most common mistake Agile teams make: when time is tight, cut Discovery entirely and jump straight into development.Core mindset: Agile is not "rush to finish," it is "deliver high value through continuous small increments" — Discovery is the foundation of that value. The correct approach is to narrow the scope of Discovery(validate only the most critical assumptions), not skip it.
The five-step SCALE method(how to execute Discovery in Agile):
| Letter | Step | What to do |
|---|---|---|
| S | Speak and Spike | Communicate with the team and stakeholders, plan Discovery ahead of time, and include spike time in iteration planning (a spike = a dedicated time block reserved for "first researching something uncertain") |
| C | Capture Alignment and Gaps | Document the team's shared understanding and blind spots; when there is disagreement, do research to fill the gaps |
| A | Assign Activities | Assign Discovery tasks to the right people —it is not just UX or PM work |
| L | Learn and Share | Share as you go; don't wait until Discovery is fully done to do a one-time analysis |
| E | Evaluate and Decide | Regularly assess "is the information enough yet?" and let the team jointly decide next steps |
4 key factors that support Discovery implementation:① Executive support(if management does not understand the value of Discovery, the team will not get time and resources — UX/product owners must advocate for it); ②Track the value of Discovery(use data to prove how Discovery speeds up decisions and improves quality, to address concerns from those who "only look at development speed"); ③Don't start development early(starting before Discovery is done leads to insufficient information, rework, and waste); ④Reuse templates(standardize task assignment sheets, research questions, and note-taking templates to improve efficiency).
Counterexample: Skipping Discovery to rush progress → discovering problems or insufficient information mid-development → massive rework, which ends up slower.
3. The three-school MVP debate: This is the biggest point of controversy in the whole piece
4 notes fight over MVP, which deserves its own section.Core contradiction: The original intent of MVP vs its misinterpretation in practice.The true original intent of MVP(from *Lean Startup*, with earlier roots in Toyota Lean Manufacturing): the simplest version of a product/feature,but simple only to the point that the team can judge "whether users can actually get value from it" — in essence it is an experiment, and if it fails you should be willing to abandon or adjust the idea.The biggest misinterpretation: Treating MVP as "Release 1" or "a half-baked product cobbled together every two weeks."
Comparison of the three schools of thought:
| Position | Source article | Claim | Applicable premise |
|---|---|---|---|
| Back-to-origins school | *MVP Is Not Necessarily Release 1*, *Minimum Viable Product* | MVP = an experiment to validate hypotheses, often replaceable with prototypes/simulations instead of a real launch | When you want low-cost, fast trial and error |
| Misinterpretation critics | “Why MVP Is the Antithesis of Good UX” | Most companies are hijacked by "fast validation," producing fragmented, mediocre, non-iterated bad experiences | When the team's goal is to build a high-quality finished product, not to prove something to investors every two weeks |
| Redefinition school | Same as above | Make "Viable" real: MVP must be polished enough, usable, and able to attract users | Modern mature teams with existing customers |
4 sins named by the misinterpretation critics(*Why MVP Is the Antithesis of Good UX*): ① No usability testing at all, or only letting paying users be guinea pigs after launch, letting negative word-of-mouth spread; ② MVP is too far from the final vision — "using user feedback on a tent to validate a mansion," making feedback meaningless; ③ Only focusing on local features that lack overall coherence when stitched together, creating a fragmented experience; ④ Failing to iterate even when post-launch feedback is poor, violating MVP's iterative core.
The redefinition school's solution: If the MVP model does not improve efficiency in your team,redefine "minimum viable" — MVP should not be a rushed half-baked product, but should be well-researched, meaningful, usable, and able to attract users before launch. Key realization: MVP in Lean Startup is suitable for startups with "limited funding, no existing customers, and investors watching closely"; but many companies using MVP today do not need to "prove something every two weeks" — they want high-quality finished products, so don't copy startup playbooks blindly.
MVP risk-reward matrix: When is it worth doing an MVP
How to use: The greater the potential reward, the more worth it is to test with an MVP first; but which specific MVP type to use depends on the level of risk.
| High reward | Low reward | |
|---|---|---|
| High risk | Test with a prototype MVP first(worth doing, but high uncertainty; try cheaply first) | Deprioritize or redefine the problem(dangerous and unprofitable; not worth pursuing) |
| Low risk | A code MVP is acceptable(the direction is likely sound; worth seeing real behavior in the real market) | Don't build a dedicated MVP first(limited benefit; not worth the effort) |
Two types of hypotheses: Value-Proposition Hypothesis vs Solution Hypothesis
MVP must answer two questions in sequence, corresponding to two types of hypotheses.Don't reverse the order: First verify "Do users find this valuable?", then verify "Can my specific approach actually deliver that value?"
| Hypothesis | English term | Question answered | Who validates first |
|---|---|---|---|
| Value proposition hypothesis | Value-Proposition Hypothesis | Users Whether they find this thing valuable | First step; suitable for quick, low-risk testing with a prototype MVP |
| Solution hypothesis | Solution Hypothesis | Whether this specific approach can actually deliver the value | Second step |
Standard format for a value proposition hypothesis: "We believe that [a certain value] is valuable to [a specific group of people]. If we observe [a specific behavioral signal] during testing, this hypothesis is validated." — In essence, this sets clear, observable success thresholds for "acquisition, retention, and growth."
Example (AI investment assistant): Build a lightweight AI investment assistant for young working professionals who want to save and invest, which connects to their bank accounts to provide personalized advice. Thresholds for the first-month pilot:≥30% complete setup in the first session, ≥30% act on the recommendation in the first week, ≥30% return within 7 days after their first action. All thresholds met = hypothesis validated; only "setup + action" met but return rate below 30% = compelling but lacking sustained value(partially supported); none met = hypothesis invalidated.
6 types of MVP metrics (what to look at when testing value proposition hypotheses with a prototype MVP)
Prerequisite: Some initial exploration has already been done, so you know what the problem is and who it affects.
| Dimension | What to measure | Example metrics |
|---|---|---|
| Engagement | How actively users use the product | Percentage completing onboarding; average number of features used per session |
| Retention | Whether users come back | 7-day return rate; which step has the highest drop-off |
| Macro-conversions | Whether users complete key behaviors that directly impact revenue | Free-trial-to-paid conversion rate; sign-up completion rate |
| Micro-conversions | Whether users complete small actions close to conversion | Percentage clicking "Learn more"; percentage adding to wishlist |
| System-performance | Whether the system is stable and reliable at scale | Page load time during peak traffic; percentage of failed/timed-out transactions |
| AI-performance | Whether AI outputs are accurate and reliable | Percentage of AI recommendations perceived as relevant/accurate |
How to describe MVP to stakeholders to win support
① Clarify the MVP goal— State clearly which hypothesis is being tested, and which specific business decision it is tied to (Investigating a conversion problem? Or testing market viability?); ② Frame the MVP as an experiment— Unless it is truly an official launch,do not use "launch / release"; use "pilot / experiment / learning test" instead, emphasizing that it is for validation, not a final version; ③ Explain the plan clearly— Which hypothesis will be tested, what MVP will be used, which metrics will be tracked, and what results count as "supported / partially supported / not supported".
Core mindset running through this section: An MVP failure is still valuable knowledge ("This idea is not worth pursuing" is itself valuable). Framing it as an experiment both sets correct expectations and protects the team from being pressured into "must launch".
IV. Fitting "understanding users" into the backlog: Research, hypotheses, and facts must all be trackable
Core pain point: Agile breaks tasks down by "specific features", while user research produces learning outcomes rather than immediately shippable code/design (output), so research is naturally a poor fit for two- to three-week sprints and is easily overlooked.Mindset:Focus on outcome (the actual value delivered by features) rather than output (delivery of the feature itself)— Research is the "continuous learning" driver that Agile needs to "respond to change".
4.1 Write research into the backlog as user stories
Three major challenges for research in Agile: ① A complete research project often spans multiple iterations, leaving backlog items open for a long time; ② Research results do not make it into the backlog, so they are heard but not acted on; ③ The output is "learning" rather than code, so the team does not know how to handle it.
Solution— Treat research as a backlog item on equal footing with design/development: ① Add research as individual backlog items/user stories to the backlog; ② Break it into small tasks (recruitment, scheduling, running tests, analyzing data, reporting); ③ Mark items complete one by one during iterations.
Example (usability test with 6 participants, testing keyboard shortcuts): Each participant = one set of "recruit + schedule + test" tasks, plus "analyze data" and "report results" tasks. Work can be completed in stages across sprints — End of first sprint: 3 participants recruited and scheduled, 4th being recruited, 1 test session completed; End of next sprint: all 6 recruited, half the interviews completed, first half of data analyzed, with preliminary patterns or a progress report presented at the sprint review. All outputs produced after research is completed (bug fixes/UX debt/new feature opportunities/future research opportunities)must flow back into the backlog, with no shelving allowed.
4.2 Questions → Assumptions → Facts: Use a knowledge board to reduce risk
Background: Constrained by time and budget, Agile teams often make assumptions first and validate them later regarding user needs (the ideal is data-driven; the reality is guessing while verifying).Risk: Assumptions are mistaken for facts, derailing the entire project.Solution: Use a single knowledge board (Kanban board is most recommended)to track four stages in separate columns, moving cards from left columns to right columns as validation progresses.
| Stage | Meaning | One-sentence description |
|---|---|---|
| 1 Questions | The parts we do not know do not know about users | Brainstorm gaps in knowledge about user behaviors/attitudes/motivations around the features to be developed |
| 2 Assumptions | The parts we think we know think we know about users | Based on personas/early research/stakeholder feedback;source + validation plan must be recorded |
| 3 Research | The process of validating assumptions | User testing/field research/data analysis/interviews; if falsified, revise the assumption and continue; if confirmed, move to the next stage |
| 4 Facts | Knowledge that has been confirmed with data | Documented + reviewed regularly to ensure shared team understanding |
Example chain (offline feature): Question "Do users want to use the App offline?" → Assumption "Users often use the app in basements with no network (source: stakeholder feedback on 10/31)" → Research "Field observation found that half of participants matching the primary persona work in basements on workdays with no stable network" → Fact "Users do need an offline feature". Recording tool options include Kanban (Trello / physical board, most recommended, for intuitive visibility of which stage each card is in), project management software (Jira, managed together with the backlog), or clearly structured text files (Google Drive/Dropbox/SharePoint).
V. Lean UX documentation: Less is more, but do not skip writing entirely
Common misconception: Agile pursues "minimal documentation", so some people interpret this as "writing no or very little documentation = high efficiency".Truth: Documentation is a company's "memory" — without records, the team repeatedly recalls and re-discusses matters already decided, which actually reduces efficiency.Mindset: It is not "don't write", it is "only write what is right" — ask two questions before writing.
| Ask before writing documentation | How will it be used |
|---|---|
| Who is it for? | Is it for leadership or for the team? Different audiences require different depth of detail and priorities; only record what the audience actually cares about |
| What is the purpose? | To provide context? To help remember decisions in the future? To report progress? Define the purpose first, then decide which details to include |
Two overarching principles:Less is more(Only write key points such as design intent, decision rationale, and how features work; overly detailed documentation will not be read);Iterate continuously and update promptly(Do not wait until the end of the project to write; update at any time as research progresses).
Two moments when "concise documentation is mandatory":① Before the project starts— Record the plan summary (what/why), impact and responsible parties, and timeboxing (key dates); ② When changes occur during the project(responding to change is core to Agile) — Record changes incrementally (do not wait until the end),update within existing tools whenever possible(JIRA / Slack discussion groups / design system; do not create a new document every time), and clarify follow-up responsible parties and unresolved items.
How to write the weekly UX update(to sync learning outcomes and progress with the team while avoiding information overload): Team/product name · Time range · Quantitative metric progress (conversion rate/growth, etc.) · Positive feedback (positive signals from user research) · Negative feedback (issues to improve) · Team dynamics (fun facts/new trends/new tools, to build cohesion).Notes: Do not use lengthy PPTs/complex charts;short emails or summaries are more effective(you can give it a fun name like "UX Feedback Friday" to build anticipation); keep data concise and highlight key points;group feedback by theme instead of dumping everything together.
VI. Collaborative design / Content planning / Design Thinking / ROI evidence
6.1 Three collaborative design activities: Make design a team responsibility
Mindset: In Agile,design is a shared team responsibility, not the UX designer's job alone. Introducing collaborative activities reduces designer burden, breaks down information silos, and speeds up decision-making.How to choose: Consider team size + whether the need is for the current sprint or a future sprint.Tips for introduction: Start small, carve out a short segment within existing Scrum meetings (planning/backlog refinement) instead of adding new meeting burdens.
| Activity | Best for | How to do it | When to use it |
|---|---|---|---|
| 6-Up 1-Up | Large teams / Designing future features | ① 6-up6-up: Each person draws up to 6 sketches of the same feature in 5 minutes (focus on ideas, not drawing skill) → ② Discuss to identify commonalities and promising ideas → ③ 1-up1-up: Each person picks one idea and refines it in 5 minutes → ④ Final discussion to select the best or merge ideas | Prepare in advance for future sprints, and help members familiarize themselves with each other's thinking |
| Whiteboarding | Small teams / Features that need fast implementation | Set clear goals (specific requirements/user personas/acceptance criteria) → Members freely draw on the whiteboard and refine together; developers/PM/designers in the same space reach consensus on technical feasibility and consistency | Design needs for the current sprint (produce solutions quickly, reduce later communication and revisions) |
| Telephone Game | Large teams / Subsequent sprint features | Members take turns adding their own ideas to sketches/wireframes; each person spends 1–2 minutes improving the previous person's design before passing it on, until no further extensions can be made | Stimulate creativity + familiarize members with others' designs, and incrementally evolve new solutions |
6.2 Five user stories for content creation: Don't let content be rushed through
Pain point: Agile uses user stories to track UX and development, but the workload of content creation is often underestimated, leading to content being rushed or even ignored.Solution: Create dedicated user stories in the backlog for each stage of the content lifecycle.
| # | Content user story | Purpose | Example (bank/first-time home mortgage scenario) |
|---|---|---|---|
| 1 | Content Spikes | Conduct research before creation to understand user needs and lay a foundation | "As a content creator, I need to understand first-time homebuyers' questions about mortgages so that I can provide correct answers" |
| 2 | Content Creation | Reserve sufficient time for "creating based on user needs" | "As a first-time homebuyer, I need to understand the mortgage application process so that I am less confused when viewing properties" |
| 3 | Content Review | Reserve time to review accuracy, brand consistency, and compliance with marketing/legal/design teams; and reserve time for revisions | "As a content creator, I need to review content together with operations/marketing/compliance" |
| 4 | Content Publication & Management | Plan the full lifecycle of publication, scheduling, review, and even takedown | "As a content manager, I need to write high-quality metadata to ensure content appears on search result pages" |
| 5 | Content Testing & Optimization | Continuously test, analyze feedback, and optimize after launch | "As a content creator, I need to understand how first-time homebuyers communicate with the bank so that I can add supporting copy" |
6.3 Design Thinking + Agile: The flashlight model
Relationship:Design Thinking is responsible for "deeply understanding the problem", while Agile is responsible for "quickly delivering solutions"— The two are not an either/or choice, but complementary. Buzzwords such as Design Thinking, Lean, and Agile are often treated as opposing options, but they can actually be combined very well.
Flashlight model (metaphor): Compare a designer's work in Agile to a flashlight beam —the closest, brightest part = clear, focused tasks in the current sprint; the farther and dimmer the beam = the more ambiguous, more in-need-of-definition tasks in future sprints. The further into the future you look, the more time and energy is needed to clarify things.
Mapping the five (six) stages of Design Thinking to sprint proximity in Agile:
| Stage | Goal | Which sprint category it falls into |
|---|---|---|
| Empathize | Understand users and build personas through research | Future sprints (early-project research, laying the foundation) |
| Define | Synthesize research, identify pain points, and recognize business opportunities and problems | Future sprints (understand the problem, do not rush to produce solutions) |
| Ideate | Brainstorm multiple creative ideas | Upcoming sprints (require time for refinement and estimation) |
| Prototype | Build prototypes for some ideas | Upcoming / Next sprint (depends on how well-defined the backlog items are) |
| Test | Validate prototypes with user feedback | Upcoming sprint |
| Implement | Finalize design and support development | Current sprint(Fully support development to ensure tasks progress as planned) |
Core principle: In agile environments, designers' work rhythm often seems unpredictable —using "how far a task is from the current sprint" to judge how much effort to invest allows you to find balance in a fast-paced environment and stay aligned with development.
6.4 Mozilla Case Study: Empirical ROI Evidence That Iterative Testing Reduced Support Requests by 70%
This is the only real case in the entire article with hard numbers, used to prove the return on investment (ROI) of UX efforts to senior leadership. Mozilla (the parent company of Firefox, a nonprofit open-source organization) has a support website that receives millions of annual visits, making it one of the most visited support sites in the world.
Pain points: ① There were approximately 400 pages of help documentation, making it hard for users to find the information they needed; ② Support staff (employees + volunteers) could not keep up with the massive volume of questions brought by Firefox's rapid updates; ③ Writing more articles actually made searching more complicated (the paradox that more content makes information harder to find).
Team (3 people): Susan Farrell (Senior UX Specialist at NNGroup, responsible for research/data discovery/analysis/improvement recommendations), Crystal Beasley (Mozilla Product Designer/Project Lead, who played the "computer" to simulate interactions during paper prototype testing), Bram Pitoyo (Web UX Designer, who designed task flows and prototypes).
Methods: ① Data discovery and analysis (UX data + behavioral data such as common questions/traffic/search + content structure analysis); ② Employee interviews (video calls to dig into pain points); ③ Information architecture (IA) testing (card sorting + tree testing); ④ Task flow testing (paper prototypes, tested on desktop and mobile).Highlighted workflow: Leveraged the 14-hour time difference between Jakarta and Portland to achieve 24-hour continuous work — Portland tested during the day, Bram revised designs and sent PDFs from Jakarta at night, and new prototypes were printed the next day,completing 7 rounds of key page iterations within 2 weeks, proving that "usability testing can also be very agile."
Results (hard ROI data):
| Metric | Before redesign | After redesign |
|---|---|---|
| Number of new forum questions | Approximately 7,000 per month | Approximately 2,000 per month(a reduction of approximately 70%, 5,000 fewer per month)70%, 5,000 fewer per month) |
| 24-hour question response rate | 40%–60% | 80%–90% |
Transition technique: Before the official launch, a quick-link navigation was added to the homepage as a temporary solution to verify whether "direct access to the most common content can reduce new questions entering the forum" — quick links are usually a stopgap for poor navigation, but here they were used to low-costly validate the usability of the most common information and provide a basis for the new IA.
Three lessons learned: ① The core of a support site is to solve constantly changing common questions; data must be analyzed regularly to update documentation so that support staff can focus on more complex new issues; ② Data mining identifies problems, data analysis validates solutions, and data-driven success drove resource acquisition and continuous improvement; ③ Cross-regional teams achieved success through close collaboration and a unified vision.Core principle: This is strong evidence for senior leadership that "UX investment produces measurable returns almost immediately" + a sample of the effectiveness of paper prototypes.
Sourced from NNGroup Topics / Agile - Agile Development (13 articles). For usability testing and the 5-user rule, qualitative data analysis, see NNGroup Usability Testing and the Ten Usability Heuristics (Complete Table of 10 Heuristics · Complex Application Implementation · 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) / NNGroup Qualitative Research and Research Methods Toolbox (Method Landscape/Interviews/Empathy Maps/Sample Size/Task Design/Moderation/Expert Evaluation/Workshops/Ethics); for team management and design process organization, 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) · Design Thinking Strong Teams · Team Decision Quality: Confirmation Bias/Groupthink/Written Thinking · UX 6-Stage Maturity and Biggest Challenges · Refine/Remodel/Rebuild) / NNGroup Design Process and Deliverables (17 Articles · Exploration 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). Images/original documents (including screenshots of Mozilla's issue trend graph, MVP risk-reward matrix, knowledge board kanban, flashlight model, etc.) 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) · Design Thinking Strong Teams · Team Decision Quality: Confirmation Bias/Groupthink/Written Thinking · UX 6-Stage Maturity and Biggest Challenges · Refine/Remodel/Rebuild)
- NNGroup Design Process and Deliverables (17 Articles · Exploration 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 Qualitative Research and Research Methods Toolbox (Method Landscape/Interviews/Empathy Maps/Sample Size/Task Design/Moderation/Expert Evaluation/Workshops/Ethics)