User Centred Design with Personas – Bringing People into the Picture

Alan Cooper’s publication The Inmates Are Running the Asylum, published in 1998 introduced personas a design tool for interactive applications. Personas gained popularity across the software industry due to their effectiveness in elicitation of user requirements and needs for a system.

Personas are fictional characters that represent a segment of the target market for an application. These have names, a backstory, a set of goals relevant to the system, and a set of needs that the system should be able to address.

Although personas are fictional, the characters are usually developed through interviewing or observation of the target market. Generation of these artefacts is an essential part of user-centred design and enables product manager and developers to be familiar with the needs of users while eliciting requirements and developing the application.

Personas do seem to be a counter-intuitive or counter-logical part of design though. Being rooted in the user community, there may be a large number of features or requests that arise from users which may add little value to the application or may even be contrary to the application model. Ending up with a set of personas that are a sum of all desired features may be a sign of the target market not being familiar with the scope or goals of the product. Although it may seem like the users are “back-seat drivers” generating irrelevant feature requests, it may still be useful to evaluate the gap between the current project/brief and target markets’ expectations to identify where additional value can be added to an application.

Generating a persona

Personas can be tricky to write – most of the time these can either be too bloated with irrelevant details about the user, or missing important needs about a specific user group.

Naturally, it can be difficult to capture all the relevant information about the target market in personas in the first attempt. However, as with all agile methods, these personas can be maintained, added to and adjusted throughout the product lifecycle as new needs arise.

Typically persona-like docuemnts generated suffered from four major problems:

  1. Characters were not believable or had been designed by comittee, their relationship to the data was not clear
  2. The characters were not communicated well. Typically they were recorded in a resume-like document blown up to be a poster.
  3. There was no understanding about how the characters were used. There was nothing that spoke to all disciplines or all stages of the development cycle
  4. The project was a grass-roots effort with no support from the business. Typically there was no budget to support the development of persons.

Microsoft Research published a strategy for persona generation as an extension of what Cooper discussed in his Inmates book.

  • Personas originate from market segmentation studies. The highest priority segments are fleshed out from user-studies, focus groups, interviews and market research. Metrics around market size, revenue and competitive placement determine which market segments can be enriched using persons.
  • Using existing related market research (from internal or external sources) helps augment the personas with information backed with qualitative or quantitive data to support design choices.
  • International market information and accessibility information is included within each persona rather than creating full-on disabled Personas. Microsoft only typically create one “anti-persona” – a persona for a user outside of the intended application market.
  • Persona generation is a multi-disciplinary team effort. A persona creation team would generally include product planners, interaction designers, usability engineers, market researchers and technical writers. The team would have 2 or more dedicated people on maintaining persona profiles from market research. Where lighter efforts are made solely on existing user research, the personas that are generated are considerably less detailed
  • Common facts extracted from research are grouped together and form priority information for the generation of the personas. The groups of findings are used in writing narratives that tell the story of the data.
  • In the user stories, qualitative data and observed anecdotes are used. One of the goals in Microsoft Research personas are to back every statement in the persona backed from user observation or collected data.
  • Microsoft use a central document for each persona as a storehouse for key information about the Persona (data, attributes, photos, reference materials). These documents do not contain all of the feature scenarios. They typically contain the goals, features and typical activities that motivate justify the scenarios that appear on the feature spec.
  • Links between persona characteristics and supporting data are made explicit in the persona documents.

A persona document typically contains:

 A day in the life  Following the user throughout a typical day
Work activities  A look at the users job description and their role at work
 Home and leisure activities  Information about what the user does outside of work
 Goals, fears and aspiration  Using the above information to understand the concerns about the user in his/her life, career and business.
 Computer skills, knowledge and abilities Learning about the users’s computer experience
 Market size and influence Understanding the impact that users similar to this user have on the business
Demographic attributes  Key demographic information about the user, family and friends
 Technology attributes Reviewing the user’s past, present and future perspectives on technology
 Quotes Hear what the user has to say
References Documentation to support this persona
  • Once a basic persona is written, Microsoft add photos of models in some of the described situations to the personas to illustrate and communicate the persona. Stock photos are not used as these typically only contain one or two photos typically in a context which is not described in the persona.
  • Cooper describes personas as a discussion tool “would Dave use this feature?”. This is a valuable tool however does not really provide a quantitative description on how valuable a feature is. Microsoft use a spreadsheet that documents how the subjective importance of  features/requirements on personas are mapped into the requirements document.
  • Once personas are generated, their use is not only limited to the generation of feature/requirements. The product and feature specifications utilize the personas, along with vision documents, story boards, demos, test cases, QA testing and documentation writing.
  • The usage and importance/relevance of personas is monitored in the product lifecycle too. To prevent a persona which reflects an insignificant/irrelevant segment of the target market from being overused, their use is typically tracked within a spreadsheet.

This approach from Microsoft appears thorough in both recording the information about the user and how the captured information is being used throughout the application lifecycle to support design decisions for the product.

Roman Pilcher discusses a slimmed-down persona template that is used in his requirements elicitation process. Typically he captures:

  • Name
  • Looks
  • Characteristics and behaviours that are relevant to the product
  • Demographics, job, lifestyle, spare time activities, common tasks
  • Why the persona would by or use the product
  • What problems should the product solve for the user
  • What benefits the persona wants to achieve

I believe that these attributes about the users’s goals could be used to augment personas generated by Microsoft’s method. Once these personas have been generated, the goals can used to support a “big picture” of the product which can the be used to create scenarios, storyboards, workflows, epics, and high level design mock-ups.


Previous Post:
Next post: