During the development of a website, businesses find different ways to focus on the user. Some choose to develop personas to give faces to target groups. Others make use of user stories that describe the user, his needs and what drives him. We especially feel the power of user stories.
Personas — giving the user a face
You create a website for people, not for numbers and figures. Makes sense, right? However, each target group differs in their needs, their desires and what drives them. It can be difficult to keep in mind. Personas can give you something to go on as they are the personification of your users.
Based on a wide range of user data — sales figures, market research, etc. — personas can be created. The different types of users (target groups) are generalized and given a face (personal) characteristics, a nice profile picture, maybe a Facebook page. Posters are printed and put 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. Additionally, 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 just 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 of 2 – 3 weeks. In order to guarantee the user’s perspective in such a short time, user stories are written. The user stories are prioritized (by user impact and business impact) and estimated by the team. The product owner and team then assign stories to sprints.
While 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. In addition, user stories are brief, uncomplicated and tell you exactly what the user(s) purpose is. As a whole it becomes concrete and applicable, like so:
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 think of possible solutions. Keep in mind, however, that it is important to formulate a user story properly and not like this:
As an existing customer, I want to log in so I can change my personal details.
Unfortunately, we often encounter user stories written like this, a user story that contains a (possible) solution. Or user stories that are no more than barely disguised requirements. But a proper user story focuses on the need and motivation of the user only. A user does not visit a website to log in. An innate desire drives the user, in this case to the login screen. You can prevent mentioning solutions in user stories by asking ‘why’ until you arrive at the essence.
Reading the first user story, you could 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 horizon. You could arrive at the conclusion that logging in is not necessary. But you would not come to this conclusion if you 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 assist when sharing developments and ideas.
Let’s look at stakeholders, for example. At a demo you can show a login screen with the words “This is a login screen, and this is where the customer changes his details”. All sorts of sensible and nonsensical discussions might ensue. But is that you want? Or will you let users and user stories lead your presentation? You can explain which user stories are formulated, how business goals are part of them, which user stories have been given priority — 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 story that makes the process and your work transparent, concrete and tangible. There is less room for discussion. Everything is validated (the right way).
This does not only apply to stakeholders but to the entire team and everyone involved. Everyone can translate user stories to their own expertise. Also, it forces us to consider the user’s perspective on the design — not just our own. In our opinion, herein lies the power of user stories: they function as the common and understandable language for a multidisciplinary, user-centered team.