Back to articles page

Personas: Focusing on getting the design right – Part 1
By: Fiona Meighan
Published - 2 April 2007

Target audience: Product Managers and User Experience practitioners who have not yet created their own personas before.

Imagine this...

You work for SecureTech Inc., a company that specialises in providing small business owners with a web camera security service called SecureCam. Although market research revealed the need for a service like SecureCam, the initial launch did not yield the sales and ongoing usage forecast. Anecdotal feedback from the sales reps seems to indicate that while they need a monitoring service, customers just don't like using SecureCam and find it difficult to use. Your Managing Director calls you in to her office and informs you that you and your team will be responsible for creating a new version of SecureCam called SecureCam II.

Your design team is responsible for ensuring SecureCam II does what customers need it to do, that it's easy to use and that customers like using it!!! Although this is a tall order, you accept the challenge, and start

Possible approaches

It might be tempting to get the design team and some graphic designers to immediately overhaul the service based on their understanding of usability principles, or better still, carry out some simple usability testing sessions on SecureCam. However, if you do this, you'll only be able to gain information about a subset of the questions you'll need to be able to answer to successfully launch a new version of SecureCam.

Usability testing will provide some answers. With usability testing or even just reviewing the service based on usability principles, you might identify problems with the usability of the existing functionality or observe that the user interface is not as attractive as it could be and that some basic design principles were not followed. Some of the usability issues you identify might even be showstoppers which you are able to rectify. But, you're unlikely to gain any significant insights as to why usage rates are so low or to check that the features offered by SecureCam match what users need and want. It may not be simply due to obvious usability or aesthetic reasons.

To give your redesign the best shot at success you need lots of information about your customers, what they need and want. You need to know what existing and potential new SecureCam users' goals and needs are and under what circumstances they use the service. You then need to ensure the service you redesign accommodates these goals and needs. You also need to make sure customers experience satisfaction and positive emotions when they use the service. Importantly, you want to understand which features are useful to customers and which ones are rarely or never used. Paring back to the necessary feature set ensures you don't over-burden customers with the need to navigate around unnecessary features and rather concentrate design efforts on delivering features that meet customer needs. This is where persona development comes in.

Personas – a vital tool for redesigning

A persona is a fictitious person, described in writing, that's based on real customer data. The data from a group of intended users with similar traits, goals and needs are consolidated into a single person, known as an archetype or persona. The persona tells a story about that represented group's goals, needs, skills, concerns and emotions towards the product or service being developed for them. It is then augmented with details about the "person" represented in the persona – the persona is given a name, an age, an occupation and a family, all of which are representative of the people the persona is based on. In the persona we also find out about the "person's" daily habits and their likes and dislikes. It is crucial that the key demographic details and data used to create the personas is real and typical of the people represented by the persona. Other items such as their name are fictitious, designed to "breathe life" into the persona; this helps the design team to treat the persona as a real person and defer to that person when they are making design decisions. Once everyone on the design team

Benefits of using personas:

  • Provides shared knowledge of who the product is being developed for
  • Informs design based on persona's needs and wants
  • Personas are precise. This helps:
    • Eliminate features that may be developed if "users" in general are considered
    • Reduce debates within teams – the persona's goals and needs direct design, not design team member's opinions
  • Keeps the team focused on the target persona – what would
starts thinking about whether Mary would really use a particular feature or if Ben is likely to be able to use the interface based on his computer knowledge, the power of persona's is more likely to be realised.

Gathering information to create a personas

The strength of a well written persona is in the precision of the details provided. Precision of details means development teams can make design decisions for a given persona and be confident that these decisions will translate to a desirable product for target customers. To achieve this precision, it is important to collect data from primary sources, for example, by interviewing or observing representative customers (potential or current) interacting with your service (or a competitor service) in the context it is usually used. If interviews or observations are not possible, it may be acceptable to use secondary data sources such as interviewing a Customer Service Representative who has extensive knowledge of representative end customers. Using secondary data alone is not recommended unless there is no alternative as small details about users' likes, dislikes, stumbling blocks or work-arounds can be missed with this method. Ideally primary and secondary data sources are supplemented with demographic and psychographic information that can be gained from marketing reports.

If you interview or observe representative customers, the number of people you need to interview depends on the amount of variation in the customers you're designing for. In the example of SecureCam, which is primarily used by small and medium enterprises with two to three stores, the market is relatively narrow, and eight to fifteen interviews is likely to be sufficient.

Whoever collects the primary data should be trained in structuring and carrying out interviews to ensure the right type of information is gathered and interview biases are not introduced. If you don't have someone on your team with the appropriate skills, we recommend that you employ someone who can do this for you – this small investment will mean you extract high quality information that will be useful to you, and eliminates the risk of finding out you've wasted your time when it comes to analysing the data collected. However, it's also very useful for members of your design team to observe the interviews as it's a great way of gaining more appreciation for the environment in which users interact with your product or service, for example, seeing first hand the problems users have with SecureCam will communicate the need for design changes more than reading a report ever will.

It's important to note, you must know who the representative end user's your business wishes to target are before you recruit interview participants and begin gathering data.

Collating the data to create personas

Once the data regarding your customers has been collected, there are a couple of techniques you can use to develop the personas: If you've employed someone to help with the data collection, this is where you, as a member of the design team can work with that person to analyse the data.

  1. Affinity diagramming. Affinity diagramming is a way of analysing all the information gathered from the notes taken when observing or interviewing customers and identifying themes common across customers. Notes are analysed to identify data points relevant to your customers, for example "Checks web cam every morning to check staff have opened store" or "Frustrated that SecureCam only shows one camera angle at a time.". Each data point is placed an individual slips of paper (e.g. Post-It Notes) along with a code to identify who the point came from. Data-points with similar messages but from different participants are grouped on a whiteboard, piece of butcher's paper or a wall. This helps identify common issues and themes. At the end of this exercise, personas based on clusters of information can be created.

    Sometimes one clear persona will emerge, and other times, more than one persona will be identified. In the latter case, it's important for the business to decide which persona they are primarily designing for. It's acceptable to design one product or service for both a primary and secondary persona but if this is done care must be taken to ensure that the needs and goals of the primary persona are met first. If a secondary persona's goals cannot be easily accommodated within the product or service being developed, consideration should be given to either creating a second interface for the secondary persona, or not targeting the secondary persona at all.

    More details about this method can be found in Gerry Gafney's article on affinity diagramming.

  2. Collapsing personas. An alternative approach to affinity diagramming is to create a persona for each person observed or interviewed using the same topic headings you will use for the final persona. Once this has been done, collapse personas that have significant overlap on elements that relate to the service to be developed to create a primary persona and possibly additional, secondary and tertiary personas. It's ok to collapse personas that differ on irrelevant factors, for example, a male and female persona may be collapsed and assigned either gender if gender is not a key factor in being able to use the service or achieving goals. You should not though, collapse personas if they differ in areas relevant to the design, for example, you shouldn't collapse a persona of a novice and expert computer user if you're developing a computer system where designing for a novice would impede the efficiency of the expert user, or designing for the expert user would make the system too difficult for the novice to use – rather you should keep them as separate personas.

Regardless of the method used, you may decide that some personas generated are "negative personas" or people you will deliberately not develop for. An example of a negative persona for SecureCam could be businesses who require outdoor, all-weather cameras; your company is not in the position to invest in new cameras that will meet this group of customer's needs just yet.

SecureCam data analysis

Returning to our the SecureCam example, imagine that you either teamed up with someone who's skilled in interviewing/observing or carried out the interviews yourself. In this scenario you and your team interviewed eight shop owners in Melbourne, Australia (where most of your customers reside). You also sell the service in other cities in Australia, but the demographics of customers in the other metropolitan areas you service is pretty similar to your Melbourne customer demographics. You also have some rural customers, but you decide to design for them at later date, so confine your interviewing to your urban customers.

Among other things, you find out the following information about your customers:

  • The customers interviewed all want to be able to see what's happening in their shops anytime, anywhere. Several have PDA's, and would love to be able to access SecureCam on their device.
  • Only a third of the SecureCam features are regularly used.
  • Those features not regularly used clutter the homepage and make it difficult to find what customers actually want to use.
  • The service terminology is too technical.
  • Half of customers interviewed would like SecureCam to digitally record and back-up their video feeds each day, rather than having to store this data themselves
  • All customers are delighted with the movement detector feature. It notifies them when their shop has been opened or if it's possible an intruder has entered the building.
  • Several customers are frustrated that they can't simultaneously view more than one shop or camera angle. As the economy is booming these customers are likely to open more storefronts soon.
  • The competitor product, View Now offers a much more simple user interface than SecureCam and allows up to six simultaneous views of either different shops or different cameras within the same shop. Three participants interviewed are considering switching to this service, the others didn't mention this product, but it's clearly a threat to business.

Checklist for creating personas

  • Find out about user goals through interviews and observing real end users
  • Ensure personas are created based on primary data you've collected
  • Ensure personas are specific
  • Include the key user goals only
  • Ensure each persona has a name, age, family and occupation.
  • The persona data should provide enough information for decisions to be made and feature creep to be avoided.
  • Design for a primary persona and possibly a secondary persona. The goal is to narrow down who your team is designing for

Armed with the above points along with much more information, you're ready to create your persona.

Part 2 of this article (coming soon) will explain the components of a persona in more detail and show you how to construct a persona.