These use cases are clear, written in plain English, and they are also as short as possible. They provide information about who the user is, and what they want from their interaction with our site. They allow other collaborators to make decisions about how to implement this user story within their field of expertise.

In order to be effective, a user story needs to be precise about the user, the requested feature, and the reason for the request. The user story needs to be large enough to be meaningful to a user, but small enough to be a fairly short task for a developer or designer. If the feature would take more than one day to build, it is probably better broken down into multiple user stories.

What a User Story Isn’t:

Here are some examples of ineffective user stories, and some comments about why they are not ideal.

• This user story is not specific enough to the user role. The target user in this user story likely isn’t your everyday user. It’s probably an administrator requesting this feature. It is also not exactly clear here what “manage advertisements” means here.
• This should be broken down into corresponding sub-tasks (As an admin, I want to add and delete ads, etc.)

• Good user stories do not tell the designer what colors to use, or the software engineers what languages or frameworks to use. They describe outcomes and will leave the designers and the engineers flexibility in how best to achieve that outcome.
• Instead try: As a user, I want discount prices to be visually distinct from the other prices so that I can easily make price-conscious purchasing decisions.

Why do we need user stories?

If they are not careful, designers and engineers can easily stray from thinking about our intended user while designing websites and web applications. We are so familiar with every last detail of our products, that we can easily forget to prioritize what the users really need. User stories are a good way of making sure that our goals are always aligned with user needs and desires. This can be challenging, especially when we are collaborating with lots of stakeholders, and designing for many different user stories.

For example, a college running a website might initially ask all of their different departments what they want to display, and then give some space on the homepage to all of them. The resulting homepage would then have equal sections for the history, math, and computer science departments, and more.

However, the sum of all of the stakeholders doesn’t always lead to a product that is usable. All of the stakeholders should be consulted, but they should all be driven to consider user needs throughout the process. Let’s re-imagine this example with the user in mind.

What would some user stories look like for a college example?

• As an applicant, I want to be able to access and check the status of my application.
• As a student, I want to navigate quickly to the course page for the courses I’m enrolled in.
• As a faculty member, I want to be able to get to my grade book with as few clicks as possible.
• As a community member, I want to be able to keep up with newsworthy happenings by visiting the homepage.

These user stories would lead us to build a homepage that has functions largely like a news site, with tags for the different departments, and that has visually clear navigation options for applicants, students, and faculty.

Next Steps

Though the concept may seem simple, there is beauty in the simplicity of the conventions provided by user stories. Try to think about and write down user stories the next time you are building, modifying, or evaluating a site or app.

Using user stories will help you plan and execute great user-centered designs!

'The Codecademy Team, composed of experienced educators and tech experts, is dedicated to making tech skills accessible to all. We empower learners worldwide with expert-reviewed content that develops and enhances the technical skills needed to advance and succeed in their careers.'