Personas: Help For Usability Projects

What is a persona?

A persona is a way to formally define and humanise a target user group’s fictional representative, in order to support design activity. They are used within usability projects, we are always talking about the importance of designing for users and keeping their interests paramount.

Personas are a valuable usability technique because they force a design project to articulate exactly who a representative user would be and to appreciate their perspective and interests.

‍

Writing a design persona to support usability

The fundamental job of a persona is to communicate the user’s perspective on a design issue. To that end, you should include any information which you think will help the design team to understand the user’s situation, likely priorities and thought processes. Most personas on a usability project will, for instance, usually include the following kinds of information on a user:

Demographic information

• Age
• Gender
• Education
• Employment

Mental model (regarding the product, service and/or domain)

• Expectations
• Experience

Context of use (regarding the product, service and/or domain)

• Ambient factors (for example: light levels, screen glare and noise)
• Location at the time of use/access
• >Device (for example: desktop, laptop, tablet, phone)
• Time pressure – is there an urgency associated with the situation?

Goals (regarding the product, service and/or domain)

• What the user wants to achieve, and why
• How motivated is the user?
• Triggers – what would increase the user’s motivation to complete their task?

‍

The role of a persona within a usability project is to effectively communicate a user group’s perspective on a particular design issue. The above-provided list is merely intended as a starting point for you to begin to consider and identify which user characteristics are most relevant to your usability project.

‍

Usability persona goals

Here’s a good tip to bear in mind when you’re considering a user’s goals within the context of a usability project – try to identify the main goals along each of these parameters:

• Frequency
  Which goals will the product/service have to support most often? Which goals will each particular user want to achieve most often?

• Importance
  What goals are most important to each user group? Which goals are most important for the organisation (overall and for a each user group)?

• Criticality
  Which goals – if they can not be achieved – will result in the most negative impact on each user group? Ask the same question from the organisation’s perspective (overall and for a each user group).

Humanising a persona to help usability thinking

Usability professionals are trained to empathise with users, but we still occasionally catch ourselves superimposing our own attitudes and perspectives onto user groups. If a usability consultant can fall into this trap, then we can hardly be surprised when non-usability specialists voice opinions which basically state “anyone who doesn’t think like me is simply wrong”.

Needless to say, this goes against the whole usability philosophy of designing for users’ perceptions and priorities. It is, however, a very human trait – and one which personas have been specifically developed to help combat.

Usability personas stand the best chance of doing this when they make it as easy as possible for someone to relate to a user group’s representative. The ideal situation is where someone looks at the persona, correctly understands the user’s perspective and says“I know someone like that”.

In order to achieve this, it can be helpful to provide additional details about a representative user which help to give the persona more depth and detail than mere usability factors could achieve. Here are some ideas for how to humanise a design persona:

• Name/Nickname & photo
  Try to not use a name or photo of anyone on (or closely associated with) the design team, as this can cause bias and confusion.

• Husband/Wife/Partner/Children
  Name, age, education, occupation.

• Personal choices
  Mobile phone, newspaper, holiday location, car.

• Leisure pursuits
  Sports, TV shows, websites.

‍

There are, of course, certain usability risks associated with trying to humanise a persona. The main usability risk is that the ancillary detail can encourage the design team to jump to conclusions based on their own personal experiences and/or cultural bias.

‍

There’s no guaranteed way of avoiding this, apart from carefully considering which types of detail will serve to clarify and illustrate the persona, whilst remaining sensitive to any details that might lead to problems. Another tactic is for a usability professional to show a draft persona to some members of the design team and ask for their understanding of the (fictional) user’s perspective and priorities.

‍

This usability testing of the persona can help to identify aspects which work and those which are causing problems (particularly if the usability professional asks follow-up questions such as “What about Ben’s (the persona’s fictional name) profile makes you think that?”). With an iterative approach, this usability testing will allow you to develop a persona which you are confident gives the design team the best possible understanding of the representative user’s perspective.

‍

Developing a persona for a usability project

A great way to develop personas is to get input from your Marketing department, who will usually have lots of research on your organisation’s different target markets. Another good source can also be Customer Service teams, as they tend to be in daily contact with customers and should be able to give you a good idea of their priorities and perspectives.

Other sources of input into persona development are the traditional usability practices of focus groups and 1-to-1 interviews. These can be especially useful in validating and further exploring any information you have been able to gain from within the organisation.

‍

Presenting the persona in usability training

To help your organisation get the most value out of a persona, it’s a really good idea for a usability professional to formally present it to the design team. This not only guarantees that everyone has at least been exposed to the persona (because, as we all know, the first rule of documentation is that people do not read documentation!) but it also gives the usability expert a chance to explain and sell the concept.

As part of this presentation, we would recommend that the usability expert lead a series of exercises to illustrate different aspects of the persona’s priorities and perspectives. Examples of such a usability exercises might be: “What would Ben think of this?”, “Where would Ben probably click next, and why?” and “What would Ben expect to happen next?”.

‍

Project-specific usability personas

It is important to realise that personas are not entirely recyclable, even within the same organisation. For example: a software company that has recently developed personas for a word processing application may be tempted to re-use its personas for a new spreadsheet application. The potential flaw in this reasoning (even if the two products do have the same target user groups) is that the users are likely to approach a spreadsheet application with different mental models, contexts of use and goals.

Therefore, we would always recommend that a usability expert carefully reconsider a persona’s rationale before it is reused. This would also apply if the same persona used during a product/service original development was going to be used during a redesign or update. Nothing stands still in life – even if the demographics of your target market have not changed, their mental models, contexts of use and goals may well have altered.