Making personas more useful with persona profile tables

The user experience camp seems a bit divided about using personas as part of user experience design. There are a couple of charges laid at personas’ feet that I think can be lifted by using profile tables together with the personas themselves.

When I talk about personas, I mean the archetypal constructs of characteristics, drivers, behaviours and goals that are designed to represent the main audiences at which a digital product is aimed. Personas were made popular by Alan Cooper, and given gravitas and discipline by industry minds such as Andrew Hinton and Jared Spool.

Pros and cons of personas

It’s true that personas are very useful for informing and validating user experience design. Here are my favourite advantages and benefits:

  • They’re a convenient combination of sensible scenarios and user requirements that are more understandable and accessible to people not familiar with (or prepared to read) copious volumes of technical documentation
  • Everyone – designers, project managers, project stakeholders and developers alike – can relate to personas (and if they don’t then the personas probably aren’t authentic enough), so they can act as a great unifier in project vision
  • They keep everyone honest and the design true to its purpose; by referring constantly to the personas, design and development is kept focused on what’s important for the target audiences and their tasks and situations
  • They are great argument enders; personas can often become the true arbitrator of discussions and debates about whether this feature should be included or not, or whether that phrase is the right tone or not

But personas are not without their criticisms. Some of the charges laid at their feet include:

  • They’re too abstract to be of useJason Fried describes them as artificial, abstract and fictitious, so they can’t provide authentic responses to designs, and be biased and unpredictable, just like real people
  • They’re just another part of the paperwork – many people across the project and client-side get documentation fatigue, and are not likely to absorb and learn from the personas
  • They can be seen as a bit of a luxury at best and time-waster at worst, where many people would rather just get on with designing and building

Persona profile tables: measuring significance of requirements against personas

Where personas can be a shorthand version of user requirements, profile tables provide a shorthand version of how significant the business- and functional requirements are to those personas. Profile tables have a list of features, functions and other contextually relevant aspects in the first column, then one column per persona displaying a measure of significance to each persona for each feature/function.

The‘significance’ bit will depend on your project, and profile charts are most effective when you are specific about the nature of this significance; it’s subtle but important. For example, it could be:

  • How likely it is that each persona would use that feature
  • How important that feature is to each persona
  • How often that persona would use that feature

The ‘measure’ bit shouldn’t be binary – like a tick or cross – because personas (just like us) are rarely black and white about these things. Use other measures that include ideally five points along a spectrum, such as:

  • Harvey ball notation – an array of circular ideograms, filled in by portions to indicate amount:
  • Set of Harvey Ball notation images with their corresponding amounts
    Harvey ball notation - none

    None

    Harvey ball notation - 25%

    25%

    Harvey ball notation - 50%

    50%

    Harvey ball notation - 75%

    75%

    Harvey ball notation - 100%

    100%

  • Colour – shades of one area of the spectrum work well, such as white (none) to yellow (mid) to green (high). Avoid more than two colours, unless you want to include a negative aspect as well, such as red (persona would definitely not use that function) to yellow (ambivalent) to green (would definitely use)

I always use Harvey ball notation, because it’s the clearest to the most number of people, and there are never any colour blindness/colour printing variation/screen display issues.

I’ve used persona profile tables in several projects now, and they were really useful for guiding interface design decisions, and finding those sweet spots with works best for both business and user and for the scenarios where the website is being used.

How to draw up a persona profile table

This assumes that you have your personas are ready to go. Profile tables are best done in a workshop situation, either within your team or with client stakeholders. This not only keeps things from being ‘designed by designers’, but gets everyone embracing and using the personas.

1. List the features and functions

Start by making a list of all the features and functions of the product you are designing. As you make this list, you’ll probably find that some functions will need to be broken down into more specific actions, or ways of using that feature. Explore this, and list it all; you can always rationalise the list later depending on the context of your project.

Example: ‘Search for houses to buy’ would break down into‘search by location’,‘search by price range’, ‘search by house feature’ and so on. I bet there would be differences in each of these item’s significance for each persona.

The examples below are taken from work done on a website about environmental information and action.

Features/functions
Background information about the environment
Background information about sustainability
How to save money
Specific actions to live more sustainably
Ways to encourage others

2. Add the behaviours

Think about the ways that personas would approach and use these features and functions. This may uncover other elements that will have differences in significance for personas, like ‘comfortable with large amounts of detail’, ‘comfortable with entering personal information’.

Features/functions
Background information about the environment
Background information about sustainability
How to save money
Specific actions to live more sustainably
Ways to encourage others
Behaviours
Comfortable with technical detail
Comfortable with content detail
Sharing information
Commenting on information
Watching online videos

3. Fold in the personas

Add each persona you have as a column next to the first column of features, functions and behaviours. If there is a certain order that you are already using when referring to your personas, use the same order.

Features/functions
Background information about the environment
Background information about sustainability
How to save money
Specific actions to live more sustainably
Ways to encourage others
Behaviours
Comfortable with technical detail
Comfortable with content detail
Sharing information
Commenting on information
Watching online videos

4. Add the ratings and heat gently

Now comes the fun part. You, your team, and your client stakeholders discuss each appropriate rating in each column for each feature/function/behaviour, according to individuals’ knowledge of personas (and therefore of requirements). This groupthink should minimise subjectivity and invite scrutiny.

Features/functions
Background information about the environment
Background information about sustainability
How to save money
Specific actions to live more sustainably
Ways to encourage others
Behaviours
Comfortable with technical detail
Comfortable with content detail
Sharing information
Commenting on information
Watching online videos

5. Observe and exploit any trends and patterns

As you complete the ratings, you may see some trends and patterns where some personas rate very highly in some areas, low in others, or cluster together in some ways. These patterns may reveal lessons that you can take to your design.

Focus on clarity

As with most things, keep the persona profile tables simple, clear and concise. Once you get into doing profile tables, it’s easy to draw up loads and loads of them, but the intention should always be to summarise what already exists in other documentation, to give others an easy-to-reference asset for the design process, and the decisions that crop up all the time.

So if you decide to include profile tables in your set of design tools, set yourself a goal to keep them to one whiteboard in the case of a workshop, and to one page (or at least one page per functional ‘area’) in a report, so that whoever else you’re working with only needs to refer to one page at a time.

, , 2 Comments
Comments To This Entry
  1. I was looking for this kind of information and enjoyed reading this one. Keep posting. Thanks for sharing.

    surf watches on 27 August, 2011 Reply

Leave a comment