By the end of the lesson, you can describe the target user from the point of view of the task, tell a stated request apart from the underlying need, and write a user story that records a goal and value, not a screen. You recognize why it is dangerous to optimize for a single imagined "average user".
Why does this matter after the brief?
The brief named the target user, and in chapter 2 you made a persona. Here we examine how to use these in design decisions. The persona is a condensation of the research; the target user description is the project's decision filter; and the need and the user story are the language with which we turn the user's goal into a task. The three are closely connected, but play different roles.
The target user is not a demographic label
The target user is the user situation or role whose task we optimize the solution for. "A student submitting an application for the first time, who in little time wants to understand which documents they need, and fears missing the deadline" is already a usable description. It can indicate that the system must communicate the requirements, the deadline, and the success of submission clearly. It does not mean everyone is exactly like this; it means that we design the first version for this high-significance situation.
Primary and secondary actors
In a process, several people can have different tasks. The primary actor is the one whose main task we optimize for. A secondary actor is a stakeholder who takes part in the process with a different goal or task: for example the clerk who checks the data, or the supporter who gives help. In case of conflict, say who has priority on the given screen. The student form, for example, helps the student's task; the clerk's need (complete, interpretable data) still has to be taken into account.
Different abilities and circumstances
In the target user description, also think of different access situations. Some people handle the task on a phone, on a bad network; some use a screen reader or magnification; some know the jargon, while others meet it for the first time. You do not need to turn every combination into a persona, but identify the critical exclusionary conditions. If a task can be done only with a mouse and a fast network, the real audience of the service is narrower than we think.
Request, goal, and need
A user need is the value the user wants to achieve or the risk they want to avoid. A request voiced by the user is not always the underlying need. Behind "send more reminders" there can be the need that the user should not miss an important step. One solution can indeed be a notification, but it can also be a deadline calendar, a process status, a forecast, or a simpler task list. If we accept only the proposed feature, we easily miss the better solution.
It is worth distinguishing three levels:
Level
Example
Note
Request
"Add a green checkmark."
A solution idea
Goal
"I want to know that my registration succeeded."
Desired outcome
Need
"To be sure my place is secured, so I don't miss out."
Underlying value and risk
In research, therefore, ask: in what situation was the request voiced? What were they trying to achieve then? What consequence did they want to avoid? What workaround did they use? Formulate the need so that it does not contain the specific form of the interface. "The user must know for sure that their application is complete" is a need; "we need a green checkmark" is a solution idea.
User story: intent, not specification
A user story is a short statement of the user's role, goal, and expected value. Its general form:
As a [role], I want [goal], so that [value or consequence].
For example: "As a student handling an administrative matter for the first time, I want to check that I have uploaded all the necessary documents, so that my application is not rejected for being incomplete." A user story does not list buttons, pages, and database fields. Those are later solution decisions.
A good story is not too broad. "As a student, I want to handle my affairs" does not help in choosing a priority. For a semester project, you should be able to mark from the story a starting point, a successful end state, and the information needed for the decision.
How does the story relate to the others? The research shows the need and the person, the story records the goal and the value, the success criterion (chapter 1) says how we know it has been met, and the user flow (chapter 5) breaks it into steps. The test task (chapter 8) will be derived from the story and the success criterion.
Worked example: the target user and story of Mai program
The Mai program team would first build a page "for young city dwellers". The research shows, however, that the important difference is not age, but the way of planning: some look for a spontaneous program for that evening with little time; others organize for a group weeks ahead. The two situations need different information. The spontaneous searcher needs the time, location, and availability immediately; for the organizer, group size, cancellation, and shareability may matter. A semester project should choose a primary situation: the team chooses the spontaneous searcher.
Request: "Add a map!" Goal: quickly see what is nearby. Need: not to have to travel far for an event that in the end does not suit.
User story: "As a student looking for a spontaneous program, I want to compare today's events in a list by price, language, and registration requirement, so that I can quickly decide which one is worth going to."
Success criterion (as in chapter 1): finds a suitable event within two minutes, and can say whether they need to register in advance.
Common misconceptions
Claim
Clarification
"Every detail of the persona must be filled in."
Record only what changes a design decision.
"If the user asks for a feature, that is what we should build."
The feature is their solution proposal; examining the underlying goal and obstacle is the designer's job.
"Inclusivity means a separate target group."
Many access decisions make the task more robust for the whole target group.
"A user story is a short version of the development task list."
No; it records intent and value, not implementation.
In brief
The target user is characterized by situation, goal, knowledge, time, device, and risk, not demographics.
Behind a stated request there are a goal and a need; formulate the need without an interface form.
We optimize for the primary actor; the needs of secondary actors must also be seen.
A user story records a role, goal, and value, not a solution.
Review questions
What situation makes the main task especially important in your project?
Behind which feature request might there be another, deeper need?
Who is the main user on a chosen screen, and who is the affected secondary actor?
Is your user story built on a goal or on a screen?
Target user, need, and user story
Objectives
By the end of the lesson, you can describe the target user from the point of view of the task, tell a stated request apart from the underlying need, and write a user story that records a goal and value, not a screen. You recognize why it is dangerous to optimize for a single imagined "average user".
Why does this matter after the brief?
The brief named the target user, and in chapter 2 you made a persona. Here we examine how to use these in design decisions. The persona is a condensation of the research; the target user description is the project's decision filter; and the need and the user story are the language with which we turn the user's goal into a task. The three are closely connected, but play different roles.
The target user is not a demographic label
The target user is the user situation or role whose task we optimize the solution for. "A student submitting an application for the first time, who in little time wants to understand which documents they need, and fears missing the deadline" is already a usable description. It can indicate that the system must communicate the requirements, the deadline, and the success of submission clearly. It does not mean everyone is exactly like this; it means that we design the first version for this high-significance situation.
Primary and secondary actors
In a process, several people can have different tasks. The primary actor is the one whose main task we optimize for. A secondary actor is a stakeholder who takes part in the process with a different goal or task: for example the clerk who checks the data, or the supporter who gives help. In case of conflict, say who has priority on the given screen. The student form, for example, helps the student's task; the clerk's need (complete, interpretable data) still has to be taken into account.
Different abilities and circumstances
In the target user description, also think of different access situations. Some people handle the task on a phone, on a bad network; some use a screen reader or magnification; some know the jargon, while others meet it for the first time. You do not need to turn every combination into a persona, but identify the critical exclusionary conditions. If a task can be done only with a mouse and a fast network, the real audience of the service is narrower than we think.
Request, goal, and need
A user need is the value the user wants to achieve or the risk they want to avoid. A request voiced by the user is not always the underlying need. Behind "send more reminders" there can be the need that the user should not miss an important step. One solution can indeed be a notification, but it can also be a deadline calendar, a process status, a forecast, or a simpler task list. If we accept only the proposed feature, we easily miss the better solution.
It is worth distinguishing three levels:
In research, therefore, ask: in what situation was the request voiced? What were they trying to achieve then? What consequence did they want to avoid? What workaround did they use? Formulate the need so that it does not contain the specific form of the interface. "The user must know for sure that their application is complete" is a need; "we need a green checkmark" is a solution idea.
User story: intent, not specification
A user story is a short statement of the user's role, goal, and expected value. Its general form:
For example: "As a student handling an administrative matter for the first time, I want to check that I have uploaded all the necessary documents, so that my application is not rejected for being incomplete." A user story does not list buttons, pages, and database fields. Those are later solution decisions.
A good story is not too broad. "As a student, I want to handle my affairs" does not help in choosing a priority. For a semester project, you should be able to mark from the story a starting point, a successful end state, and the information needed for the decision.
How does the story relate to the others? The research shows the need and the person, the story records the goal and the value, the success criterion (chapter 1) says how we know it has been met, and the user flow (chapter 5) breaks it into steps. The test task (chapter 8) will be derived from the story and the success criterion.
Worked example: the target user and story of Mai program
The Mai program team would first build a page "for young city dwellers". The research shows, however, that the important difference is not age, but the way of planning: some look for a spontaneous program for that evening with little time; others organize for a group weeks ahead. The two situations need different information. The spontaneous searcher needs the time, location, and availability immediately; for the organizer, group size, cancellation, and shareability may matter. A semester project should choose a primary situation: the team chooses the spontaneous searcher.
Request: "Add a map!" Goal: quickly see what is nearby. Need: not to have to travel far for an event that in the end does not suit.
User story: "As a student looking for a spontaneous program, I want to compare today's events in a list by price, language, and registration requirement, so that I can quickly decide which one is worth going to."
Success criterion (as in chapter 1): finds a suitable event within two minutes, and can say whether they need to register in advance.
Common misconceptions
In brief
Review questions