As a blog reader, [Your Name Here] wants to read an accurate and informative post on web design, so that you learn something to help your career.
That’s a user story in a nutshell, but don’t let their brevity fool you. These “short stories” actually hold a lot of weight and practical application in the design process, as long as you know how to use them.
In this piece, we’ll cover everything you need to know about user stories, from how to write them to what to do with them. First things first, though, you need to know why they’re important, and how they’re key to great UX.
User stories succinctly summarize a user desire in a way that’s easy to organize. One want, one story. Designers can then gather all the user stories together and prioritize them, giving the team a clear idea of which features, additions, or revisions to make, and in which order. These stories also help estimate the project’s timeline, with each story representing a few weeks worth of work.
Every design element you add to your site should have a corresponding user story. This is the same as saying “don’t add unnecessary elements to your design.” User stories focus on both specific user types and their needs, so if you have to force a user story for a feature, it’s either superfluous or intended for a user type that you’re not targeting.
Once you have a collection of user stories, you can use them to prioritize your workflow, especially for a design sprint. User stories were originally created as an efficient way to organize Product Backlog Items in agile and scrum methodologies.
Design teams go down the list of user stories, implementing the most consequential first. This system works perfectly with design sprints, another popular agile practice.
As an bonus, user stories also make great documentation. They’re compact and comprehensive, but more formal and informative than a basic list of user wants.
Writing for UX Booth, UI/UX Architect Tom Brinton lists out three practical advantages to the user story approach:
1. Focuses on the User. More often than not, the designer is not the target user; and yet, so many design decisions are based on their own preferences. User stories remind the design team who the users are and what they want, calibrating the entire design process around the user — where it belongs.
2. Improves Collaboration. User stories are brief and easy to understand, so they’re better at rallying the entire team in a single direction without miscommunication. Drawing on the same shared collection of user stories streamlines communication with a common language.
3. Safeguards Against Feature Creep. “Feature creep” is when a team keeps adding more and more features until the product becomes convoluted from its original intention. User stories help structure the product requirements and limit features to only those that are necessary, as defined by the user.
While mainly attuned to agile and scrum approaches, the fundamentals of user stories can be adapted to any design process. The benefits always remain the same: more structure, only the essentials, and focus on the user.
In a sentence or two (the briefer, the better), a user story must convey three core points:
Who the user is What they need Why they need it
These three details are the bare essentials of what the team must know to design a new feature or revisions effectively.
Typically, the who in the user story is one of your personas, which we’ll talk about in the next section. For this reason, it’s common to have a series of different user stories coming from the same user (representing an entire user group).
In terms of format, it doesn’t really matter as long as you cover the above three points as succinctly as possible. If you want to play it safe, you can follow the traditional format:
As a ___________, I want _____________, so that ____________.
An early adopter of user stories, the notable agile consultant and writer Bill Wake coined the INVEST acronym to outline their criteria. In his opinion, a well-written user story exemplifies these properties:
Independent — able to be understood on its own, without overlap, so that user stories can be implemented in any order. Negotiable — the essence, not the details; able to be modified as the process goes on. Valuable — essential to the product. Valuable to the user, not the design team. Estimable — comprehensive enough that it can be fit into the design process with realistic results. Small — in scope of the amount of work; typically, one card equals a few weeks of work, but no more than a month. Testable — not only is testability practical for a better end product, but it also indicates that a goal is clear and well-defined.
Use the INVEST criteria as a checklist for each user story your team completes.
Since the inception of user stories over a decade ago, designers have been coming up with tactics and techniques to make them more effective. The agile software management system Yodiz suggests these best practices:
Break up large stories into multiple smaller ones. Sometimes satisfying a single user desire requires multiple steps, and so user stories turn into user novels. Divide longer and complicated stories into a series of small, self-sustainable ones. This keeps the benefits intact for organizing and simplifying the design process.
Don’t write them just for the sake of writing them. One of the main advantages of user stories is they eliminate unnecessary features. If you’re stretching to write user stories because you think the act alone will help the design, you’ll end up producing features you don’t really need.
Hold a “grooming session.” Just because you wrote a batch of user stories doesn’t make them infallible. Team up with a group of stakeholders and team members to properly edit, whittle down, and prioritize them. Invite both technical experts and senior staff. Aim for spending an hour on this, even over lunch.
Any discussion of user stories should include at least a mention of another important user-based design document, the persona.
Personas are fictional characters based on the user behaviors and preferences of the target customers. These documents include imaginary personality traits, careers, pet peeves, understanding of technology, etc. — all based on factual user research.
The aim of personas, like user stories, is to anchor the design process to the user. Personas are a go-to reference whenever a tough design decision is made; whenever the designer asks “how would this user group react if we did this,” they have only to pull out the representative persona sheet to find out.
Personas are most effective when they’re based on real user data. We advise starting a new design project with user interviews or at least questionnaires to hone in on the specifics of the people who will use the end product.
After collecting information from enough sources, compare the data and look for patterns. Isolate these patterns and combine them into the corresponding persona. One persona per each user group.
Each persona sheet should contain at least the following information:
Name — a made-up name, often in a format like, “Wanda the Wedding Planner,” or “Sam the Small Shop Owner.” Photo — even if it’s just a stock photo, any image will make it easier to imagine the persona as a real person using the site. Demographics — standard data on age, sex, job, location, etc. Personality Descriptions — often a list of words describing relevant personality traits, such as “lazy,” “easily distracted,” or “fast learner.” Motivation — what does the user hope to accomplish, both on your site and in their own life. Knowing what your users’ life motivations are helps the design team empathize with them. Devices — on which platforms the user will access the site most. Technological Prowess — how familiar the user is with certain web trends and UI patterns. Personal Quote — it helps to encapsulate the persona’s character in a single line representing their personal philosophy.
We mention personas here because they are the users behind your user stories. Just as user stories help to organize the design process, personas help to organize user stories. Each persona will spawn a series of user stories, based on what that user group wants/needs — and a well-made persona will reveal those wants and needs more clearly.
Creating personas is a skill on its own, one we can’t do justice to here. For more information, Shlomo Goltz wrote a wonderful two-piece treatment for Smashing Magazine on how to make them successfully. You can find part one here, and part two here.
Here’s a summation of the key points for user stories we discussed above:
Each story should correspond to a single user want or need. Prioritize user stories and guide your team’s workflow. User stories keep focus on the user, improve collaboration, and defend against feature creep. Each story should answer who, what, and why. Follow the INVEST criteria for more effective user stories. Base your user stories on strong and solid personas. Do you have any questions or opinions? Share them now in the comments below.
,
What to read next