Lightweight user research

Great design starts with understanding users, not opening Figma. Lightweight user research — a few practical methods you can actually do (even solo, even fast) — grounds your project in real needs and gives your case study credibility. This lesson covers lightweight user research. Let's understand the user first. Let's research.

Why research and lightweight methods

RESEARCH-FIRST — good UX starts by UNDERSTANDING the users + their problem, BEFORE designing.
Designing on assumptions -> solving the wrong problem beautifully. Even a LITTLE research grounds your
design in reality + massively strengthens your case study (it shows you design from evidence, not
guesses — exactly what employers want).

"LIGHTWEIGHT" = practical research you can realistically do for a portfolio project — even solo, on a
budget, quickly. You don't need a big study; a few good insights beat none. Methods:

- USER INTERVIEWS — talk to 3-5 people who fit your target user. Ask about their goals, frustrations,
  + how they currently solve the problem. OPEN questions ("tell me about the last time you...", "what's
  frustrating about..."). The richest, most doable qualitative method. Even a few interviews reveal
  real needs.
- SURVEYS — a quick Google Form to more people for broader/quantitative signal (how common is a
  problem, preferences). Good to complement interviews.
- COMPETITIVE / COMPARATIVE ANALYSIS — study existing products solving this problem: what they do
  well/badly, features, UX patterns, gaps. Cheap, fast, + reveals conventions + opportunities. Always
  doable.
- OBSERVATION / CONTEXTUAL — watch people use a current solution (or yourself) + note pain points.
- SECONDARY RESEARCH — existing articles, reviews (read app-store reviews for complaints!), studies,
  data about the problem/domain. App reviews are a goldmine of real user frustrations.
- HEURISTIC EVALUATION (for a redesign) — evaluate the existing product against usability principles to
  find concrete problems to fix.

DO WHAT'S FEASIBLE: for a portfolio project, a few interviews + competitive analysis + reading reviews
is plenty. The point is to design from SOME real insight, not pure assumption.

Research-first — good UX starts by understanding the users + their problem, before designing — designing on assumptions → solving the wrong problem beautifully — even a little research grounds your design in reality + massively strengthens your case study (it shows you design from evidence, not guesses — exactly what employers want). "Lightweight" = practical research you can realistically do for a portfolio project — even solo, on a budget, quickly — you don't need a big study; a few good insights beat none. Methods: user interviews (talk to 3–5 people who fit your target user — ask about their goals, frustrations, + how they currently solve the problem — open questions — "tell me about the last time you…", "what's frustrating about…" — the richest, most doable qualitative method; even a few reveal real needs); surveys (a quick Google Form to more people for broader/quantitative signal — how common is a problem, preferences — good to complement interviews); competitive / comparative analysis (study existing products solving this problem: what they do well/badly, features, UX patterns, gaps — cheap, fast, + reveals conventions + opportunities — always doable); observation / contextual (watch people use a current solution + note pain points); secondary research (existing articles, reviews — read app-store reviews for complaints! — studies, data — app reviews are a goldmine of real user frustrations); and heuristic evaluation (for a redesign) (evaluate the existing product against usability principles to find concrete problems to fix). Do what's feasible: for a portfolio project, a few interviews + competitive analysis + reading reviews is plenty — the point is to design from some real insight, not pure assumption.

From research to insights

THE GOAL OF RESEARCH = INSIGHTS you can act on (not just "data collected"):
- USER GOALS — what users are trying to achieve.
- PAIN POINTS / FRUSTRATIONS — where current solutions fail them (the opportunities to solve).
- NEEDS + MOTIVATIONS — what they actually need + why.
- BEHAVIOURS + context — how they currently do it, in what situations.
- OPPORTUNITIES — gaps + unmet needs your design can address.
These feed your PERSONAS + PROBLEM STATEMENT (next lesson) + drive every design decision.

SYNTHESISE — turn raw research into insight:
- After interviews/analysis, look for PATTERNS + THEMES across what you heard/found. What frustrations
  came up repeatedly? What do users consistently want? (Affinity mapping — group similar notes/quotes
  into themes — is a common technique.)
- Distil into a few KEY INSIGHTS/findings ("Users abandon the checkout because it asks for too much
  upfront", "People want X but existing apps make it hard").
- These insights become the FOUNDATION + JUSTIFICATION for your design (+ great case-study material).

DOING IT WELL:
- RESEARCH BEFORE DESIGNING — even a little; ground the project in real user understanding.
- ASK ABOUT PROBLEMS, NOT SOLUTIONS — learn users' goals/frustrations; don't ask "would you use my
  idea?" (leading). Understand the problem first.
- KEEP IT LIGHTWEIGHT BUT REAL — a few interviews + competitive analysis + reviews is enough; SOME real
  insight beats none. Don't skip research entirely.
- SYNTHESISE INTO INSIGHTS — the value is the insights (patterns/pain points/opportunities), not the raw
  data. Distil + document them.
- DOCUMENT FOR THE CASE STUDY — capture your method + key findings; it shows evidence-based design (a
  huge portfolio plus).
- STAY OBJECTIVE — listen for what users actually say/need, not confirmation of your idea.

THE PRINCIPLE: do LIGHTWEIGHT USER RESEARCH before designing — a few INTERVIEWS + COMPETITIVE ANALYSIS
+ reading reviews (feasible even solo) — to understand user GOALS, PAIN POINTS, + needs. SYNTHESISE
into a few KEY INSIGHTS that ground + justify your design (+ strengthen the case study). Design from
evidence, not assumption. Understand the user first — it makes everything after it right.

The goal of research = insights you can act on (not just "data collected"): user goals (what users are trying to achieve), pain points / frustrations (where current solutions fail them — the opportunities to solve), needs + motivations (what they actually need + why), behaviours + context (how they currently do it, in what situations), and opportunities (gaps + unmet needs your design can address) — these feed your personas + problem statement + drive every design decision. Synthesise — turn raw research into insight: after interviews/analysis, look for patterns + themes across what you heard/found — what frustrations came up repeatedly? what do users consistently want? (affinity mapping — group similar notes/quotes into themes — is a common technique); distil into a few key insights/findings ("Users abandon the checkout because it asks for too much upfront"); these insights become the foundation + justification for your design (+ great case-study material). Doing it well: research before designing (even a little; ground the project in real user understanding); ask about problems, not solutions (learn users' goals/frustrations; don't ask "would you use my idea?" — leading — understand the problem first); keep it lightweight but real (a few interviews + competitive analysis + reviews is enough; some real insight beats none — don't skip research entirely); synthesise into insights (the value is the insights — patterns/pain points/opportunities — not the raw data — distil + document them); document for the case study (capture your method + key findings; it shows evidence-based design — a huge portfolio plus); and stay objective (listen for what users actually say/need, not confirmation of your idea). The principle: do lightweight user research before designing — a few interviews + competitive analysis + reading reviews (feasible even solo) — to understand user goals, pain points, + needs; synthesise into a few key insights that ground + justify your design (+ strengthen the case study); design from evidence, not assumption — understand the user first.

The mistake beginners make

The first mistake is skipping research (designing on assumptions) — jumping to Figma with no user understanding, solving the wrong problem; do some research first. The second mistake is asking about solutions, not problems — leading questions ("would you use my app?") that get biased answers; ask about goals + frustrations. The third mistake is collecting data but no insights — notes with no synthesis into patterns/findings; distil into key insights. And thinking research needs to be huge — skipping it because a big study isn't feasible; lightweight (a few interviews + reviews) is enough. And not documenting research for the case study — doing research but not showing it; capture method + findings (evidence-based design impresses). Research first, ask about problems, synthesise into insights, keep it lightweight, and document it.

Your turn

---

Your turn

1. Research before designing: understand the users + their problem BEFORE opening Figma - even a little research grounds your design in reality and strengthens your case study (evidence-based design is what employers want).
2. Do lightweight methods: run 3-5 short USER INTERVIEWS (ask about goals + frustrations + how they currently solve it), a COMPETITIVE ANALYSIS of existing products, and read app-store REVIEWS (a goldmine of real frustrations) - feasible even solo.
3. Ask about problems, not solutions: use open questions ('tell me about the last time you...', 'what's frustrating about...') - never leading ones like 'would you use my idea?'.
4. Synthesise into insights: find patterns/themes across your research (affinity mapping), and distil a few KEY INSIGHTS (user goals, pain points, opportunities) that will ground and justify your design.
5. Document it for the case study: capture your method + key findings, since showing evidence-based design (research -> insights -> decisions) is a huge portfolio plus.

Key points

• RESEARCH-FIRST: understand users + their problem BEFORE designing (assumptions -> solving the wrong problem beautifully). Even a little research grounds the design + strengthens the case study (evidence-based, not guesses — what employers want).
• LIGHTWEIGHT methods (feasible solo/fast): USER INTERVIEWS (3-5 people — goals/frustrations/current solutions, OPEN questions — the richest, most doable), SURVEYS (broader signal), COMPETITIVE ANALYSIS (what existing products do well/badly + gaps), OBSERVATION, SECONDARY research (articles + APP REVIEWS — a goldmine of frustrations), HEURISTIC EVALUATION (for a redesign).
• The GOAL = INSIGHTS (not just data): user GOALS, PAIN POINTS/frustrations, NEEDS/motivations, BEHAVIOURS/context, OPPORTUNITIES. These feed personas + the problem statement + every decision.
• SYNTHESISE: find PATTERNS/THEMES across research (affinity mapping — group notes/quotes), distil a few KEY INSIGHTS ('users abandon checkout because it asks too much upfront') — the foundation + justification for your design.
• Do it well: research BEFORE designing (even a little), ask about PROBLEMS not solutions (no leading questions), keep it LIGHTWEIGHT but real (some insight beats none), SYNTHESISE into insights, DOCUMENT for the case study, stay OBJECTIVE. The mistakes: skipping research, asking about solutions, data-but-no-insights, thinking research must be huge, and not documenting it.