The previous set of notes (NNGroup Usability Testing and the Ten Usability Heuristics (full list 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 errors/competitive evaluation)) covers “how to test whether a design is good”; this set covers how design work progresses step by step, and what is delivered at each step— from “how to clarify what problem to solve before you start” (discovery), to “how to draw out the ideas in your head” (wireframes/sketches/prototypes), to “how to hand off the solution to developers” (design specs), to “what documents to use to communicate with different people” (deliverables), as well as four cross-cutting collaboration tools (expert review, workshops, storyboards, surveys).
Summarized in one sentence:Don’t rush to think about solutions first (maintain a discovery mindset in the discovery phase) → lay out problems and unknowns on the table (CSD Matrix) → sketch ideas at a coarse granularity (wireframes, sketches) → build testable prototypes (choose fidelity based on test goals) → refine after testing and hand off to developers (design specs) → use appropriate deliverables to communicate with corresponding audiences throughout the process.
The full text has five sections: 1. Discovery Phase (mindset · 7 tips · CSD Matrix · project kickoff) 2. Wireframes and Collaborative Sketching (drawing wireframes · getting stakeholders to sketch · Promptframes) 3. Prototype Fidelity (low-fidelity vs. high-fidelity · clickable vs. static) 4. Design Specs and Deliverables (spec · deliverable terminology · most commonly used) 5. Four Collaboration Tools (expert review · workshops · storyboards · in-process surveys). Each section provides core principles / Why / counterexamples.
1. Discovery Phase: Before you start designing, clarify what problem you are solving
Discovery = the work done before design starts to “figure out exactly what problem needs to be solved”. Its biggest enemy is not lack of information, but “the team already settling on a solution before doing any research.” The four articles in this section all center on fighting “premature convergence to a solution.”
1.1 Discovery Mindset: Focus on problems, not solutions
Core principle: Explorer vs. biologist under a microscope. A discovery mindset is like an explorer landing on a new continent, staying open to “what exists in the problem space”; a solution mindset is like a biologist staring at a fixed organism under a microscope — the field of view is already locked in.
Why — solution orientation triggers two cognitive biases:
| Bias | Plain-language explanation | Consequence |
|---|---|---|
| Anchoring | The team starts from a fixed solution and only validates “whether this solution works,” without asking “how the problem actually arose and who it affects” | Missing the essence of the problem |
| Confirmation Bias | Once a team favors a solution, they actively seek evidence that supports it and avoid evidence against it | Self-persuasion, building an unsuitable product |
3 tactics to avoid falling into a solution mindset:
- Reframe the Goal— Don’t write the goal as “design a tracker that can track orders,” but as the underlying problem it solves: “How to give users transparency into order fulfillment progress and increase trust.” Example: The real problem for a dashboard is “helping users make decisions with real-time data”; for a chatbot it is “providing support and reassurance when users have questions.” Problem-oriented goals naturally lead to research questions (What data do users need when making decisions? When do they need it? How will they use it?).
- Highlight Unknowns and Assumptions— In the kickoff workshop, ask “What assumptions do we hold about user needs, behaviors, and problem contexts?” and distinguish which unknowns are critical and which are merely nice-to-know.
- Icebox Favorite Ideas— Record the team’s existing solution ideas and “freeze” them first, then evaluate them after discovery research is complete.The benefit is not just preventing premature convergence: Writing ideas down makes the people who proposed them feel “I was heard,” easing their anxiety about “their idea being thrown away.”
Counterexample: Writing the discovery goal as “figure out how an AI chatbot can answer users’ key questions” — this already presupposes “we are building a chatbot,” so the team will only go on to validate whether a chatbot is feasible, without asking “what approach should actually be used to solve users’ core problems.”
1.2 7 tips for successful discovery
The discovery phase is full of uncertainty and collaboration friction. 7 practical recommendations:
| # | Tip | How to do it / key numbers |
|---|---|---|
| 1 | Secure Buy-in First | Before starting, help team members and key stakeholders understand the purpose of discovery (understanding the problem ≠ immediately designing a solution). When the team already favors a solution, use a workshop to reveal the unknowns and assumptions within it, so everyone recognizes the risk of jumping straight to the solution |
| 2 | Clarify Roles and Norms | At kickoff, clarify who is responsible for which part of the research; agree on collaboration norms, such as “each person participates in at least one user research session per week” “one short daily standup” |
| 3 | Frame the Problem | Concisely describe the problem, affected users, and why it is worth solving;avoid implying a solution in the statement |
| 4 | Prioritize Unknowns | Brainstorm and list unknowns → cluster into broad categories (e.g., merge “preferred contact time” “commonly used devices” into “user device usage and contact preferences”) → vote: “Which unknowns are most important?” “Which unknowns carry the highest risk?” |
| 5 | Timebox Discovery | Timeboxes create urgency and prevent the “planning fallacy” (underestimating task duration).7-week sample plan: Weeks 1–2 problem framing / Weeks 2–4 research / Weeks 3–5 analysis / Weeks 6–7 opportunity identification + ideation |
| 6 | All Team Members Participate in User Research | Don’t do research alone and then report back — only when members participate firsthand will they develop empathy for users, remember user stories, and avoid distortion from secondhand retelling |
| 7 | Analyze, Synthesize, and Ideate Together | After each research session, each person notes observations → cluster to find patterns → synthesize multi-source insights using service blueprints/business model canvases → use “How-Might-We” questions to guide creativity (e.g., if you find “users like to ask for help” → pose “How might we provide the help users need?”) |
Counterexample: Starting research without writing a problem statement → research goes off track and wastes time; one person doing research alone and only submitting a report → the team forms misunderstandings of users and lacks empathy.
1.3 CSD Matrix: Put "Knowns/Assumptions/Unknowns" on the Same Table
Core principle: CSD = three columns of Certainties / Suppositions / Doubts, used to help the team reach consensus on the project background. It organizes messy project perceptions into three structured categories.
| Column | Meaning | Recording Format | Example (Dog Trainer App Redesign) |
|---|---|---|---|
| Certainties | Validated, credible known information that can be used to make decisions | "We know…" "We understand…", with links to data sources in the research repository | Current dog training apps on the market are expensive and have poor user experience; coaches need to provide clients with photo/video/audio recaps of training sessions |
| Suppositions | Reasonable inferences based on preliminary research,testable | "We believe…", with source attached + the method/data needed to validate it | "We believe allowing dog owners to schedule classes on their own will increase booking volume" |
| Doubts | Open questions that are not yet understood and require further research | Phrased as questions | "Are dog owners willing to track training plans on the platform?" "Will they continue to practice with their dogs after class?" |
Advanced tip — add "rows" to organize information. In addition to the three columns, you can add rows to group similar information. Rows can be organized by: Users (groups/segments/needs/pain points), Business (goals/KPIs/key results), Technology (tools and systems), People (internal teams/resources), Process (workflows/dependencies), Status (ongoing doubts and suppositions), Priority (high/medium/low). Benefits of adding rows: you can resolve a set of doubts at once with the same research method or the same interview, and it also makes it easier to prioritize research and identify the cross-functional personnel who need to be involved.
Why — the goal is to make information "flow". The matrix is not something you fill out once and leave: as research deepens,validate doubts into suppositions, validate suppositions into certainties, or directly delete items that are no longer relevant. The ultimate goal is to "reduce doubts and increase certainties", so the team can make confident decisions based on what is known. It applies across all stages: vision and strategy / early exploration / service design / content strategy / interface and visual design / iteration prioritization. (NNGroup provides Excel and Miro templates.)
1.4 Kicking Off a New UX Project: 4 Steps to Make UX Workload "Visible"
Core principle: The two most important things for a new project — determine ① how much work is required ② what deliverables need to be produced. A personal method from an NNGroup practitioner:
- Bring a question list to the kickoff — centered on "Who are the target users? What are the users' main tasks? How will this project help the organization become more successful?"
- Expose information gaps through questions — discuss these questions verbally in the meeting. Three benefits: confirm core UX problems, deepen the team's understanding of users,reduce resistance to UX work(When people find that no one can answer certain questions, they will understand that these gaps need to be filled by the UX team, and UX work will naturally be understood and supported).
- Create plans and timelines based on information gaps — Example: If no one at the kickoff can clearly state the three core user tasks, say "Then we need user research to find the answers", mark in the plan "The UX team needs 3 days for user research", and embed this item into the main project plan.
- Pave the way for future projects — This approach keeps the team from being caught off guard by UX work,it works for both Agile and Waterfall, and in the long run improves the team's buy-in for the UX process.
2. Wireframes and Collaborative Sketching: Draw the Ideas in Your Head
A wireframe = a sketch without color or polished visuals, that only expresses "what blocks are on the page, how they are arranged, and the information hierarchy". This section covers three things: how to draw wireframes yourself, how to get stakeholders who can't draw to feel comfortable sketching, and how to use real content instead of placeholder text in the AI era.
2.1 How to Draw Wireframes (Even If You Can't Draw) in 4 Steps
| Step | What to Do | Drawing Conventions |
|---|---|---|
| 1 | Set the aspect ratio of the browser/device | Hand-drawing does not need to be precise; for precision, reference web dimensions of 1024×768 or 1920×1080 pixels, adjust mobile dimensions per device; add browser toolbars/device buttons to provide context |
| 2 | Draw navigation and search | Use rectangles for navigation bars, highlight the current link with an underline/border; represent search with a search icon + rectangular box, and search suggestions as rectangles below the box — these give the wireframe its framework and context |
| 3 | Draw the largest elements | Headings = thick lines; body text = thin lines;Images = an X drawn inside a rectangle |
| 4 | Add details (interactive components) | Dropdowns = rectangle + downward triangle; checkboxes = square (check mark when selected)/radio buttons = circle (filled when selected); buttons = rectangle + label (e.g., "Add to Cart"); banners = one or two lines of text + button/cancel icon; dialog boxes = heading + one or two lines + buttons; progress bars = partially filled rounded rectangles |
2.2 Getting Stakeholders to Feel Comfortable Sketching: The Magic Formula
Core principle (magic formula): Fat markers + tiny spaces + time limits + casually ugly examples = relaxed sketchers.
Non-design stakeholders often resist sketching ("I'm not a designer, I can't draw"), and are even more nervous when they have to draw in public. This formula eliminates anxiety through physical constraints:
| Variable | Why It Works |
|---|---|
| Fat Markers | Use thick-tipped pens like Sharpies,which physically cannot draw fine details, forcing people to focus on high-level ideas instead of polishing. (By contrast: fine-tipped Micron pens tempt people to nitpick details, which are useless in the collaborative ideation stage) |
| Tiny Spaces | Use small cards/sticky notes, or "fold a sheet of letter paper into 8 grids", draw one idea per grid; the small space forces focus on the core idea |
| Time Limits | One of the most important variables. For example, 5 minutes per idea, emphasize quantity over polish, use a timer to control the pace, and avoid overthinking and self-censorship |
| Ugly Examples | The rougher the examples you give (basic shapes + arrows + circles) the better;do not use polished sketches as examples, otherwise people will feel "the standard is too high", leading to feelings of inadequacy and being judged |
Opening setup is equally critical: ① Clearly state that the purpose is "generating ideas + collaboration", not producing a final solution; ② Use the word "sketch" instead of "design" to lower the barrier, emphasizing that details and aesthetics don't matter; ③ Encourage quantity over quality.
Don't limit sketching to interfaces. Sketching can also be used for abstract challenges such as business processes, customer experience, and employee satisfaction — provide clear guiding questions (e.g., "What does it look like when employees feel fully supported and satisfied?"), and accept diverse forms of expression (scene diagrams/charts/single objects).
Why — the value of collaborative sketching: Increases buy-in for design decisions, diverse participant backgrounds bring more ideas, the team shares a sense of ownership over outcomes, speeds up the design process, and exposes non-UX people to UX work.
2.3 Promptframes: The Evolution of Wireframes in the AI Era, Farewell to Lorem Ipsum
Core principle: A Promptframe = a deliverable that records "what content should be generated with generative AI", built on top of the layout and functionality of wireframes, replacing placeholder text (lorem ipsum) and meaningless placeholder images with realistic content. Note:It does not replace wireframes, but is a separate deliverable alongside the wireframe, used to document and support the act of "filling wireframes with real content".
Why — fake content contaminates user testing. Placeholder text/meaningless images lack realism, which confuses users and stakeholders; during testing, participants shift their attention to irrelevant details, wasting test time.Content is the core of user feedback, not the container that holds the content.
6 application steps:
- Define context and user personas — Provide the AI with: role (have the AI act as a content strategist/data analyst), organization (mission and goals), objectives (e.g., increase sign-up rate), tone (professional/friendly), definitions (industry term glossary), visual principles (color scheme/graphic style),variants (have the AI generate 2–3 content variants to support broader testing). You can upload interview reports/existing deliverables to the AI as background (e.g., ChatGPT custom GPTs that reuse context across multiple chats).
- Write and record prompts — Write prompts for each area: text (core message + placement such as button/error message + word count limit), images (subject/background/dimensions/style), data visualizations (chart type/column labels/sorting/totals/dimension formatting).
- Run prompts to fill the design — Put the content directly into the prototype;don't chase perfection(the goal is to quickly produce testable content, not to launch); split prompts that are too long into chunks.
- Optimize through collaboration and testing — Validate AI content in design reviews and user testing, adjust prompts quickly based on feedback.
- Iterate rapidly — Invest time in higher-quality content iteration.
- Manual refinement — The final prototype still requires manual improvement of content and visual fidelity; the role of Promptframes is to accelerate early iteration and collect more comprehensive feedback.
Notes / Counterexamples: ①Not suitable for executive reviews — Promptframes are only suitable for internal use by the design team; executives require deliverables with higher visual and content fidelity; ② AI content quality is uneven and requires multiple revisions; ③ Comply with your organization's AI use and data protection policies. It is especially suitable for independent designers or small teams with limited resources.
3. Prototype Fidelity: Build Something "Testable", But Choose Fidelity Based on Your Goal
A Prototype = a hypothesis — a candidate solution for a specific design problem. The most direct way to test it is to see how real users use it. The key decision is not "the more polished the better", but "how much fidelity do I need to answer the current test question".
3.1 Why Test Prototypes (And Why Those Objections Don't Hold Up)
Why: ① Saves cost (changing code is expensive, changing prototypes is cheap, especially paper prototypes); ② Avoids risk (testing designs on the final product is high-risk, prototypes expose problems early); ③ Iteratively improves the design until it is good enough.
Common objections — "You can only test naturally once the design is complete" "There's no need to adjust Agile/Waterfall processes for UX" "Don't waste resources on failed prototypes" — all ignore the value of user research: testing prototypes gives the team more confidence to optimize the design and reduces negative reactions from end users.
3.2 Three Dimensions + High-Fidelity vs Low-Fidelity Comparison
Prototypes span a range across three dimensions:Single page ↔ Multi-page / Realistic detail ↔ Hand-drawn sketch / Interactive ↔ Static.
| Attribute | High-Fidelity Prototype | Low-Fidelity Prototype |
|---|---|---|
| Interactivity | Click targets are functional, automatically respond to actions | Requires a person to switch pages in real time |
| Visuals | Realistic visual hierarchy, layout, spacing | Black-and-white sketches or simple schematics |
| Content Completeness | Contains the complete content of the final design | Simplified or placeholder content |
- Advantages of high fidelity: More realistic test scenarios, user behavior closer to real use, fewer human operational errors.
- Advantages of low fidelity: Faster to prepare, easy to adjust quickly based on feedback, encourages users and teams to give more improvement suggestions (users are more willing to speak honestly when they know "it's not finished yet").
3.3 Clickable Prototypes vs Static Prototypes: 7-Question Decision Framework
Core principle: Answer yes/no to each question; more "yes" answers → use a clickable prototype; more "no" answers → use a static prototype.
| # | Question | Tendency |
|---|---|---|
| 1 | Do you have enough time and skill to pre-set responses for all possible actions? | Yes → Clickable |
| 2 | Do you have enough time to run through tasks multiple times? | Yes → Clickable |
| 3 | Do you have enough time to test tasks and fix all issues? | Yes → Clickable |
| 4 | Is the design stable, with no need for frequent changes between tests? | Frequent changes → Static is more flexible |
| 5 | Is there no one available to act as the "computer" and manually switch pages during testing? | No one available → Clickable |
| 6 | Is the flow between screens a key focus of the research? | Yes → Clickable |
| 7 | Do users need to notice dynamic changes (color changes/animations)? | Yes → Clickable |
- Interactive (clickable) prototypes: Pros = instant responses simulate real systems, testing is closer to real use, fewer human errors let designers focus on observation; Cons = time-consuming to build (requires setting up all click targets and responses).
- Static prototypes: Pros = time-saving (no interaction implemented, time invested in page content), easy to adjust, reduces pressure (users are more willing to speak honestly when they know it's not finished), designers are more willing to revise sketches than high-fidelity mockups; Cons = manually simulating page switches can cause errors, affecting experience and test results.
Handling user interactions during testing: Briefly explain prototype characteristics before testing but do not over-explain design elements; when encountering unresponsive click targets, tell the user "this feature is not yet complete" and ask about their expected behavior; when encountering error pages, correct them as soon as possible and help the user restore context.
4. Design Specs and Deliverables: Handing Off Solutions to Development, and What Documents to Use to Communicate With Whom
4.1 Design Spec: The Handoff Document from Design to Development
Core principle: A design specification is a document that aligns the design team and development team. It details the functionality, behavior, and appearance of a design so that developers can accurately implement the design into a usable product. Most teams use a combination of Figma links (or similar design tools) + development tool task tickets (GitHub / Linear) to communicate this. Its core value is preventing the situation where "the design is finished but cannot be developed".
A design specification typically consists of two core components:
| Component | Content | Owner |
|---|---|---|
| Design File(e.g., Figma) | Interaction flows (what happens after clicking an element) · Visual design (colors/fonts/icons, with consistently named styles for reuse) · Layout system (grids + responsive breakpoints) · Interactive elements (buttons/input fields + animation transitions) · Content information (use real text and images + mark dimensions) ·Accessibility details (tab order, alt text must be separately explained) | Designers (visual/content designers, etc.), who annotate key explanations |
| Development Issue(e.g., Linear) | Objectives · Scope · Use cases · Problems the design solves · Functional and non-functional requirements (e.g., performance) · Risks and countermeasures · Screenshots or links consistent with Figma · Design updates require discussion and scheduling to avoid version inconsistency · Overly large specs can be split into multiple smaller specs | Usually written by the product owner or development team members, depending on team structure |
Typical structure of a development issue(using a "course details page" as an example): Objectives (provide users with clear, actionable course information, support decision-making, reduce navigation friction) / Scope (explicitly state included features such as course metadata, description, purchase button, responsiveness, state logic, as well as explicitly excluded features such as deep links to instructor pages, embedded comments, related recommendations) / Assumptions (data is fetched via API or CMS, browsing is available without login) / Success Metrics (conversion rate from details page to cart +X%, reduced bounce rate, increased time on page by Y seconds) / Design link / Notes (button copy "Add to Cart" vs "Enroll Now", fallback for missing metadata, accessibility, logged-in vs logged-out paths).
Design specifications are created during the design phase; before creating them, the following must be completed first: define strategic goals → user research → build interaction flows and prototypes → usability testing → optimize based on feedback.
4 tips for aligning with development: ①Invite developers to participate early(don’t wait until the design is "finished" to notify them; the spec should record behaviors/features/visuals that have already reached consensus beforehand); ② set aside time for developers to comment in the design file (raise feasibility suggestions early to make review meetings more efficient); ③ be prepared to compromise (assess what users truly need given resource constraints, weigh costs); ④ ensure design updates are documented and synced (changes are a source of chaos; modifications must be written into the spec and notified to developers through common channels).
Three real-world examples for reference: ① Small mobile navigation (Linear documents objectives + research finding "most users can navigate but one got stuck on search", Figma annotates interactions); ② Large web page (Figma uses green/yellow/red colors to mark whether pages are ready for development, red marks backend-related items); ③ Component specification (e.g., Google Material Design button component, marking states and attribute values such as height 40dp, presented as a web page rather than only in Figma).
4.2 Deliverable Glossary: Quick Reference for 50+ UX Deliverables
Core principle: Deliverables = documents/outputs used throughout the project lifecycle to record the design process, research findings, and project context. This is a terminology reference, grouping commonly confused similar items together:
| Category | Term (Chinese/English) and one-sentence definition |
|---|---|
| Information Organization | Affinity Diagram (sticky notes clustered by similarity) · Concept Map (nodes = concepts, labeled arrows = relationships) · Mind Map (central theme + subtopic tree) · Cognitive Map (visualization of a person/group’s mental model) |
| User Personas | Persona (fictional but realistic description of a target user) · Proto Persona (quick persona based on assumptions rather than research) · Qualitative Persona (based on small-sample qualitative research) · Statistical Persona (based on large-sample surveys) · Antipersona (groups that may negatively impact target users and the business, to prevent misuse) · Archetype (abstract user type, not referring to specific individuals) · Stakeholder Persona/Profile |
| Journeys and Maps | Chronological Map (general term for experiences that change over time) · User Journey Map · Experience Map (the full process of a typical user, not tied to a specific product) · Service Blueprint (relationships between service components, linked to journey touchpoints) · Ecosystem Map · Asset Map (all interface elements encountered in a task, ordered chronologically) · Relationship Map · Landscape Map |
| Flows and Tasks | User Flow (set of steps to complete a task) · Process Map · HTA (Hierarchical Task Analysis) Diagram (tasks broken into subtasks) · User-Story Map · Jobs-to-Be-Done (users "hire" a product to complete a "job") |
| Prioritization Frameworks | Kano Model (four categories: attractive/performance/must-be/indifferent) · MoSCoW (Must have/Should have/Could have/Won’t have, by Dai Clegg) · RICE (Reach/Impact/Confidence/Effort, by Intercom) · Impact–Effort Matrix · Feasibility, Desirability, Viability scorecard (IDEO) |
| Design and Visuals | Wireframe (implied) · Mockup (static high-fidelity UI with colors and images) · Prototype · Paper Prototype · Prototype Specification (text notes next to prototypes indicating font size, line spacing, etc.) · Design System · Style Guide · Mood Board · Promptframe |
| Research and Collaboration | Empathy Map · Interview Guide · Research Plan · Research Repository · Screener · Survey · Usability Report · Analytics Report · Content Inventory + Content Audit · Sketch Test (ask colleagues to draw/summarize your document, review outputs to find unclear parts) · Skill Map · Dashboard · Story · Storyboard · Scenario Map · Site Map · Interactive UX Map |
| Roadmaps | Product Roadmap (covers all areas including UX/marketing/content) · UX Roadmap · Field Roadmap (UX only, no marketing) · Specialty Roadmap (only a single UX area such as user research) · RACI Matrix (how roles participate in tasks) |
4.3 Which Deliverables Are Most Commonly Used? — Choose by Audience, There Is No "One-Size-Fits-All"
Survey of 86 UX practitioners. Most frequently created deliverables (overall): ① Static wireframes (show page layout to facilitate discussion of structure) ② Interactive prototypes (simulate real operations for testing and demos) ③ Flowcharts ④ Site maps ⑤ Usability/analytics reports.
Key insight: Different audiences require different deliverables.
| Audience | Most effective deliverables (with hit rate) | Why |
|---|---|---|
| Internal management | Interactive prototypes · Usability reports · User journey maps | Management needs to quickly see design value and core experience points; interactive prototypes let them directly see how the product works, and usability reports intuitively present data to support decision-making |
| External clients | Interactive prototypes67%· High-fidelity visual mockups47%· Competitive analysis reports34% | Most clients are not technical and prioritize intuitiveness and visuals; high-fidelity mockups impress with visual appeal, and competitive analysis shows where the design leads |
| Developers | Interactive prototypes63%· Flowcharts55%· Style guides51% | Developers focus on technical implementation and logical details; flowcharts show operational logic, and style guides provide unified standards |
Three lessons / counterexamples: ①There is no "one-size-fits-all" deliverable; choose based on audience; ②Static wireframes ≠ final solution — they are very common but are mostly used by designers themselves, lack intuitiveness, so do not treat them as finished products for clients/executives; ③ even low-fidelity interactive prototypes can help management/clients quickly understand the design. (Case: A startup used interactive prototypes to prove to clients that a new feature was feasible + used style guides to help developers implement quickly, saving 30% of time in one go.)
V. The Collaboration Trio + In-Process Questionnaires
5.1 Expert Review: Using External Experts’ Eyes for a Health Check
Core principle: An expert review is an evaluation method in which UX experts analyze a design to identify usability issues and design strengths. It is the broadest type in the "Design Review (using expert eyes to inspect)" family; there are three types of design reviews:
- Heuristic Evaluation — Evaluation based on a set of usability heuristics (e.g., Nielsen’s 10 heuristics, see NNGroup Usability Testing and the Ten Usability Heuristics (full table of 10 heuristics · application to complex applications · user pleasure hierarchy · 5-user rule for testing methods/recruitment/remote testing/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample errors/competitive evaluation)).
- Independent Design Critique — Group discussion of in-progress designs to assess whether they meet standards.
- Expert Review — UX experts inspect the system to find issues;it is the broadest, combining heuristic evaluation with other usability principles, cognitive psychology, and human-computer interaction principles.
Why — the need for an external perspective: ① More objective (not affected by internal team emotions and politics); ② Uncovers blind spots (issues the team has long ignored). "Designers cannot see problems in their own designs, just as authors find it hard to proofread their own writing." (Note: UX experts’ qualifications come from extensive real user research and practical experience, not from designing in a vacuum.)
5 core components of an expert review report: ① Usability strengths list (highlight strengths to avoid breaking good designs in subsequent improvements) ② Usability issues list (mark the area of the issue + violated principles + references) ③Severity ratings (high/medium/low, to help prioritize improvement plans) ④Improvement suggestions (provide solutions or further research directions for each issue) ⑤Best practice examples (provide successful examples for similar issues).
vs Usability Testing — complementary, not substitutive:
| Expert Review | Usability Testing | |
|---|---|---|
| Relies on | Expert knowledge + heuristics | Real user behavior |
| Good at finding | Minor issues (inconsistent fonts, color deviations) + major issues that violate best practices | Issues caused by users’ unique needs/knowledge (things experts would not think of) |
How to combine: Conduct expert review first; after resolving obvious issues, let user testing focus on discovering unexpected user behaviors.
When to conduct: At any stage of the design cycle (as long as experts are available; a prototype or finished product works) · Before a major redesign (to identify current strengths and weaknesses) · Even without major redesigns, conduct a regular review every 2–5 years to ensure the design still meets user needs. Best practice: integrate expert reviews into iteration stages to catch and fix issues early, and avoid costly major rework later.
5.2 Workshop Facilitation 101
Core principle: Workshop facilitation = the process of helping a team move toward a shared goal through objective, non-intrusive guidance. Note that it is different from moderation in user research: workshop facilitation focuses on "promoting team collaboration", rather than one-on-one interaction with participants. The facilitator’s role is to: plan and guide activities, ensure full participation from everyone,remain neutral and not dominate.
Four core facilitation goals:
- Ensure full and equal participation — create a democratic environment where everyone feels comfortable speaking up; use Diverge-Converge (individual thinking first, then sharing, then guided synthesis).
- Foster mutual understanding — build a shared language for the team, using visual tools (empathy maps/journey maps) and tangible outputs (sticky notes/voting results).
- Support inclusive and collaborative decision-making — outputs (task lists/action items/shared language) must be created collaboratively to ensure buy-in and participation.
- Drive shared accountability — clarify each person’s follow-up responsibilities to ensure post-workshop actions are executable and fairly assigned.
Six facilitation principles (apply regardless of goals or participants): ① Always listen (help people express themselves more clearly when needed) ② Create an inclusive space (encourage introverts, use prompts like "Would anyone like to add something?" "You seem to have an idea, would you share it?") ③ Welcome improvisation (respond flexibly to unexpected situations) ④ Stay authentic and transparent (openly admit when you are unfamiliar with content, focus on facilitating discussion) ⑤Avoid giving advice (stay neutral, do not say "If it were me, I would…", keep facilitation focused on process rather than content) ⑥ Embrace constructive conflict (conflict is a natural outcome of diverse opinions, and a means to build trust and achieve breakthroughs).
Facilitation toolkit = Materials + Activities + Techniques:
| Dimension | Content |
|---|---|
| Materials | Sticky notes · Markers · Whiteboards · Large-format sticky notes · Voting dot stickers · Index cards (to help record and organize ideas, visualize and retain information) |
| Activities | Post-up (freely post ideas) · Affinity Diagramming (group similar ideas) · Landscape Mapping (draw the overall structure) · Forced Ranking (prioritize items) · Storyboarding · Role Playing (explore from the user’s perspective) · Playback (review and share outputs) |
| Techniques | Silence technique (use pauses to encourage participants to fill gaps) · Balancing technique (invite others to raise opposing views) · Linking technique (redirect off-track discussions back to the topic) |
How to practice: Start in low-stakes scenarios (small internal meetings with colleagues) → Observe and assist experienced facilitators → If work opportunities are limited, facilitate for nonprofit/volunteer events → Continuously improve through practice and feedback.
5.3 Storyboard: Tell UX Ideas Visually
Core principle: A storyboard is a visual tool that uses images in a sequence of panels to show the main events of a story in chronological order. In UX, it provides contextual information for teams and stakeholders;images make the story clear at a glance and easy to remember. Basic characteristic: it does not need to be complex or high-fidelity; simple visuals + one specific scenario are sufficient.
Three core components: ①Scenario (based on a specific scenario/user story + clear persona, e.g., "James needs to restock office supplies"; the description should be clear enough to understand before viewing the images) ②Visuals (a sequence of images showing each step progressively; can be sketches/illustrations/photos, with fidelity matched to the audience; reflect the environment/speech bubbles/device interactions) ③Captions (pair each image with short text: action/environment/emotion/device, generally no more than two points).
vs User Journey Map — do not confuse them:
| User Journey Map | Storyboard | |
|---|---|---|
| Content | Primarily text-based, including behaviors/thoughts/emotions/insight points | Primarily image-based, with minimal text |
| Perspective | Big-picture perspective, a cross-departmental collaboration tool | Specific context, more suitable for small-scale internal team use |
Why use storyboards: ① Research and usability testing (convey how users interact to people who did not participate in testing; can include real quotes/body language) ② Complement journey maps (add contextual images to each stage to enhance empathy) ③ Prioritization and consensus (visualized interactions help identify and prioritize necessary features, provide a shared understanding for the whole team) ④ Brainstorming and ideation.
6 steps to create: ① Gather data (interviews/tests/metrics; if data is insufficient, storyboards can also be used for creative ideation) ② Decide fidelity (low-fidelity = sketches and sticky notes for team brainstorming; high-fidelity = produced with Adobe/Sketch for presentation and delivery) ③ Set the foundation (clarify the persona and scenario,one storyboard corresponds to only a single user path; for complex scenarios, create a separate storyboard for each path) ④ Plan steps (write down each step, connect them with arrows, and mark emotional state icons; if you are worried about drawing, start by writing steps + marking emotions first) ⑤ Create visuals + add captions (simple shapes are sufficient) ⑥ Distribute and iterate.
Counterexample: Cramming multiple user paths into one storyboard → becomes incomprehensible; each path should have its own storyboard.
5.4 In-Process Surveys: Not Just a Tool for the "Listen Phase"
Core principle: Most people mistakenly think surveys are fast and simple, and thus misuse them; in reality, survey types should be selected according to the stage of the design cycle. The 4 stages of the design cycle —Discover / Explore / Test / Listen — each has its own most suitable survey type. (Although surveys are usually categorized under the Listen phase, they can play a role in every stage with a sound strategy.)
| Stage | Stage Goal | Applicable Survey Types | Example Questions / Key Metrics |
|---|---|---|---|
| Discover | Collect background information on the problem space to ensure the right problem is identified | Discovery surveys (more qualitative, open-ended, reveal themes to dig deeper into in subsequent interviews) · Stakeholder surveys (collect goals and expectations when stakeholders are hard to schedule for interviews) · Diary study surveys (long-term recording of behaviors/interactions) | "If you could change [the product] freely, what would you change?" "On a scale of 1–7, how well does the product currently meet your needs?"; Stakeholders: "What are the main project issues? What counts as success/failure? What scope is explicitly excluded?"; Diary: "Rate your current mood" "How many times did you perform [behavior] today?" |
| Explore | Deep dive into the problem space, confirm scope and user needs (design reviews/competitive analysis/persona creation) | Statistical persona surveys (large-sample quantitative data to generate personas) · Competitor customer surveys (understand competitors’ strengths and weaknesses) | Statistical personas: "How many times have you used it in the past 7 days?" "What was the main reason you started using it?" "What is your annual household income?"; Competitors: "Satisfaction with [product] on a 1–7 scale?" "Which feature do you like most?" "What unmet problem do you hope to solve?" |
| Test | Validate hypotheses from the Explore phase (iterative usability testing); surveys are usually administered after task completion | Post-Task surveys (rate the ease/difficulty of a single task, commonly using the Single Ease Question (SEQ)) · Post-Test surveys (rate overall usability, commonly using the System Usability Scale (SUS), 10 questions, with reliable industry benchmarks) | SEQ: "How easy or difficult was this task? 1–7?" |
| Listen | Continuously collect feedback, monitor experience and emotion throughout the product usage lifecycle | NPS (Net Promoter Score) (likelihood to recommend, score ranges from -100% to 100%) · CSAT (Customer Satisfaction) · CES (Customer Effort Score) (ease of completing an action, based on the proportion of top-three high scores) · Custom listen surveys (in-context pop-ups at the end of user journeys/key operations to collect immediate feedback) | NPS: "How likely are you to recommend this product? 0–10 scale"; CSAT: "Overall satisfaction? 1–5 scale"; CES: "How easy was it to complete this task?"; Custom: "Did [feature/change] make your work easier? Agree/Disagree" |
Counterexample / Core principle: Sending out surveys casually as something "fast and simple" → leads to misuse; before deciding whether to use a survey, first clarify research goals and questions, then select the type corresponding to the stage. Surveys are good at capturing "self-perceptions and attitudes" (attitudinal data); to capture real behaviors, they must be paired with behavioral research — this is consistent with the "attitudinal vs behavioral research" point in NNGroup Usability Testing and the Ten Usability Heuristics (Full list of 10 heuristics · Application to complex applications · User pleasure hierarchy · Testing methods: 5-user rule/recruiting/remote/task scenarios/step-by-step tasks/attitudinal vs behavioral/4-step analysis/small-sample errors/competitive evaluation).
Sourced from NNGroup Topics / Organization & Design Process - UX Design Work (subset of design process, 17 articles). For usability testing and heuristic evaluation, see NNGroup Usability Testing and the Ten Usability Heuristics (Full list of 10 heuristics · Application to complex applications · User pleasure hierarchy · Testing methods: 5-user rule/recruiting/remote/task scenarios/step-by-step tasks/attitudinal vs behavioral/4-step analysis/small-sample errors/competitive evaluation); for qualitative research methods, see NNGroup Qualitative Research and Research Methods Toolkit (Method landscape/interviews/empathy maps/sample size/task design/moderation/expert evaluation/workshops/ethics); for user journey maps, see NNGroup Customer Journeys (Five elements of journey maps/seven analysis methods · Four mapping methods vs service blueprints/experience maps/empathy maps · Journey vs process vs story maps · Service design and blueprint three-line five-step · Project methodology current-future & assumptions-research · CX transformation and journey-centered design · Research foundation CUEs/user panels · Practical cases: luxury/healthcare/AI image generation); for UX strategy and roadmaps, see NNGroup UX Strategy · Roadmaps · Maps · Risk & Debt · Retrospectives · Stakeholders (21 articles · UX strategy/three stages for complex applications/CASTLE/mood boards · Roadmap roles & timelines + 5 prioritization methods + Pareto · Interaction maps/asset mapping/73.8h average time to create journey maps/skill maps · 6-step design risk + UX debt + fracture tracking RAS · 4-step Retrospective/7 elements of Postmortem · Stakeholder power-interest matrix + interviews + cross-team collaboration + RACI + Scrum responsibilities). Images/original documents (including UX Deliverables Glossary PDF) are retained in sources.
Sources and Related Materials
- NNGroup UX Strategy · Roadmaps · Maps · Risk & Debt · Retrospectives · Stakeholders (21 articles · UX strategy/three stages for complex applications/CASTLE/mood boards · Roadmap roles & timelines + 5 prioritization methods + Pareto · Interaction maps/asset mapping/73.8h average time to create journey maps/skill maps · 6-step design risk + UX debt + fracture tracking RAS · 4-step Retrospective/7 elements of Postmortem · Stakeholder power-interest matrix + interviews + cross-team collaboration + RACI + Scrum responsibilities)
- NNGroup Qualitative Research and Research Methods Toolkit (Method landscape/interviews/empathy maps/sample size/task design/moderation/expert evaluation/workshops/ethics)
- NNGroup Customer Journeys (Five elements of journey maps/seven analysis methods · Four mapping methods vs service blueprints/experience maps/empathy maps · Journey vs process vs story maps · Service design and blueprint three-line five-step · Project methodology current-future & assumptions-research · CX transformation and journey-centered design · Research foundation CUEs/user panels · Practical cases: luxury/healthcare/AI image generation)