UI/UX Design Understanding Users
Every design decision you make is a guess until you talk to real users. A persona built on assumptions creates a product for a fictional person. A persona built on real research creates a product for real people. This topic covers how to conduct user research and how to turn your findings into useful personas that guide your entire design process.
What Is User Research
User research is the practice of collecting information directly from the people who will use your product. It answers questions that no team member — no matter how experienced — can answer from inside a meeting room:
- Who exactly are our users?
- What are they trying to accomplish?
- What frustrates them about current solutions?
- What words do they use to describe their problems?
- When, where, and how do they use similar products?
Research does not replace good design judgment. It informs it. Experienced designers combine research findings with their design expertise to make better decisions faster.
Two Types of User Research
Qualitative Research
Qualitative research produces stories, observations, and quotes. It tells you the "why" behind user behavior. Methods include interviews, observation, and diary studies. This type of research works with small groups (5-15 people) and produces rich, detailed insights.
Quantitative Research
Quantitative research produces numbers and statistics. It tells you the "what" and "how many" of user behavior. Methods include surveys, analytics, and A/B testing. This type works with large groups (hundreds or thousands) and produces measurable patterns.
RESEARCH TYPE COMPARISON DIAGRAM QUALITATIVE QUANTITATIVE ----------- ------------ Interviews Surveys Observation sessions Web analytics Think-aloud testing A/B testing Diary studies Heat maps Focus groups Task completion rates Answers: WHY do users behave Answers: WHAT do users do and this way? HOW OFTEN? Sample size: 5-15 people Sample size: 100-10,000+ people Output: Rich stories and insights Output: Statistics and percentages Best used: Early in design Best used: Late in design process process to validate decisions
How to Conduct User Interviews
A user interview is a structured conversation with a person who represents your target audience. It typically lasts 30-60 minutes and uses open-ended questions to explore the user's thoughts, behaviors, and experiences.
Before the Interview
Write a discussion guide — a list of topics and questions you plan to cover. The guide keeps you on track without making the conversation feel rigid. Good interview questions have these characteristics:
- Open-ended (cannot be answered with yes or no)
- Non-leading (do not suggest the answer you want to hear)
- Focused on behavior rather than opinions ("What did you do?" rather than "What do you think?")
- About past experience rather than hypothetical future behavior
QUESTION QUALITY COMPARISON BAD QUESTIONS: "Would you use a feature that reminds you to buy milk?" Problem: Hypothetical, leading, yes/no "Don't you find grocery apps confusing?" Problem: Leading, yes/no GOOD QUESTIONS: "Walk me through the last time you went grocery shopping." Good: Behavior-based, open-ended, specific past event "What happened when you ran out of something you forgot to buy?" Good: Reveals real pain points through specific story "How do you currently manage your shopping list?" Good: Open, reveals actual workflow, not assumed one
During the Interview
Start with easy, comfortable questions to build rapport. Move toward specific topics once the user feels relaxed. Listen far more than you speak. When something interesting comes up, dig deeper: "Can you tell me more about that?" or "Why did that bother you?" These follow-up questions reveal the most valuable insights.
Never defend your product during an interview. You are there to learn, not to persuade.
After the Interview
Write up your notes immediately — within an hour of the session. Human memory degrades quickly, and the subtleties of tone and body language fade fast. Highlight the three most important things you learned from each interview.
Affinity Mapping: Organizing Research Findings
After conducting several interviews, you have a large collection of quotes, observations, and notes. Affinity mapping turns this unstructured information into organized themes.
AFFINITY MAP DIAGRAM
Step 1: Write each observation on a separate sticky note
"User forgot to check the app before leaving home"
"User added 12 items at once using voice instead of typing"
"User shared the list with their partner in a text message"
Step 2: Post all notes on a wall or digital board
Step 3: Group related notes together
GROUP A: Memory and Reminders
- Forgot app before leaving
- Wished app sent alerts
- Often buys duplicates
GROUP B: Input Methods
- Used voice for speed
- Found typing slow while cooking
- Wants image-based input
GROUP C: Sharing and Collaboration
- Shared list via text (workaround)
- Partner added items separately
- List got out of sync
Step 4: Name each group -- these become your design focus areas
What Is a User Persona
A user persona is a fictional but research-based representation of a key user group. It combines patterns found across multiple interviews into one clear, readable profile. Personas give the entire design team a shared picture of who they are building for.
The critical difference between a good persona and a bad one:
- A good persona is built from real research with real users
- A bad persona is built from team assumptions about imagined users
A bad persona is worse than no persona because it creates false confidence. The team believes they understand their users when they actually built a caricature of their own preferences.
What a User Persona Includes
PERSONA TEMPLATE DIAGRAM ┌─────────────────────────────────────────────────────────┐ │ NAME: Priya Sharma │ │ AGE: 34 OCCUPATION: Software Engineer │ │ LOCATION: Bengaluru, India │ │ PHOTO: [Profile icon placeholder] │ ├─────────────────────────────────────────────────────────┤ │ BACKGROUND │ │ Priya works long hours and manages her household │ │ independently. She shops once a week but frequently │ │ forgets items. She is comfortable with technology │ │ and uses 5-6 apps daily. │ ├─────────────────────────────────────────────────────────┤ │ GOALS │ │ • Buy everything in one trip without forgetting items │ │ • Spend less time planning and more time doing │ │ • Share list with partner without friction │ ├─────────────────────────────────────────────────────────┤ │ FRUSTRATIONS │ │ • Forgets to open the app before reaching the store │ │ • Typing on a small screen while cooking is hard │ │ • Partner uses a different list app, causing conflicts │ ├─────────────────────────────────────────────────────────┤ │ BEHAVIORS │ │ • Builds list in 2-3 separate sessions, not one go │ │ • Uses voice input when hands are occupied │ │ • Checks list while walking through store aisles │ ├─────────────────────────────────────────────────────────┤ │ QUOTE FROM RESEARCH │ │ "I end up at the store and realize I forgot half the │ │ things I actually needed. It's so frustrating." │ └─────────────────────────────────────────────────────────┘
How Many Personas to Build
Most products serve 2-4 distinct user types. Build one persona for each distinct type. Do not create more personas than you have evidence for — too many personas dilute the team's focus.
A grocery app might have:
- Primary persona: The busy professional who shops weekly and needs efficiency
- Secondary persona: The parent managing a large family's needs and sharing with a spouse
- Edge persona: The elderly user who shops in person and needs large text and simple steps
Design primarily for the primary persona. Ensure the secondary persona's core needs are met. Consider the edge persona when making accessibility decisions. Never design equally for all three — designing for everyone usually serves no one well.
Jobs to Be Done: An Alternative to Personas
Some design teams use a framework called Jobs to Be Done (JTBD) instead of or alongside personas. The JTBD framework focuses on the task or goal a user is trying to accomplish rather than on who the user is.
A "job" follows this format:
When [situation], I want to [motivation], so I can [expected outcome].
Example:
When I realize I am running low on an item while cooking, I want to quickly add it to a list, so I can remember to buy it without interrupting what I am doing.
PERSONA VS JTBD COMPARISON PERSONA TELLS YOU: Who the user is (age, job, habits, goals, frustrations) Useful for: Building empathy across the design team JTBD TELLS YOU: What the user is trying to accomplish and why Useful for: Defining features and evaluating design solutions USED TOGETHER: Priya (persona) + "When cooking, I want to add items fast" (JTBD) = Full picture of user identity AND motivation
How to Use Personas During Design
A persona that lives only in a document is useless. Personas must be used actively throughout the design process.
Decision Making with Personas
When facing a design decision, ask: "What would Priya do here?" This grounds abstract decisions in concrete user behavior. "Priya is cooking with one hand — she cannot type. She needs a voice input option" is far more actionable than "Some users might prefer voice input."
Prioritization with Personas
When the team debates which features to build first, the primary persona decides. Build what serves the primary persona's core goal first. Features that serve only edge-case users can wait.
Persona Posters
Many teams print persona posters and display them in their workspace. Keeping the user visible during daily work keeps the team grounded in user needs rather than personal preferences.
When Research Is Limited
Some projects have tight timelines or small budgets. When full research is not possible, use these faster alternatives:
- Guerrilla research: Stop 5 people in a coffee shop or library who represent your target users and spend 10 minutes asking them key questions. Fast, cheap, imperfect but far better than nothing
- Expert review: Find a domain expert — a doctor for a health app, a teacher for an education app — and interview them for 60 minutes. They represent many users' perspectives
- Desk research: Read competitor reviews on app stores, Reddit threads, and product forums. Users write surprisingly honest accounts of their frustrations in public reviews
RESEARCH OPTION COMPARISON FULL RESEARCH: Time: 3-4 weeks Cost: Medium-high Output: Rich, validated personas GUERRILLA RESEARCH: Time: 1-2 days Cost: Very low Output: Directional insights, unvalidated patterns DESK RESEARCH: Time: Half a day Cost: Free Output: Existing user language and frustrations from public forums Always do at least desk research -- no excuse exists for zero research
Key Points
- User research answers questions that no team member can answer from assumptions alone
- Qualitative research gives you the "why" behind behavior; quantitative research gives you the "what" and "how many"
- Good interview questions are open-ended, non-leading, behavior-based, and focused on past experience
- Affinity mapping organizes research findings into themes that guide design decisions
- A user persona is a research-based profile of a key user group — built from real data, not assumptions
- Most products need 2-4 personas; design primarily for the primary persona
- Jobs to Be Done is a complementary framework that focuses on user goals rather than user identity
- Personas must be used actively in decision-making and prioritization — not just filed away in a document