Theory
The assumption that emptied the fest
When you designed FestConnect, you assumed the users were like you: comfortable with forms, fast typers, tech-confident. So you built for that user.
The real users turned out to be first-years from Gujarati-medium schools, on cheap phones, who had never filled an online form and found the whole thing intimidating.
You designed for a user who did not exist. The fix is not more cleverness: it is EVIDENCE. User research is how you find out who your users actually are, BEFORE you design for a fantasy.
Theory
User research, formally
User research is the systematic study of your target users: their behaviours, needs, goals, motivations and contexts: to inform design with evidence instead of assumption.
It exists to answer the questions you would otherwise GUESS: Who are they really? What do they need? Where do they struggle? What is obvious to them, and what confuses them?
The payoff is risk reduction: research catches "we are building the wrong thing" while it is still cheap to change, rather than after launch when real users have already walked away. It turns design from opinion into an informed decision.
At a glance
Kinds of user research (know the axes)
| Axis | Type A | Type B |
|---|---|---|
| Depth | Qualitative: why/how (interviews, observation) | Quantitative: how many (surveys, analytics) |
| Source | Primary: you gather it fresh | Secondary: existing data/reports |
| What it captures | Attitudinal: what people SAY | Behavioural: what people DO |
| Sample | Small, rich detail | Large, numeric patterns |
Theory
The say-do gap
One research insight worth its own paragraph: what people SAY and what they DO often differ.
Ask students "would you use a fest app?" and everyone says yes (attitudinal). Watch them actually try to register (behavioural) and half give up at the date field. The words were sincere; the behaviour was the truth.
This is why good research does not just ASK, it OBSERVES: usability tests and watching real use catch the gap that interviews alone miss. Combine attitudinal (why they struggle) with behavioural (that they struggle) for the full picture: a theme that runs into interviews and testing next.
Quiz
What is the core reason user research matters in design?
- It makes the product look more colourful
- It replaces the designer's assumptions with evidence about who users really are and what they need
- It is a legal requirement for all software
- It lets the designer avoid ever talking to users
Show the answer
It replaces the designer's assumptions with evidence about who users really are and what they need
Research exists to ground design in EVIDENCE rather than assumption: the direct cure for the you-are-not-your-user problem, revealing real users, needs and pain points before you design for a fantasy. Option A confuses research (understanding users) with visual design (a later unit). Option C invents a legal mandate; research is a professional practice, not a law. Option D is the exact OPPOSITE of research, which is fundamentally about ENGAGING users (talking to and observing them). The lesson: design decisions should rest on what you have LEARNED about users, not what you have GUESSED.
Think first
Which research for which question?
Two FestConnect questions: (a) WHY do students abandon the registration form? (b) HOW MANY students drop off at each step? Match each to qualitative or quantitative research, and note why you would want both. Then tap.
Show the answer
(a) WHY they abandon is qualitative: interviews and watching a few students reveal the reasons (confusing date field, fear of errors): rich, explanatory, small-sample. (b) HOW MANY drop off at each step is quantitative: analytics measures the drop-off numerically across many users: broad, but silent on WHY. You want BOTH: quantitative tells you WHERE the problem is (the date step loses 40%), qualitative tells you WHY (nobody understands the format). Numbers locate the wound; conversation diagnoses it. Great research pairs the two.
Watch out
Research slips
Skipping research to 'save time': the most expensive shortcut: it guarantees designing for assumptions.
Asking only, never observing: the say-do gap means self-reports mislead; watch real behaviour too.
Leading questions: "you love this feature, right?" gathers flattery, not truth (the interview lesson tackles this).
Treating yourself as a sample: one CS student is not the user base; research REAL target users.
Theory
From raw research to a usable picture
Research produces a pile of insights: but a pile is hard to design against. The next lesson turns it into something you can hold in your head and design FOR: the PERSONA: a believable model of a real user, built from research. Then the lesson after it teaches the single most important research METHOD: the user interview, and how to run one without corrupting the answers.
Summary
Key takeaways
- User research is the systematic study of target users to inform design with evidence, not assumption.
- It reveals who users really are, their needs and pain points, reducing the risk of building the wrong thing.
- Axes: qualitative (why/how) vs quantitative (how many); primary vs secondary; attitudinal (say) vs behavioural (do).
- The say-do gap: what users say differs from what they do; observe, do not just ask.
- Pair quantitative (where the problem is) with qualitative (why it happens).
- Research runs throughout, especially early, and feeds personas and requirements.
- Memory hook: research replaces guessing with knowing.