How to Choose a UX Research Method
Map your research question to a 3D space: what people say vs. do (attitudinal vs. behavioral), and direct observation vs. indirect measurement (qual vs. quant). This helps you select the right tool, from surveys to A/B tests.
Screener Surveys: Your Filter for Valid User Research
A screener survey is your filter for finding the right research participants. It ensures your study includes representative users, not just anyone, by asking questions about their behaviors and demographics.
Research Objectives: From 'What If' to 'What to Test'
Research objectives translate vague business worries into specific, testable questions about user behavior. They are the blueprint for your study, ensuring you test what matters.
UX Research Questions: The 'Why' Before the 'What'
A research question is your study's North Star—the high-level "why" you're conducting research, not a question you ask users. Before writing an interview guide, define these to keep your study focused.
GDPR for UX Research: Beyond the Consent Form
GDPR forces you to treat user data with respect: collect only what you need for a specific purpose and keep it safe. It applies to all research involving personal data from EU residents. The biggest footgun is collecting data "just in case."
UX Research Repository: Your Team's Shared Brain
A research repository is your team's shared brain for user insights, preventing knowledge from getting lost. It centralizes reports, recordings, and notes, making them searchable to prevent duplicate studies. The main footgun is poor adoption.
Triangulation: Stronger UX Insights from Multiple Angles
Triangulation strengthens research by combining methods to cover each one's blind spots. For example, pair a quantitative study showing *what* users do with a qualitative one explaining *why*. The footgun is treating a single data source as definitive proof.
Formative vs. Summative Evaluation: Improve vs. Judge
Formative evaluation improves a design in progress; summative evaluation judges a finished one. Use formative tests to find and fix flaws iteratively. Use summative tests to measure a shipped product against a benchmark, like a prior version or a competitor.
Jobs to Be Done: Sell the Hole, Not the Drill
The Jobs to Be Done framework says customers 'hire' products to get a job done. Instead of selling a drill, sell the quarter-inch hole. This reframes innovation around stable customer needs, not temporary product features.
Double Diamond: Explore, Then Focus, Twice
The Double Diamond model prevents building the wrong thing by forcing two cycles of 'go wide, then narrow down.' First, explore the problem space, then define a specific problem. Second, explore solutions, then deliver a tested one.
User Flow Diagrams: Mapping the Path to 'Done'
A user flow diagram maps the exact steps a user takes in your app to complete one task. It aligns teams on product goals and gives developers a visual guide, preventing confusion and rework. The footgun: it's not a customer journey, which is far broader.
Real-time Collaboration: Figma's 'Multiplayer' Model
Real-time collaboration uses a central server as the single source of truth for a file. Instead of passing copies, users connect to the same live document, enabling simultaneous editing in tools like Figma.
Figma Comments: Annotate Designs for Better Handoff
Figma comments are the inline documentation for your designs, bridging the gap between a static screen and its intended behavior. Use them to clarify interactions and edge cases directly on the canvas. The footgun is assuming the design speaks for itself.
Design System Docs: The Product, Not the Afterthought
Treat your design system documentation as a product, not a cleanup task. It's the instruction manual that prevents your component library from being misused. It's essential for scaling a design system to ensure consistency and speed up onboarding.
Drive Design System Adoption, Don't Just Build It
Treat your design system like an internal product, not a one-off project. To drive adoption, show quick, measurable wins and offer tiered onboarding for different roles.
Versioning a Design System with Semantic Versioning
Use Semantic Versioning (MAJOR.MINOR.PATCH) to signal the impact of design system changes. This tells teams if an update is a breaking change (MAJOR), a new feature (MINOR), or a bug fix (PATCH).
Design System Governance: Preventing UI Drift
Design system governance is the constitution for your UI, defining how components evolve, not just what they are. It prevents the slow drift where production code diverges from the Figma library as teams make local exceptions.
Base Component Pattern: Your Design System's Template
Think of a base component as a master template for UI elements. Changes to the master instantly update every copy, ensuring consistency. Use it for repeated elements like buttons or icons that need slight variations.
The 8-Point Grid: A Shared Language for UI Spacing
The 8-point grid system stops spacing debates by making every dimension and gap a multiple of 8px. It's used in design systems like Google's to create consistent layouts that render cleanly across devices. The biggest mistake is breaking the rule for "feel."
Mental Models: Design for What Users Believe
A mental model is the user's internal story of how your UI works, based on past experiences, not your design spec. This is why users expect your site to work like others they've used. The footgun is assuming users share your expert model; they don't.