One-sentence summary
A project begins with understanding the real need of the person who will use it, so before writing any code we ask, "Who is this for?" and "What do they actually need?"
Why does it matter?
In the previous lesson we chose a problem. But even a good problem is not enough on its own. The same problem can feel different to different people.
Think about an example. We build a "night light" project. For a young sibling, the light should be soft and dim, because a bright light keeps them awake. But for an adult who gets up at night for a glass of water, the same light might be too faint. Both people asked for a "night light," yet their needs are not the same.
A project built without understanding the user often ends up "working but nobody uses it." Engineers pay attention to this: they understand the need first, then design the solution. In this lesson we will learn to get to know the user before we start coding.
Key idea: A project starts with what the user needs, not with what you feel like building.
Who is the user?
The user is the person who will actually use your project. Sometimes that is you, but often it is someone else: a sibling, a teacher, a neighbour, a grandparent at home.
A project can have more than one user. In the automatic night light example:
- Main user: The small child who wakes up in the dark.
- Secondary user: The parent who switches the light on and off or changes its battery.
Describing the user
Describing the user as "everyone" does not help, because everyone's needs differ. Instead, we describe the user concretely.
| Question | Example answer (night light) |
|---|---|
| Who? | A 5-year-old child |
| Where will they use it? | In the bedroom, next to the bed |
| When? | When they wake up at night |
| What difficulty do they face? | Afraid of the dark, cannot find the switch |
| What can't they do? | Struggles to press small buttons |
Filling in this table turns the vague "someone" in our heads into a real person.
Finding the real need
People sometimes ask for a solution while the real need behind it is something else. Our job is to see the need underneath the requested solution.
Want versus need
A classic example: someone says, "I want a faster horse." What they really want is not a horse; it is the need for faster travel. Once you understand that need, you are no longer stuck on the horse and can imagine other solutions.
In the night light example:
- Want: "Let's keep the light on all the time."
- Need underneath: "To not be scared when waking up in the dark and to be able to see around."
Focusing on the need leads to a better solution: instead of leaving the light on all the time, a lamp that turns on by itself when the room gets dark and switches off when morning comes. This meets the need and does not waste battery.
Needs table
To keep needs organised, you can use a simple table. In the "Want" column you write what the user said, and in the "Real need" column you write the actual requirement underneath.
| What the user said (want) | Real need | Why does this need exist? |
|---|---|---|
| "Keep the light on always" | To feel safe in the dark | The child wakes up scared at night |
| "Make the button big" | To turn it on and off easily | Small hands struggle with a small button |
| "Not too bright" | Soft light that doesn't disturb sleep | Bright light keeps them awake |
This table reminds you later why each feature is needed. As you add a feature, you can ask, "Which need does this meet?"
How we learn: Asking and observing
Instead of guessing the user's need, we learn it in two simple ways: asking questions and observing.
Asking good questions
A good question makes the user talk without leading them. The question "Wouldn't a bright light be nice?" puts the answer in their mouth. Instead, we ask open-ended questions:
Simple questions for a user interview
1. When you wake up at night, what do you do first?
2. Why is that hard to do right now?
3. When was the last time you had this problem?
4. What have you tried so far?
5. Which part bothers you the most?These questions do not end in "yes/no"; they let the user describe their own experience.
Observing
Some things people do not say in words, but you notice them while watching. If you see your little sibling grope for the night light's switch and miss it three times, you understand the need "finding the switch is hard" without anyone saying it.
When observing, getting permission matters. If you are going to watch someone, tell them beforehand and explain why.
The user story
There is a nice way to write the need you discovered as a short, memorable sentence: the user story. Software teams use it a lot. The template goes like this:
As a [user],
I want [to do something],
because [reason / which need].Example user stories for the night light project:
As a small child,
I want the room to light up gently by itself when I wake up at night,
because I want to go for water without being scared of the dark.
As a parent,
I want to turn the light off easily with one button,
because during a daytime nap the light is not needed.Because a user story is short, it is easy to remember. At every step of the project you can ask, "Does this still serve that story?" If the answer is no, you need to rethink either the story or the feature.
Mini practice
Choose one of the projects below (or use your own):
- An automatic night light.
- A line-following robot.
- A morning "don't forget your bag" reminder.
- A sensor that alerts you when a plant's soil is dry.
Then complete these steps:
- Describe the user. Fill in the "who / where / when / what difficulty" table above for your own project.
- Write two questions. Prepare two open-ended questions to ask this user.
- Make a needs table. Create a "want → real need" table with at least two rows.
- Write a user story. Using the template above, write a one-sentence story.
If possible, ask your questions to a real person. Their answer may be different from your guess. That is a good thing, because your project gets closer to reality before it even begins.
Common mistakes
Deciding for the user
It is easy to say, "If it were me, I'd want it this way." But you are not the user. Mistaking your own taste for the user's need is the most common mistake. Ask first, then decide.
Mistaking a want for a need
Accepting a solution the user names ("keep the light on always") exactly as it is. Instead, you should ask for the real need underneath. Without finding the "why" behind the want, a good solution rarely appears.
Describing the user as "everyone"
Saying "this project is for everyone" actually describes no one clearly. A project that describes one person well usually fits others like them too.
Asking leading questions
Questions like "Wouldn't this feature be great?" push the user to agree with you. Answers from such questions are misleading. Ask open-ended, neutral questions.
Safety note
When you talk to and observe a user, keep a few rules in mind:
- Get permission. If you are going to ask someone questions or watch them, say so first; for a young sibling, ask a parent for permission.
- Don't collect personal information. Do not note things like home address, full name, school name, phone number or photos; your project does not need them.
- Ask only what is needed. Ask the questions needed to understand the need; do not pry into private matters.
- Be careful when sharing notes. If you write interview notes somewhere, do not use the person's name; a general description like "a 5-year-old user" is enough.
Understanding a user begins with respecting them. People give more honest answers when they feel safe.
Lesson summary
- A project starts with the user's real need, not with your own wish.
- We describe the user as a concrete person (who, where, when), not as "everyone."
- A want and a need are different; we look for the real need underneath the want.
- Instead of guessing the need, we learn it by asking open-ended questions and observing.
- A user story ("As a …, I want …, because …") makes the need short and memorable.
Check questions
- Who is a project's "user," and why might it not always be yourself?
- What is the difference between a "want" and a "real need"? Give an example.
- Why is describing the user as "everyone" not a good idea?
- What is the difference between a leading question and an open-ended question?
- What are the three parts of a user story?
Answers
- The user is the person who will actually use the project. Often it is someone other than you (a sibling, teacher, neighbour), because we build the project for their need, and our own taste may not match theirs.
- A want is the solution the user names ("keep the light on always"); the real need is the actual requirement underneath ("to feel safe in the dark"). Focusing on the need leads to better solutions.
- Because everyone's needs are different; saying "everyone" describes no one clearly. A project that understands one person well also fits people like them.
- A leading question puts the answer in the user's mouth ("Wouldn't this be great?"). An open-ended question lets the user describe their own experience ("When you wake up at night, what do you do first?").
- The user (who), what they want to do (want) and the reason (which need). The template: "As a …, I want …, because …".
Source and verification note
For “Understanding Users and Needs”, verification focuses on whether the relationship between Who is the user? and Finding the real need remains consistent across examples. A project page should make a result claim only when it is supported by a real prototype, test record or observation. Numbers such as cost, duration and success rate must be labelled clearly when they are estimates.
Next lesson
Doing Research: Once we understand the need, how do we research similar solutions and reliable information?