Raxxid-ux UX Research Insights (Beginner)
Research data on its own doesn't tell you what to design. It's just raw material — like ingredients before cooking. This skill turns that raw material into something you can actually act on, using 4 simple steps. Go one step at a time. Don't skip ahead, even if it feels slow — this order is what makes the result reliable instead of guessy.
Why this matters
A lot of beginners either freeze when they see a pile of notes ("I don't know where to start") or jump straight to designing a solution without really understanding the problem first. Both of these lead to weak design. This method fixes both — it gives you a starting point, and it forces you to understand the problem before you try to solve it.
Before you start
Gather whatever raw material you have. This can be:
- Interview notes or recordings
- Survey answers
- Screenshots of reviews, comments, or complaints
- Your own observations from watching someone use a product
If you have nothing yet, that's okay — write down 3-5 things you've personally noticed or heard people say about the problem area. You can't skip to insights with zero raw material; there has to be something real to work from.
The 4 steps
Step 1 — Collect List out the raw facts, quotes, or things you observed, as short bullet points. Don't interpret or analyze anything yet — just write down what actually happened or was said.
Example:
- "I always forget to log my mood, I only remember when I'm already stressed"
- "The app felt like homework, not something I wanted to open"
- User closed the app after the third onboarding screen without finishing
Step 2 — Group Now look at your list and find bullets that feel related to each other. Put them into small groups. Give each group a short name, about 3-5 words, that describes the theme.
Example grouping:
- Group: "Forgets to use it" → the mood-logging bullet
- Group: "Feels like a chore" → the homework bullet
- Group: "Gives up early" → the onboarding bullet
Try to keep it to 3-5 groups total. If you have way more than that, some groups are probably really the same theme — merge them.
Step 3 — Name the pain
For each group, write one sentence using this exact format:
People feel [emotion] when [situation] because [reason].
This forces you to be specific instead of vague. "Users don't like onboarding" is vague. "People feel discouraged when onboarding has too many steps because it feels like work before they've gotten any value" is a real insight you can design against.
If you try to write this sentence and can't fill in one of the three blanks confidently, it usually means that group needs more raw data before it's ready — don't force it.
Step 4 — Point to a direction For each pain sentence, suggest one possible design direction. This is not the final solution — just a direction worth exploring further.
Example: Pain: "People feel discouraged when onboarding has too many steps because it feels like work before they've gotten any value." Direction: "Let people experience one core feature before asking them to complete full onboarding."
Common mistakes
- Jumping to solutions too early. If you start designing before you've written the pain sentence, you're guessing, not designing from evidence.
- Making too many groups. More than 5 groups usually means overlap — merge similar ones. Too many options will slow you down later, not help you.
- Using jargon without explaining it. If you use a term like "friction" or "cognitive load," add a short plain-English explanation the first time, so anyone reading it — including future you — understands it without extra research.
- Skipping straight to Step 3 without Step 1 and 2. The grouping step is what reveals real patterns instead of reacting to a single loud comment.
Checklist
[ ] Step 1: Collected raw notes/quotes (no analysis yet)
[ ] Step 2: Grouped into 3-5 clusters with short names
[ ] Step 3: Wrote one pain sentence per cluster
[ ] Step 4: Suggested one direction per pain sentence