Not sure what accessibility changes will have the most benefit to your existing software? Are you in the build process and need to make sure accessibility has been appropriately considered? Use this checklist as a starting point.
When we’re getting started building a digital product, we need to understand why we’re building it (in the form of a digital project brief) and who we’re building it for (which can be captured in user personas). But then we get to the question: what exactly needs to be built?
That’s where user stories come in. User stories are a way of communicating project requirements from the perspective of the end user. Here are some quick examples of what user stories can look like:
User stories are usually written on cards following this format:
As a <user persona> I want <functionality> so that <benefit / rationale>.
They are absolutely integral to the success of a digital project. They’re captured in a specific method, which we’ll outline, and then used for everything from project estimation through to prototyping, design and development, and testing.
Let’s talk more about why user stories are so important, and then we’ll dive into how to actually create them.
From a high level, user stories (compared to extraordinarily detailed written requirements, ISO 29148-2011-style) have a few key benefits:
However, discovering and writing the user stories is only step 1. Step 2 is prioritizing them. Step 3 is discussing them to ensure comprehensive understanding. Step 4 is outlining the acceptance criteria for each story so you can test them to ensure they’ve been properly met.
After those steps, user stories are continually referred to throughout the information architecture and prototyping stages of a digital project, and in quality assurance / user acceptance testing phases as well, to ensure the holistic digital product is doing what it needs to do. User stories might also get added throughout the project as you discover more information, test the prototype or product with your users or just have those “wouldn’t it be cool if…” moments.
Basically, you can’t execute on a project without knowing the details around what you’re supposed to be building and why, and user stories are the best way to accomplish that.
Capturing user stories isn’t that difficult. There’s no singular “right” way to do it – so instead, I’ll just tell you how we do it at Paper Leaf.
All of our projects start with a kickoff. We cover a lot of ground in this kickoff – from outlining initial user personas to outlining how we work using Kanban and much more. They take at least half a day, and often a full day. However, arguably the most important portion of the kickoff – assuming user stories or requirements haven’t yet been captured properly or captured at all – is around user story generation and prioritization.
The first key in capturing effective user stories is to ensure the right people are in the room. Who will be affected by the web app or mobile app you’re going to build? Who is a stakeholder? Make sure they’re in the room. That should include:
Say it with me: “Make sure they’re in the room!”
Once the right people are in the room, give everyone a Sharpie or pen and a stack of flashcards. Feel free to download and use our free user story flashcard template and print some off yourself. That way, you can be sure you’re getting the right information.
Once everyone has a pen and a stack of blank flashcards, write down the format for user stories up on the whiteboard:
As a <user persona> I want <functionality> so that <benefit / rationale>.
Then, instruct everyone to begin writing user stories down on their cards following the format above. When someone completes a user story, they are to hold the card up to the group and read it out loud, then throw the card in the middle of the table. Just keep doing that over and over, and soon you’ll have a big stack of user stories!
Sometimes it’s not possible to get all the people you want to participate in the workshop in one location. This workshop can easily be done remotely. Replace flashcards with a shared Google sheet (or a similar tool where multiple people can write and contribute simultaneously) and a virtual meeting room on Zoom, Google Meet, or one of the many other video conferencing tools.
The purpose here is not about feasibility or prioritization. It’s about generating a huge, exhaustive pile of user stories. They’ll be evaluated for feasibility and prioritization later, so tell people not to worry about that.
You don’t need to go around the room in order. Free for all!
Anyone can write a story for any type of user. For example, IT staff can write a story for an end-user group.
If you’re unclear what someone’s user story means when they read it out loud, ask. This method allows for communication, so take advantage.
That said, now isn’t the time to unpack acceptance criteria. That comes later – so don’t talk for 10 minutes about every story or else you’ll probably die in that board room.
Encourage people to write and share their stories one at a time, as opposed to sitting there writing a million user stories at once. In our experience, we’ve found that verbalizing user stories out loud is a great brainstorming tactic – it’ll spur others around the room to capture a user story they might not have otherwise thought about.
If the group gets stuck, you can prompt them. Think about the specific reasons you want to build a digital product and ask the group questions about that. For example, if you are building a mobile app that requires users to sign up for an account, what do you need to do to sign up? Another example would be if your app lets people complete an assessment – what does that assessment entail?
It’s handy, if not required, to have your user personas in front of people. Print them off, have them up on a wall, have them on a slide. Regardless, the user stories are literally stories about those users – being able to refer back to the user personas makes writing user stories way easier and more efficient.
You don’t have to get everything captured and figured out in one meeting. You won’t be able to think of every possible user story in one session. As you work through workflows, prototyping, user testing and product development, your team will find additional user stories that you hadn’t thought of before. Consider the place where you keep your user stories a living document. This will allow you to plan out releases for your product that extend well past your initial launch.
The length of this exercise is totally variable depending on the size of the project, the number and type of people in the room, and many more variables that expose themselves while deconstructing a new project. Some of our experiences with these workshops have been as short as 30 minutes and some have been as long as a couple of hours. Regardless, your group will either naturally start to slow down, or you’ll hit the time limit for your meeting agenda. If the latter happens, don’t worry – additional user stories can and should be continually discovered throughout the life of the project. This isn’t your only opportunity to capture them.
When you’re done capturing all the user stories, the next step is part 2: prioritizing them. Click through and read the next article in the series, and learn how to prioritize user stories!