User story is the humanizing part of the design process. User stories are told from the perspective of the user and are used to inspire and direct design decisions. It plays a vital role in establishing a high-level view of different tasks to be performed by users. Written from the perspective of typical users, they help you to establish the different goals your different users may have so that you can design for their different needs accordingly.
User stories help us position the users at the heart of the conversation. Short descriptions of goals and features told from the perspective of different users, user stories help you to get an understanding of the underlying goals your users have so that you can see the problem from their perspective. These follow a pattern as:
* As a [person in a particular role],
* I want to [perform an action or find something out],
* So that [I can achieve my goal of].
A user story can be written, storyboarded, or even an audio or video recording.
Seen from the perspective of a student - a user story could be like:
"As a student, I want to register for availing merit scholarship."
By using user stories to develop typical scenarios you remain focused on your users' core goals. This approach also enables you to establish expectations and develop benchmarks for typical user needs, which can be used to set clear deliverables and scope at the start of the project.
Using your user stories and scenarios as a driver it's possible to begin to map pathways through your design at a high level.
User story includes three main characteristics:
* It tells the story of the problem or need that the user will solve through a particular piece of product functionality
* It's meant to be a living story that can be updated and modified as the project evolves
* It provides sufficient information for developers and designers to understand the functional need but doesn't go into the details of how these should be addressed from a technical or design perspective
A user story has three main components viz. Summary, Details, and Priority.
The summary is basically a statement that tells the story of what the user would like to achieve. The general format for the summary is:
As a user, I can [perform a certain action or achieve a certain goal]
Let's imagine that we are building a scholarship platform that allows students to search for available scholarships and apply as per their eligibility.
Examples of user story summaries that would be needed for this type of platform include-
As a user, I can:
* create an account
* log in to my account
* reset my password
* apply for a scholarship
* search for my applications
As you can see, each user summary presents the user's goal - e.g. create an account - and as such, communicates to both the design and development team that an account creation functionality is needed here.
The details piece of a user story spells out how particular functionality will work.
Using the example of a platform for scholarship, let's take this user story:
"As a user, I can create an account"
We can then write out the following details:
* User clicks on account creation option
* User is prompted to fill in the following fields:
* The following rules will apply to each field
First and Last Name: Text-only fields. Limited to 40 characters.
Username: Text and numeric field. Limited to 20 characters.
Password: Must be at least nine characters, with at least one uppercase letter, one number, and one special character.
The priority index helps the product manager ensure that the product team is focusing on the most important features first.
The priority can be presented in any of the three different ways:
* Sizing: S, M, L (Small, Medium, Large)
* Urgency index: L, M, H (Low, Medium, High)
* MoSCoW rating: M, S, C, W (Must, Should, Could, Won't)
Several factors such as Business objectives, Functional dependencies, and Development time required influence the priority index of a user story.