Could you deliver great software without user personas? Possibly. Especially if you are the user of your own system. Having easy access to users or customers is not the luxury of many of us however. In most cases, these people are remote and distributed across large areas or even time zones. Not knowing who the users are and what they need might lead to bad product decisions and even to the death of the product.
We usually have a picture in mind of who the users are, but let’s not forget that people who create the software see the world from a perspective of a quiet office, a desk with two or three desk monitors on it and a fast internet connection. How often is this the case for the users?
In our case – never. Our users are delivery drivers, who are always on the move, using a mobile device in areas either too crowded or too remote to get a decent data connection. And it’s definitely not quiet on the busy streets of London. This is why we have employed user personas.
Done right, personas are extremely powerful; done wrong, they are a waste of everybody’s time.
There are many great publications about how to create personas, to name just a couple: The User is Always Right by Steve Mulder or The Persona Lifecycle by John Pruitt and Tamara Adlin. The persona recipe in a nutshell? Base the profiles on quantitative and qualitative research and focus on their goals, not demographics. Imaginary personas (not based on any research) carry low value and might even be risky until validated. So, get out of the building (GOOB!) and talk to people (Talking to Humans by Giff Constable). Then check the numbers and come back to talking to people. And then create personas.
Assuming you already have personas, the next challenge is to introduce them to your teams and then keep the profiles alive. Many personas die quickly because the dev team didn’t believe in them or simply forgot to use them on daily basis.
How to avoid this? It’s worth including the whole dev team in the user research. If possible, every developer should spend some time with the users. Our starting point was working with delivery drivers for a day. That was an excellent experience and this is how empathy towards the users was born in the team. Refraining from introducing personas up to this point was a good move, because everyone could relate the profiles to the experience they had. Had I introduced Robert, Luke and Albert (the delivery driver personas) earlier, they wouldn’t have seemed real, therefore the risk of ignoring or rejecting them would be higher.
Once the team buys into personas, the next step is to make them visible. Distributing profiles via email might seem the most efficient (and environmentally friendly) solution, but that is not enough to keep personas alive. Developers get dozens of emails a day and information that is not continually on display is often forgotten. Posters around the office, especially on the walls around the team, or even better – on their physical agile board, where they meet daily, are a good idea. A thing to remember is that to get any attention, the profiles need to be visually engaging. Having pages of text on the display will be just a noise. Invest some time in making the information beautiful and easy to absorb and remember. An infographic is an excellent form of presenting this kind of information. Have a look here to learn more about infographics: http://www.informationisbeautiful.net/
We went a step further. Robert, Luke and Albert are not just smiley faces watching us from the posters. Visualised in their full work uniforms on the posters, their miniatures are also present on every user story on the physical agile board. This makes us think about who is really going to benefit from the dev work. It is also a good indicator of how many user related stories we deliver compare to technical stories, which don’t have any personas attached.
We didn’t stop just there. We do want personas to be realistic, so… we printed a persona named Alice to a life-size format cut-out. She is sitting in our office, wearing a real hi-vis vest, like she normally would at work. She also comes to meetings. Her favourites are workshops and sprint demos; however, she can’t always understand what the developers are talking about…
Robert, Luke, Albert and Alice have their own email addresses and physical ID cards (so they can print their paperwork for the day). They get a lot of attention from passers-by. That triggers conversations that wouldn’t happen otherwise. They are alive!
Personas are now present in everyday conversation and this has led to us changing our story format. We do not say “As a user I want… so that…” any more. Neither Robert or Luke or Albert would ever say anything this way. In my opinion, artificial phrases make the story feel less real, hence less important. So, we started quoting the exact words the users would use. For example:
Alice said: “Is there any way we can adjust the notes section on this report, so it is bigger and fills the screen. This would aid us when putting in detail as often the information is too large and is hidden out of sight unless you click in and scroll through.”
I first realised that the team had fully adopted personas when I heard them discussing a feature request: “This would never work for Luke” or “You think like a Robert!”. Another day someone declared that his shopping was delivered by “an Albert”. Straight after that someone else came to me with ‘“a solution for Albert’s problem”, which is now discussed in meetings mentioning Albert on the agenda!
It really pays off to keep thinking about the users all the time. First of all, developers have found a sense of purpose – it’s not “just a code”, they are helping real people out there. Work that would be tagged “boring” before now has true meaning and therefore is more interesting. The delivery drivers are now happier, because they feel that we listen to them (and don’t come up with the “useless IT ideas” any more). On top of all this, solving real problems as opposed to imaginary ones is a big win for the business.