I’m determined that our digital projects, starting with our new website, are user-focused. One new tool I’ve been learning about is the user story.
For us at Sussex Students’ Union our users primarily fall into two broad categories: students and our staff/officers/volunteers.
One of the aspects of agile management that has stuck with me is the idea of ‘user stories’.
What is a user story?
A user story are concise summaries of what users need/want from something such as a piece of software or website.
They are generally structured as ‘<someone> wants <something> so that <something else>’ or more technically, ‘<a user> wants <a feature> so that <value/benefit/result>.
These are created by working with the people familiar with the service you’re developing, commonly with decidedly low-tech index cards. They aim to get at the heart of what users need and why so everyone involved can prioritise these needs and understand what the problems are rather than racing straight to solutions.
Example user stories for a students’ union website
I played around with user stories today to get a feel for how we could use them for our website project.
I went old school to begin with by digging around in the stationery cupboard for index cards – who says digital people can only use computers?!
I started by looking at the most commonly viewed pages on our website as those are the aspects I plan to prioritise in our redevelopment. These are some of the examples I came up with:
- Students want to vote in our elections because democracy (yeah still need to pin down the exact reason but ‘because democracy’ felt like an acceptable placeholder for now)
- Potential employees want to apply for jobs so they can be considered as an employee
- Students want to find out who their Student Rep is so they can contact them
- Students who run clubs & societies want to book resources so they can run their sessions
One challenge is not squeezing too much into one story, I think we’ll need to do some editing to tease out the individual components of user needs and motivations.
I found coming up with the first two chunks of information (who and what) fairly easy. Being forced to think about different types of users was useful as it is tempting to always just say ‘students’ whereas different students have different needs and goals.
Thinking about why people want to do things was interesting as previously I’ve rushed straight to ‘oh well it needs to have a membership system’ but thinking about why has useful implications for usability and content.
Next steps
Now I’m more familiar with creating user stories I’m planning to use them as part of my meetings with colleagues as part of the process to gather user needs.
That’s likely to come up with a fairly hefty list as I’ll be encouraging everyone to think ambitiously and innovatively rather than feeling constrained by what our website currently does. That means there’ll be a lot of sifting, looking for similarities and overlaps in functionality and choosing priorities.
I’ll blog once I’ve tried creating user stories with my colleagues to let you know how it goes.
Hi Jo,
I can defiantly recommend it, at NUS we use this methodology with the UnionCloud development team.
Looking forward to the follow up.
Ricky
Hey Jo,
Thank you for sharing our post about user stories with your readers! Here’s a follow up post from the PM series describing how does a life cycle of a ticket looks like: https://netguru.co/blog/tickets-in-pivotal-tracker-the-lif . Hope it will be useful as well!