User Research Methods: Interviews, Surveys, and Analytics

User interviews are the most powerful research tool available. A 30-minute conversation with five real users reveals more than six months of guessing. The goal is not to test your solution — it is to understand the user's world before you have a solution.

The TEDW Framework prevents leading questions that confirm existing assumptions:

• Tell me about the last time you tried to [do the thing your product does]
• Explain what was frustrating about that experience
• Describe your ideal version of that process
• Walk me through exactly what you do step-by-step

Questions to avoid:

• Would you use a feature that...? (hypothetical — people cannot predict their own future behavior)
• Don't you think it would be easier if...? (leading — suggests the answer you want)
• How often do you use X? (respondents round up — observe behavior instead)

Interview structure for a 30-minute session:

1. Warm-up (5 min): background, rapport-building, explain the session purpose
2. Context exploration (10 min): current behavior, tools used, workarounds invented
3. Specific scenarios (10 min): walk through a recent real example in full detail
4. Wrap-up (5 min): anything else they want to share, permission for follow-up contact

Aim for 5-8 interviews per user segment. After 5 interviews you will hear the same themes repeating — this saturation signals you have enough data for this research round.

Practical rules: record with permission (frees you to listen, not transcribe); embrace 3-second silences before following up; never validate or reject answers; ask 'Why?' and 'Tell me more' relentlessly; follow surprising tangents — that is where unexpected insight lives.

Surveys answer: how many users experience X? They provide statistical confidence to patterns observed in interviews. A survey cannot explain why users do things, but it validates whether a pattern is widespread or limited to a few outliers.

Likert Scale Questions measure attitudes on a 5 or 7-point scale:

'How easy was it to find the course you were looking for?' (1 = Very difficult, 5 = Very easy)

The System Usability Scale (SUS) is the industry-standard 10-question usability survey. A SUS score above 68 is above average. Below 51 is an immediate usability red flag requiring intervention.

Survey design principles:

• One question, one idea — never combine two concepts in one question
• Start behavioral ('How many times per week do you...'), end attitudinal ('How satisfied are you with...')
• Always follow closed questions with a one-sentence open-ended response: 'In one sentence, what would you change about X?'
• Target 50-100 responses for statistical validity — fewer is anecdotal
• Use conditional branching to send users down relevant paths only

Common response biases to design around:

• Acquiescence bias: users agree regardless of truth — use paired positive and negative statements
• Social desirability bias: users give answers they think you want — emphasize anonymity
• Recency bias: users describe their most recent experience, not their typical one — ask about 'a typical week'

Survey data informs CSS decisions. If 68% of respondents report difficulty distinguishing course difficulty levels, the solution is a visible difficulty badge on course cards:

1/* Difficulty badge — designed from survey data showing users cannot distinguish levels */
2.difficulty-badge {
3  display: inline-flex;
4  align-items: center;
5  padding: 0.25rem 0.625rem;
6  border-radius: 9999px;
7  font-size: 0.6875rem;
8  font-weight: 600;
9  letter-spacing: 0.05em;
10  text-transform: uppercase;
11}
12.difficulty-badge[data-level="beginner"]     { background: #dcfce7; color: #166534; }
13.difficulty-badge[data-level="intermediate"] { background: #fef3c7; color: #92400e; }
14.difficulty-badge[data-level="advanced"]     { background: #fee2e2; color: #991b1b; }

Analytics tell you what users actually do, not what they say they do. People are terrible at self-reporting their own behavior — they remember exceptions as typical and omit embarrassing steps. Analytics are honest because they record every action without interpretation.

Key metrics and their action thresholds:

Bounce rate: percentage who leave after one page. Above 70% indicates a landing page problem — mismatch between what the page promises and what it delivers.

Session duration: time spent per visit. A consistent drop signals an engagement problem — content is not meeting user expectations set by the entry point.

Funnel drop-off: the percentage of users who abandon at each step of a conversion flow. Above 50% drop-off at a single step is a clear friction signal that requires investigation.

Rage clicks: rapid repeated clicks on non-interactive elements. Any rage clicks indicate users expect something to be clickable that is not — a common UX failure when decorative elements look interactive.

Scroll depth: how far down a page users read. Below 50% scroll depth on content pages indicates above-the-fold content is not compelling enough to motivate continued reading.

Forming a research hypothesis from analytics:

1. Observe: 73% of users drop off at the payment step
2. Hypothesize: users may be surprised by the total — they saw $49 on the course page but see $54 at payment after fees are added
3. Research method to validate: run 5 interviews with users who abandoned checkout; ask them to walk through what happened
4. If validated: add fee transparency earlier in the pricing display (a design decision backed by evidence)

The analytics plus interview loop is the core research cycle: analytics show where the problem is; interviews reveal why it exists. Neither method alone is sufficient for confident design decisions.

Implement analytics-informed components with data attributes for event tracking:

1<!-- Analytics identified rage clicks on this bookmark icon (it was a div, not a button) -->
2<!-- Fix: make it a focusable, interactive button element -->
3<button
4  type="button"
5  class="icon-btn"
6  aria-label="Save to reading list"
7  aria-pressed="false"
8  data-track="course-save"
9  data-course-id="react-hooks-deep-dive">
10  <svg aria-hidden="true" focusable="false" width="20" height="20">
11    <use href="#icon-bookmark"></use>
12  </svg>
13</button>

1.icon-btn {
2  display: inline-flex;
3  align-items: center;
4  justify-content: center;
5  width: 2rem;
6  height: 2rem;
7  border-radius: 0.5rem;
8  border: none;
9  background: transparent;
10  color: #6b7280;
11  cursor: pointer;
12  transition: background-color 150ms ease, color 150ms ease;
13}
14.icon-btn:hover { background: #f3f4f6; color: #111827; }
15.icon-btn[aria-pressed="true"] { color: #2563eb; }
16.icon-btn:focus-visible { outline: 2px solid #2563eb; outline-offset: 2px; }

Raw research data is not actionable. Synthesis converts raw data into design opportunities by finding patterns across multiple data sources and connecting them to specific implementation decisions.

Affinity Mapping process:

1. Write each research observation on a sticky note — one observation per note
2. Group notes that address similar themes without forcing categories
3. Name each group with a 'How might we...' opportunity statement
4. Prioritize groups by: impact (how many users affected) multiplied by severity (how much it blocks the goal)

Insight statement structure:

'We noticed that [observation from research]. We believe this is because [interpretation]. This creates an opportunity to [specific design action].'

Example from a real synthesis:

'We noticed that 68% of survey respondents said finding the right course took over 10 minutes. Interviews revealed users could not distinguish beginner from intermediate content from the course card alone. This creates an opportunity to add a visible difficulty indicator directly on course cards — positioned on the thumbnail image so it is visible before the user reads any text.'

This connects: quantitative data (68% measurement) + qualitative data (interview explanation) + specific design action (course card badge position).

The CSS implementation that traces back to this specific research synthesis:

1/* Course card — thumbnail-positioned badge is the direct output of research synthesis */
2.course-card { position: relative; border-radius: 0.75rem; overflow: hidden;
3               border: 1px solid #e5e7eb; background: white; }
4.course-card-thumbnail { position: relative; aspect-ratio: 16/9; overflow: hidden; }
5.course-card-thumbnail img { width: 100%; height: 100%; object-fit: cover; }
6
7/* Badge on thumbnail — not in body — because research showed users decide on the thumbnail */
8.course-card .difficulty-badge {
9  position: absolute;
10  top: 0.75rem;
11  left: 0.75rem;
12  z-index: 1;
13}
14.course-card-body { padding: 1rem; }
15.course-card-title { font-size: 1rem; font-weight: 600; margin: 0 0 0.375rem; color: #111827; }
16.course-card-meta { font-size: 0.8125rem; color: #6b7280; }