Track
Stage
33 methods
Facilitated sessions that align the team on the problem and surface risky assumptions before fieldwork. Lean UX clarifies goals and outcomes; Assumption Mapping ranks assumptions by how little evidence exists and how costly they are if wrong.
ResearchQualitative conversations with representative users about their needs, mental models, behaviors, and context. They reveal the "why" behind what people do, which usage data cannot.
ResearchAnalysis of behavioral usage data in tools such as LogRocket, Pendo, FullStory, or Amplitude to find trends, friction, and drop-off. It shows what happens at scale, not why.
ResearchOrganizing, coding, and analyzing raw research (interview notes, recordings, survey responses, analytics findings) into themes, insights, and opportunities.
ResearchSessions that explore and critique high-level design directions or concept sketches informed by research, to judge whether concepts address the problem, not to finalize details.
ResearchTurning insights, themes, and recommendations into a shareable report, opportunity brief, or insight deck that informs next steps.
ResearchStructured ideation and sequencing sessions that generate varied solutions and align the team on what to build. Crazy 8s produces rapid sketches, How Might We (HMW) reframes problems as opportunities, and Story Mapping sequences the user's workflow.
ImplementationSimplified wireframes, sketches, or clickable mockups outlining core workflows without visual detail, to communicate and test flows quickly.
ImplementationModerated or unmoderated sessions in which representative users attempt tasks with a low-fidelity prototype, to surface fundamental usability problems before visual design.
ImplementationRefining the prototype with detailed interactions, visual design, realistic content, and design system components, to approximate the final experience.
ImplementationTesting high-fidelity prototypes with representative users against success criteria set in advance, to see how the refined solution performs before development.
ImplementationStructured reviews that iterate designs using usability findings, stakeholder input, and engineering feasibility, to reach an approved, development-ready state.
ImplementationWorking with engineering during the build to keep design fidelity, resolve edge cases as they appear, and answer design questions in real time.
ImplementationEvaluating the live product or feature against success metrics defined beforehand, to see whether it did what they said it should. It can include moderated sessions with live users, task completion studies, or CSAT.
ImplementationUsing analytics tools (such as LogRocket, Pendo, FullStory, or Amplitude) to measure adoption, usage, and drop-off after launch against metrics defined beforehand.
ImplementationStructured questionnaires sent to representative users to collect quantitative and qualitative data on behaviors, attitudes, and needs at scale, complementing interviews with breadth.
ResearchA visual map of the end-to-end experience across touchpoints, channels, and time, showing actions, thoughts, emotions, and pain points at each stage of a defined scenario.
ResearchA collaborative technique that arranges user stories along the user's journey to visualize scope, find gaps, sequence priorities, and plan delivery slices.
ImplementationA detailed map of service delivery showing how what customers see and do (touchpoints, physical evidence) relates to staff actions (frontstage and backstage) and to supporting systems, data, and processes. It extends the journey map into operations.
ResearchOne-on-one conversations with the people who sponsor, build, sell, or support the product, to learn business goals, constraints, history, and risks. They capture the organization's view, not evidence of what users need.
ResearchField observation in which a researcher watches people do real work in their own environment and asks questions as it happens, capturing workarounds, interruptions, tools, and handoffs rather than recalled accounts. Notes can become a task analysis.
ResearchA structured review of how other products solve the same or a similar problem: direct and indirect alternatives, including workarounds, and products in other domains with a similar pattern. Findings describe the landscape, not what users need.
ResearchSystematic analysis of existing feedback (tickets, chats, reviews, NPS and CSAT comments, call notes), coded into themes with a count of how often each appears. It surfaces recurring pain points in customers' words, but over-represents people who choose to contact you.
ResearchGrouping users by shared behaviors, goals, and contexts (what people do and need, not demographics alone) and describing each group in a persona. A persona built without evidence is a proto-persona: hypotheses to label and test, not a finding.
ResearchA framework that describes needs as the progress a person wants in a situation, independent of any solution, paired with interviews that reconstruct the circumstances behind a choice to adopt or switch. It frames findings; it is not a study design.
ResearchA visual map connecting a desired outcome to customer opportunities from research, candidate solutions, and the assumption tests showing whether a solution is worth building. It keeps choices traceable to evidence but does not replace it.
ResearchShowing target users early concepts (descriptions, storyboards, sketches, demos) to learn whether they understand the idea, see value, and could fit it into their situation. It can also test the riskiest assumption before building. It tests desirability and fit, not usability; stated interest is not later behavior.
ResearchDefining, before design and build, how the team will know the work succeeded. Goals-Signals-Metrics moves from a goal, to the behavior that would signal it, to a measurable metric. HEART (Happiness, Engagement, Adoption, Retention, Task success) is a menu, not a checklist.
ImplementationTwo information architecture studies. Card sorting has participants group and label content, showing how they expect it organized. Tree testing has them find items in a text-only proposed hierarchy, before visual design. Card sorting helps create a structure; tree testing evaluates one.
ImplementationTwo expert reviews needing no participants. In a heuristic evaluation, several evaluators independently inspect an interface against recognized principles, such as Nielsen's ten heuristics, then combine and rate findings. A cognitive walkthrough asks, at each task step, whether a new user would know what to do. Both predict problems; neither observes users.
ImplementationEvaluating a design or build against an accessibility standard such as WCAG, and testing with assistive technology: screen readers, keyboard-only use, magnification, voice control. An audit finds unmet requirements; testing with people who use assistive technology shows how it works. Automated checkers find only some issues.
ImplementationA controlled online experiment that randomly assigns users to versions of an experience and compares a predefined metric between groups. A/B tests compare two versions; multivariate tests vary several elements at once and need far more traffic. They can show that a change caused a difference in behavior, not why.
ImplementationMeasuring perceived usability with a standardized questionnaire, repeated over time or across versions or alternatives. The System Usability Scale (SUS) has ten statements on a five-point scale, scored 0 to 100. UMUX-Lite has two statements and was developed with a seven-point scale (five-point variants exist, so state which). They are different instruments and their results should not be treated as interchangeable; a SUS-equivalent converted from UMUX-Lite is an estimate, not a measured SUS score. Both measure perception only, not task success, time, or behavior, which can disagree with perception.
Implementation