"The user" is a nebulous term. Everyone on the team has a different picture in their head when they say those words. Thumbnail personas use site visit data to focus the whole team on the same key individuals.
If you asked everyone on the team to think of the color blue, and then showed each of them a choice of Pantone color swatches, how many of them do you think would choose the same swatch?
It's the same thing when we ask the team to think about "the user." Each of them has a different picture of who the user is. If you're lucky, it's the last customer they saw. If you're unlucky, it's more likely to be the generic "my Mom."
When you build software, that user description gets stretched in many directions. Sometimes the user is experienced, sometimes they aren't. Sometimes they are older, sometimes they are just out of college.
The result is a product that aims at different users at different points in the interaction. Real users aren't made of elastic. They find it hard to cope with our schizophrenic interfaces.
Making "the user" concrete
Thumbnail personas let the whole team get on the same page. Even if the persona you create is slightly off from reality, users will much prefer a consistent interface over an inconsistent one.
The process is quite simple. It is best done as a team, because then every team member feels like they have contributed and so they can buy in to the final personas.
- Consider the users you observed during site visits. What attributes did they share? What qualities differentiated some from others? You might have these attributes listed in your experience map, or you can get all team members who attended the visits to individually write down the attributes on sticky notes.
- Group the attributes by bringing all the sticky notes together.
- Once you have some sensible clusters, name each group using a role described by its attributes.
- Taking each role in turn, turn the attribute descriptions into a believable person(a). On a large size index card:
- Give the persona a name and age.
- It often helps to give them a two to five word tag-line (Abby the AOL Mom, Nicolas the Knowledge Worker, Ichiro the IT Pro).
- Say what they do in life. Are they a student, a business person, retired?
- What is their level of comfort with technology? How experienced are they in the topics your product will address?
- Justify each piece of information you add by showing how it is important to the design decisions you will have to make later on.
- For instance, there may not be any point describing the car that the persona drives if you are building a document management system, but there could be every point if you are creating a forum for Volkswagen enthusiasts.
- Add design implications for each of the pieces of information you've provided.
- For instance, saying that a persona is detail-oriented suggests that they will need to see certain characteristics in the product in order to be happy using it. What are those features?
- Provide the context for how this persona would interact with your product
- Is it through choice or because it's part of their work?
- Do they interact frequently or just occasionally? Alone or as part of a team?
- Is their interaction on a mobile device or PC?
- If you can, choose just one primary persona and two to three secondary personas.
- Killing personas is difficult even at this early stage, but you'll thank yourselves later. It's much easier to keep the needs of three to four well differentiated users straight in your head than to try and please a whole herd of ill-defined individuals. The results of this early streamlining will show up in a more focused product.
Use your personas every time you describe your users. The persona names become shorthand on the team for a shared knowledge about a set of user attributes. When you write scenarios, write them for a persona. When you create design sketches and prototypes, build them for a persona. When you write story cards or requirements documents, write them with the persona in mind. Building for a small set of defined users will create a product that resonates with an entire customer base.
Many thanks to Jeff Patton for helping me embrace thumbnail personas.
More robust personas for longer-term use
You may find that thumbnail personas are sufficient for your needs for a shorter development job, but if you're likely to be building software for the same users over a period of time, having a set of data-based personas really helps to keep the team focused on who they are building for. This in turn keeps the user interface focused and makes your users happy.
John Pruitt and Tamara Adlin describe how to create longer-term assumption and data-based personas in their book "The Persona Lifecycle" (and the smaller, more affordable "Essential Persona Lifecycle").
Persona success stories
Your team may not be sold on the idea of personas. Here are some large companies who found them useful.
Universal Orlando sketched out personas, each with a different set of motivators and travel needs. Online ticket purchases, a key metric for the resort, are up almost 80 percent year to date. "It's beyond demographic, beyond male/female, young/old. It gets into the psychology of how humans make decisions and how they get comfortable making decisions.”
Home Depot uncovered two very different customers who might have identical demographic profiles: the do-it-yourselfer who wants to pick out all the cabinets and appliances and the customer who wants a kitchen designer to do it all.
Staples’ online revenue went from $3 billion to $4.9 billion within two years after a major site redesign that included the development of seven personas and a decision to design primarily for the two most important ones.
Detoxologie.com used personas to boost conversion by 400%, and get a 2 to 1 return on a floundering Pay-Per-Click campaign. “It’s like having your own customers as a personal trainer. Personas can tell what to improve and what to avoid, but it’s up to you to take the first step.”