User personas are a useful software requirements analysis technique. The idea is that instead of referring to ‘the user’, when discussing requirements, you describe a user ‘persona’ to talk about instead. The difference is that the persona has an identity - a name, a portrait photo, a short bio and a description. This is especially helpful when there is more than one kind of user, each with a different persona who will use the software differently and have different goals.
Suppose you’re designing a warehouse management system. Initial analysis reveals that the software users mainly fall into two groups: warehouse staff and supply chain operations managers. There are variations within these groups, but most people within each group have a lot in common: they have similar backgrounds and skills, and want similar things from the software.
Instead of trying to consider every individual user, or ignoring the differences and just referring to ‘the users’ as if they were a single group, you can define two personas. ‘Walter Woodward the warehouse worker’, for example, need not to correspond to any particular person but will capture interesting limiting factors and opportunities, such as job description, age, computer skills and personal goals. None of the users are Walter, but if Walter would be happy with the software, then the real warehouse staff probably will be. ‘Oscar Madison the operations manager’, on the other hand, is someone else entirely.
The general approach to creating personas starts with getting to know what kinds of people will use the software that you are going to design, simplifying the group to a few stereotypical characters, and then ignoring the ones that are not most important. Each of these personas is not an average of the group, but rather a contrived hypothetical example that illustrates key characteristics. This means that each persona is fake, in the sense that it’s made-up - not a real person - and their photo is just some random person on the Internet.
The problem with producing fake personas, and the need to make everything up, is that this can be unnecessarily time-consuming and creatively challenging. A much more constructively lazy idea is to base each persona on a fictional character from a television series that team members are familiar with. This gives you a basic character that you can add specifics to, for details that might not be apparent in their television appearances, such as their computer skills or how they will use your software.
For example, on a recent software project in the Netherlands, to build an ISO compliance quality management application, my customer identified TV personas for each of the two key organisational roles:
- Birgitte Nyborg (Borgen) is a department manager, who gets things done without getting bogged down in bureaucracy, while staying faithful to her personal vision.
- Cristina Yang (Grey’s Anatomy) is a quality manager, who is highly intelligent but relentless in her pursuit of perfection.
We already knew a lot about these characters, which gave the development team a lot of shared context for the project, and common ground with the customer. In fact, Birgitte and Cristina were both more clearly delineated characters than we would have been able to make up, and convenient choices whose descriptions and photos were already available online.
A TV persona isn’t just a short-cut - an off-the-shelf persona. A TV persona has three key advantages, because they:
- are exaggerated stereotypes who lack the ambiguities inherent in real people.
- each have a Wikipedia page that describes their basic character, leaving less documentation to write
- look good in photos.
If you’re lucky, they’ve got a good back-story too.