The power of user stories

When developing a website, businesses find various ways to focus on the user. Some choose to create personas to give a human face to their target groups. Others use user stories that describe the user, their needs and what motivates them. We particularly recognise the power of user stories.

Personas — putting a face to the user

You create a website for people, not for numbers and figures. Makes sense, doesn’t it? However, each target group differs in terms of their needs, their desires and what drives them. It can be difficult to bear this in mind. Personas can give you something to go on, as they are the personification of your users.

Personas can be created based on a wide range of user data — sales figures, market research, etc. The different types of users (target groups) are generalised and given ​‘personal’ characteristics, a nice profile picture, perhaps even a Facebook page. Posters are printed and put up on the walls for everyone to see. There you go – your user has come to life.

Personas can help you think from the user’s perspective, but in our experience, using personas does not yield the desired results. Personas are often too general and abstract to serve their purpose. Furthermore, the layer of abstraction remains firmly in place: ​“This is Richard, but what is he trying to achieve? And why?” At the end of the day, it’s simply very hard to keep a fictional character alive.
 

User stories — who, what, why

User stories are the building blocks of Agile projects. Scrum projects often consist of short sprints lasting 2 – 3 weeks. User stories are written to ensure the user’s perspective is taken into account within such a short timeframe. The user stories are prioritised (by user impact and business impact) and estimated by the team. The product owner and team then assign stories to sprints.

Whilst personas often remain generic and abstract, user stories go deeper. User stories tell you who the user is, what she wants to do on the website and, most importantly, why. Furthermore, user stories are brief, straightforward and tell you exactly what the user’s purpose is. Taken as a whole, they become concrete and actionable, as in the following example:

‘As an existing customer, I want to change my personal details so the bill will be delivered at the right location.’

The user story above provides concrete answers to the three questions (who, what, why). Now we can consider possible solutions. Bear in mind, however, that it is important to formulate a user story correctly and not like this:

‘As an existing customer, I want to log in so I can change my personal details.’

Unfortunately, we often come across user stories written like this – ones that contain a (possible) solution. Or user stories that are little more than thinly veiled requirements. But a proper user story focuses solely on the user’s need and motivation. A user does not visit a website simply to log in. An innate desire drives the user – in this case, to the login screen. You can avoid mentioning solutions in user stories by asking ​‘why’ until you get to the heart of the matter.

Reading the first user story, you might be convinced that a login screen is a viable solution. Why is it necessary — or at least very convenient — to avoid this?

If you do not mention the (possible) solution, you are forcing yourself to broaden your horizons. You might come to the conclusion that logging in isn’t necessary. But you wouldn’t reach this conclusion if you’d mentioned the login screen in your user story. A good user story enables the creative mind to think beyond ​‘standard solutions’ and helps you understand what users really want in the end.

A common language

Of course, developing a website is not just the web team’s responsibility. Developers, testers, marketers, stakeholders and others are involved as well. User stories help when sharing developments and ideas.

Let’s take stakeholders as an example. At a demo, you might show a login screen with the words ​“This is a login screen, and this is where the customer updates their details”. All sorts of sensible and nonsensical discussions might follow. But is that what you want? Or will you let users and user stories guide your presentation? You can explain which user stories have been formulated, how business goals are incorporated into them, which user stories have been prioritised — and why — and then elaborate on the results of a user test. Finally, you’ll arrive at the end product: a login screen. It’s a solid narrative that makes the process and your work transparent, concrete and tangible. There is less scope for debate. Everything is validated (in the right way).

This applies not only to stakeholders but to the entire team and everyone involved. Everyone can relate user stories to their own area of expertise. It also forces us to consider the user’s perspective on the design — not just our own. In our view, this is where the power of user stories lies: they serve as a shared and understandable language for a multidisciplinary, user-centred team.