Article
2 comments

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.

Article
3 comments

Oz IA 2009 – Day 1

I’m finally home after day 1 of Oz IA 2009, and absolutely knackered. What. A. Day. The presentation content was as diverse and interesting as the program suggested, but for me the greatest highlight was the meeting of minds of so many IAs.

First up was Matt Hodgson’s The Evolution of the Agile IA. Matt took us through a rollicking ride with where IA has come from, where it’s at now with the emergence of agile methodology, and where it’s going. One of the things I took from his messages about IA and agile was that in some ways we as IAs are already practicing some degree of agile without even knowing it; taking the big step into agile and leaving waterfall behind shouldn’t be too much of a pain.

I was up second, presenting on Guiding the way to living greener: how psychology helped IA for a new government website. I got some great feedback after it, including some requests for more information about how the ‘concierge’ model manifests itself in the various user interfaces used in the livinggreener.gov.au website. It was always going to be tricky to include the principles aspects of the presentation along with the applied aspects. I erred on the side of principles, given that the focus was on how motivational psychology can contribute to IA design. Maybe next time I would focus more on the UI aspects!

Cast herewith for your perusal (or go to my prezo at Slideshare):

Matt Balara was doing some awesome sketches of his thoughts coming out of each talk on the day, and here’s a pic of the page he sketched for my talk. It’s interesting that the key points that arose for him were:

  • Designing for people where they were at
  • Maslow’s hierarchy of needs
  • ‘The Concierge’ interaction model – answer question and offer even more
  • Personas are partners

Other highlights of the day:

  • Non-stop supply of fantastic real barista-served coffee – Single Origin, no less. I think I had 5? Stopped counting… Oz IA, you have spoiled me for any and all conferences in future.
  • Non-stop supply of fruit juice cocktails. Wanting to hold on to my masculinity, I didn’t indulge in this aspect of the conference much. But dayam, muddled mint and watermelon tastes good.
  • Stamford Interactive’s war stories of the pleasures and pains of being involved in a massive government intranet redesign project. Girls, I felt your pain.
  • Suze Ingram’s lightning-paced but highly entertaining review of prototyping tools. Expression Blend and Axure came up pretty well. I won a demo access pass to one of the online prototyping tools… no idea which one, now! But full points to Ian Stalvies, who won a fresh spanking new copy of Axure, for getting the trivia question right about the capital of Brazil (or somewhere like that).
  • Last and definitely not least: I have never seen so much twittering in all my freaking life! It was quite weird to see so many laptops open with people having one eye on the speaker and one eye on tweetdeck. Extra extra weird to see my own tweets retweeted on other people’s screens.

More fun in store tomorrow…