Using User Stories for Interaction Design
Team Weeknotes #1 (English)
*Read this story in loosely translated Tagalog.
I don’t know how many people working in digital (who aren’t project managers or developers), are familiar with user stories these days.
What I do know is there’s already an article debunking user stories — and asking that they be “tweaked” into job stories. This either means user stories are hitting their peak, or about to become passé. Before that happens, we want to take this moment and say why they have very particular benefits for our team.
Last week, almost all our projects went through scope changes. And scope changes are inevitable. Deadlines change, context can change, user demands can change.
And during those times, that’s when you really feel the impact of good product and project management.
Technically, User Stories are a project management tool.
Project Managers use them to:
1) Track project scope.
2) Set clear success or accomplishment metrics for each task
Particularly, if your team is using “Scrum” as a product development methodology (*Scrum is a kind of agile development style — meaning the type of project management that prioritizes “only the essential features you need for it to work” — or Minimum Viable Product. Then “let’s build on the next releases, once we have more data” — or Iterative.)
So how exactly does this benefit changing-project-scope times?
1. When you have a complete list of user stories, they act as a sort of bible or encyclopedia of everything your product does, or will do, in verbal form.
That’s pretty much why they’re useful to both product and project management.
2. Once you have that “encyclopedia” of features, the team can align and the product or project manager can say “these and only these will be developed” for this release. All other stories, wait for the next launch.
Word of warning: Writing them probably takes up twice the time that you’d think it would.
What’s so special about user stories?
Actually, nothing.
Kidding. But also, half-true. “User stories” aren’t magic. Just because you have them, doesn’t mean your project releases automatically get better.
You still need to let them into your workflow and listen to them. Almost like another teammate.
Formal answer — User stories are really a “format” or method of writing the user tasks of a product.
What makes it unique?
1. Its essential feature is that it has 3 sections: Actor, Action and “Achievement”.
- Only what type of users can do this action?
- What action can they do?
- So what? What can they do after this action?
2. Traditionally, what sets them apart is that they’re written on cards.
The ideal usage situation is: the entire team huddles in a room, discusses each card (story), rates each in terms of “Importance” and “Feasibility” or “Turnaround time”, then they’re clustered according to what goes into each release.
3. This is the practical version.
In real life, we tried cards.
It’s cute, and engaging. It fosters team discussion because you can all hold and read the cards.
So, it isn’t bad. When you have less than 20 product features.
Such as: Upload a text post, edit a text post, delete a text post, register, log-in, edit personal profile, delete a profile, follow a person, unfollow a person, post an image, delete an image, see posts from a user.
BUT, I can probably count the projects I know of, which have fewer than 20 features, on one hand.
What if your website has over 60 user tasks or stories? What if you were building a platform? What if you’re building a game? Which means, each motion, stage and reaction to an object is probably a separate task.
Enter — spreadsheets.
They aren’t as cute as cards. But they’re easier to list and sort.
Bonus round: Another benefit. Which points to why we like using them for wireframing.
It’s fun to use for design.
If I’m not mistaken, we learned that from one of our earlier Developer bosses. When a designer gets a “features list” (e.g. Carousel. [Sorry, it was 2011 that time — Carousels were the “hot new thing” for digital strategists. 2012, the hot new thing became “Parallax”.]), you’re already tying them down to an execution of an action — “Okay, so let’s put a carousel on the homepage.”
When you do that, there’s a higher tendency of similar-looking websites because non-web designers already dictate what to put on the website, based on trend or familiarity.
But, what if your main point was that the site should be able to present multiple images to users on a homepage, while allowing them to focus on just one image first, and minimizing space used? (Which is essentially the use case of the “carousel” design pattern).
This way, you allow the designers more flexibility.
You allow them to think of the “goal” and how to get there creatively. Rather than follow an execution, then look for ways to make that look creative and ornamental.
Case in point: When it was cool to redesign publishers, the websites we looked at had carousel after carousel.
Until The Verge came out with:
Same goal, different strategy.
Going back to last week. Why did we remember user stories?
Because when scope changes, it really helps to have a backlog of features and actions of everything you set out to develop, to jog the team’s memory and say “Guys, this is our roadmap”. Even when it’s usually pretty hard to update.
Note: Like I mentioned earlier, user stories aren’t the end-all, be-all of project management. It’s just one of the many ways you can document product features or user tasks. If you know what works for your team and want to share stories, we’d love to hear about them. We can even have coffee and chat sometime. Product management challenges are always fun to reminisce.
Extra reading: If you enjoyed reading about user stories, you might also want to read this article that talks about making them even more specific (“job stories”), written by the @Intercom.io team.
What we know about work, we owe — not only to our formal education and our jobs, but also to the forward-thinking designers, developers, researchers,product managers and teams who choose to share their processes and lessons (for free) on Youtube, blogs, websites and MOOC (Massive Online Open Courses) tutorials. This is the spirit of designing in the open. Where design teams show their process and what they learn along the way. This is done to grow the knowledge base of the industry, and also to get feedback and dialogue going about the work.
(If you’re interested in reading more about the beauty of open design, you can read this.)
We share what we experience in these weeknotes. To respect our clients’ confidentiality, we won’t directly post details about them. Everything we share here are the opinions (and life lessons) of the writer.
Follow our weekly updates here on Medium, Facebook or on LinkedIn, if you want to read and exchange thoughts about the interaction design process. Join our Priority Studios’ newsletter, for a monthly collection of links we found useful for work and projects.
