UI/UX Design Basics for Marketers · UX foundations for marketers · lesson 3 of 21 · 11 min
Understanding users: goals, jobs and lightweight research
Design starts with people
Every UX decision rests on assumptions about users: who they are, what they want, what they already know, and what worries them. Better assumptions — grounded in evidence — lead to better pages. You don't need a research department; lightweight methods get you most of the way.
Goals, tasks and context
For each key audience, capture:
- Goal: what they ultimately want ("Get more clients for my salon").
- Task: what they are trying to do on this page right now ("Compare booking software prices").
- Context: device, place, time pressure, language, connection quality.
- Anxieties: what might stop them ("Hidden fees?", "Is my data safe?", "Will this work in my country?").
- Knowledge: familiarity with the category and jargon.
Jobs to be done
The jobs-to-be-done idea frames users' needs as progress they're trying to make: "When [situation], I want to [motivation], so I can [expected outcome]."
Example: "When I'm launching a new product, I want to get a professional landing page live in a day, so I can start taking pre-orders before my competitors."
Job statements help you prioritize content: this user needs speed, templates and payment setup, not a long history of the company.
Proto-personas
Full research-based personas take time. Proto-personas are quick, assumption-based profiles created from what the team knows, then validated over time.
Proto-persona
Name/label: "Busy salon owner" (avoid stereotypes; focus on behavior)
Context: Runs a 3-chair salon in Lahore; manages bookings on WhatsApp
Goal: Reduce no-shows and admin time
Tasks on site: Understand features, check price in local currency, see if it works with WhatsApp
Anxieties: Cost, learning curve, staff adoption
Channels: Instagram, Facebook groups, word of mouth
Evidence: 3 sales calls, 20 support chats (update as research grows)
Mark which parts are assumptions and which are evidenced.
Lightweight research methods
| Method | What it gives you | Effort | |---|---|---| | Customer interviews (5–8) | Motivations, language, anxieties | Low–medium | | Support tickets, chats, DMs, reviews | Real problems in customers' words | Low | | Sales call notes | Objections and decision criteria | Low | | On-site surveys (one question) | Why people visit, what's missing | Low | | Analytics | What people do, where they drop | Low–medium | | Search queries (site search and search engines) | What people look for | Low | | Usability tests | Where people struggle | Medium |
Interview tips
- Ask about past behavior, not hypothetical futures: "Tell me about the last time you booked a…" rather than "Would you use…?"
- Ask open questions and follow up with "Why?" and "Tell me more".
- Avoid leading questions ("Don't you think this is easy?").
- Record (with consent) or take detailed notes; note exact phrases people use.
- Respect privacy: collect only what you need, explain how notes are used, and follow data-protection rules in your market.
Turning research into design decisions
Research is only useful if it changes something. After collecting insights:
- Cluster notes into themes (affinity mapping).
- Write insights as statements: "Salon owners worry staff won't adopt new tools."
- Turn insights into design implications: "Show a 'staff app in 5 minutes' video and a testimonial from a salon manager."
- Prioritize implications for the pages that matter most.
Worked example: a coaching program page
Research: 6 interviews and 50 DM questions. Themes: price uncertainty, time commitment, "Is this for beginners?", payment options in local currency.
Design implications: a "Who this is for / not for" section; weekly time commitment stated clearly; price shown in multiple currencies where appropriate with clear installment terms; FAQ addressing beginner concerns in the exact language people used.
Common mistakes
- Designing for "everyone".
- Personas based on demographics only, with no goals or anxieties.
- Asking people to predict future behavior.
- Doing research and then ignoring it.
Research ethics and privacy
Treat research participants with respect. Explain why you are talking to them, how long it will take and how notes or recordings will be used, and get their consent before recording. Store notes securely, remove personal details you do not need, and delete recordings when the project ends. Pay or reward participants fairly for their time, and never use research sessions as a disguised sales pitch.
Hands-on: synthesize real customer messages in one hour
You probably already own a research goldmine: DMs, support tickets, reviews, sales-call notes and chat logs. This exercise turns them into design decisions.
- Export 30–50 recent messages from one or two sources (for example, Instagram DMs and support emails). Remove names, phone numbers, emails and order numbers first.
- Paste each message onto its own card in a whiteboard tool (FigJam, Miro or plain sticky notes).
- Cluster silently for 15 minutes. Move cards that feel related together. Don't name groups yet.
- Name each cluster with a user-voice label, such as "I don't know if this works with WhatsApp."
- Write an insight and a design implication for the three largest clusters, using the template below.
INSIGHT CARD
Cluster name (user voice): _____________________________________
How many messages: ___ of ___ Sources: ___________________
Insight (what we now believe): _________________________________
Evidence (2 short quotes): _____________________________________
Design implication (what we'll change): ________________________
Where (page/section): __________________ Metric to watch: _______
Confidence: low / medium / high Next research step: __________
Using AI to speed up synthesis (carefully)
AI assistants can do a useful first-pass clustering of anonymized text. Keep a human in charge of the final themes, because models can over-generalize or invent patterns.
Below are 40 anonymized customer messages, one per line.
1) Group them into 4-7 themes. For each theme give: a short name in the customer's own words,
the count of messages, and 2 verbatim quotes (copy exactly; do not paraphrase).
2) List any messages that do not fit a theme.
3) Do not infer demographics or facts that are not in the text.
MESSAGES:
<paste>
Then check every quote against the source messages. If a quote does not exist verbatim, discard that theme and redo it by hand.
Privacy check: only paste anonymized data, and use a business account or tool approved by your organization. Many AI services have settings for whether your inputs are used for training; check them before you start, and follow the data-protection rules that apply to your customers (for example, GDPR or UK GDPR for EU and UK residents, and local laws in markets such as the UAE, Saudi Arabia and Pakistan).
Writing a good interview guide
Warm-up (2 min): "Tell me a bit about your business and your role."
Past behavior (10): "Tell me about the last time you [booked / bought / chose] a ..."
"What did you try first? What happened next?"
Pain points (8): "What was the most frustrating part?" "What did you do about it?"
Decision (5): "What almost stopped you?" "Who else was involved?"
Wrap-up (2): "Is there anything I should have asked but didn't?"
How to measure success
Research succeeds when it changes something measurable. For every design implication you ship, name the metric it should influence (for example, fewer pre-sale questions about fees, or higher completion of the pricing step) and check it a few weeks later.
Summary
Capture users' goals, tasks, context, anxieties and knowledge; express needs as jobs to be done; start with proto-personas and validate them; use lightweight research sources; and translate insights into specific design implications.
Video lecture: Understanding users: goals, jobs and lightweight research
Lecture coming soon · 12 chapters · about 8 minutes. Read the full transcript below.
- Understanding users
- Why it matters
- Capture five things
- Jobs to be done
- Worked example 1: proto-persona
- Worked example 2: coaching program (illustrative)
- Watch me do it: one-hour synthesis
- AI-assisted synthesis, safely
- Lightweight research sources
- Interview essentials
- Common mistakes
- Recap and try this now
Lecture transcript
Understanding users
Here's a question. Who is your landing page actually for? If your answer is everyone, you're in trouble. Pages built for everyone end up speaking to no one. The good news: you don't need a research department to understand your users. You probably already have hundreds of real customer words sitting in your inbox, your DMs and your reviews. In this lecture, you'll learn how to capture users' goals, tasks, context and worries, how to write jobs-to-be-done statements, how to build a quick proto-persona, and how to turn raw customer messages into design decisions in about an hour.
Why it matters
Why does this matter so much? Because every design decision rests on assumptions about users. What they want. What they already know. What might stop them. Better assumptions, grounded in evidence, lead to better pages. Think of it like cooking for guests. You could cook your favorite dish. Or you could ask what they like, whether anyone's allergic, and how hungry they are. Same skills, very different dinner. Research is simply asking before you cook.
Capture five things
For each key audience, capture five things. Their goal: what they ultimately want, like get more clients for my salon. Their task: what they're trying to do on this page right now, like compare booking software prices. Their context: device, place, time pressure, language, connection. Their anxieties: what might stop them, like hidden fees or will this work in my country. And their knowledge: how familiar they are with your category and its jargon. Here's the key idea. The task on this page is usually much smaller than the goal. Design for the task, and connect it to the goal.
Jobs to be done
Now jobs to be done. This frames needs as progress someone wants to make. The pattern is: when, some situation, I want to, some motivation, so I can, some outcome. For example. When I'm launching a new product, I want to get a professional landing page live in a day, so I can take pre-orders before my competitors. Notice what that tells you. This person needs speed, templates and payment setup. They do not need a long company history. Job statements help you decide what goes on the page and what doesn't.
Worked example 1: proto-persona
Worked example one, simple. A salon software company builds a proto-persona. That's a quick, assumption-based profile you validate over time. Label: busy salon owner. Context: runs a three-chair salon in Lahore and manages bookings on WhatsApp. Goal: fewer no-shows and less admin. Tasks on the site: understand features, check the price in local currency, see if it works with WhatsApp. Anxieties: cost, learning curve, whether staff will adopt it. Evidence: three sales calls and twenty support chats. And every line is marked as either assumed or evidenced. That honesty is what makes it useful.
Worked example 2: coaching program (illustrative)
Worked example two, a business scenario with illustrative numbers. A coaching business in Toronto sells a twelve-week program. The team runs six short interviews and reviews fifty DM questions. Four themes appear. Price uncertainty. Time commitment. Is this for beginners? And payment options in local currency. So they turn each theme into a design implication. A who this is for, and not for, section. Weekly time commitment stated in hours. Prices shown clearly with installment terms. And an FAQ that uses the exact words people used in their DMs. Pre-sale questions about time and fees drop over the following month.
Watch me do it: one-hour synthesis
Watch me do it. I export forty recent DMs and support emails and remove names, phone numbers and order numbers. I paste each one onto a card in a whiteboard tool. For fifteen minutes I cluster silently. No labels yet. Then I name each cluster in the customer's voice. For example: I don't know if this works with WhatsApp. For the three biggest clusters, I fill in an insight card: the insight, two exact quotes, a design implication, where it goes on the site, and a metric to watch. The whole thing takes about an hour.
AI-assisted synthesis, safely
You can speed up that first clustering with an AI assistant. Paste your anonymized messages and ask it to group them into four to seven themes, with counts and two verbatim quotes each. Then check every quote against the originals. If a quote doesn't exist word for word, the theme is suspect, so redo it by hand. And a privacy rule: only paste anonymized data, into a tool your organization has approved, and check whether your inputs may be used for training. Follow the data protection laws that apply to your customers.
Lightweight research sources
Where do you find users if you have no budget? Start with what you already own. Support tickets, chats, DMs and reviews show real problems in customers' own words. Sales call notes reveal objections and decision criteria. A one-question on-site survey, like what's stopping you from booking today, tells you what's missing. Site search terms show what people look for and can't find. Analytics show what people do and where they drop off. And short interviews with five to eight customers give you motivations and language. Most of these cost nothing but an afternoon. Combine at least two sources before you trust a theme.
Interview essentials
A quick word on interviews. Ask about past behavior, not the future. Tell me about the last time you booked a salon appointment beats would you use an app for that? People are poor at predicting their own behavior. Ask open questions, follow up with why, and tell me more. Avoid leading questions like don't you think this is easy? Record only with consent, pay people fairly for their time, and never turn an interview into a disguised sales pitch.
Common mistakes
Common mistakes. Designing for everyone. Personas built only from demographics, with no goals or worries. Asking people to predict what they'd do. Letting AI invent themes that no customer actually said. And the most common of all: doing research, then ignoring it. Research only matters if it changes something. So for every design implication you ship, name the metric it should move, like fewer questions about fees, and check it a few weeks later.
Recap and try this now
Let's recap. Capture goals, tasks, context, anxieties and knowledge for each key audience. Use jobs-to-be-done statements to decide what belongs on the page. Start with proto-personas and mark what's assumed. Mine the messages you already have, cluster them, and turn themes into design implications. Use AI for a first pass, verify every quote, and protect privacy. Try this now. Export twenty recent customer messages, reviews or support tickets. Anonymize them, cluster them into themes, and write three insight cards, each with one design implication and one metric to watch.
Key takeaways
- Capture goals, tasks, context, anxieties and knowledge for each key audience.
- Jobs-to-be-done statements focus design on the progress users want to make.
- Proto-personas are quick starting points — mark assumptions and validate them.
- Interview about past behavior, avoid leading questions and turn insights into design implications.
Try it
Review 20 recent customer messages, reviews or support tickets. Cluster them into themes, write three insight statements and one design implication for each.