Chapter 7

Analysing users with personas

There’s one reason why web apps are created: for people to use them. Without people, users, customers, or whatever you want to call them, the existence of a web app is meaningless. Although the occasional app is created exclusively for another system or computer to use, this chapter assumes that your app is designed primarily for humans.

The user should be the first and foremost consideration of your web app strategy. If you accurately gauge and cater to users’ needs and circumstances, you’ll be able to charge more for your app. It will benefit from increased customer satisfaction and word-of-mouth promotion, and require less support. You’ll also build more of the right features and fewer wrong ones, reducing your timescale and development cost, even if it’s simply the cost of your spare time.

The question is: who are your users?


Personas are an effective tool to help you design an app that’s appropriate for your target users.

A persona is a representative model of a core user type, in the form of a profile of a specific fictional person. Usually, the majority of your target users can be boiled down to a few key personas. Each of these will represent the needs of a larger group of users, allowing you to focus on discrete personalities rather than thousands of diverse individuals. Personas are easy to visualise, remember and discuss with your team.


An example persona for a travel notifications app

It’s normal to be sceptical about the utility of personas if you’ve never used the technique before: I certainly was the first time I created one. Persevere though, and you’ll likely grow to be an advocate. For me, the technique is as much about becoming naturally accustomed to thinking about users as it is the actual output. It’s the equivalent of stretching before sport.

In practice, if you’re building the app for yourself (if the idea originates from a problem you need to solve for yourself) then you become the main persona and you don’t necessarily need to follow this chapter and process through. This is especially true if you are the sole person developing the app, in which case the communication benefits of personas are redundant.

If you don’t have this luxury, if you don’t personify the entire potential market, or a team is developing the app, read on.

Personas require research

Personas are archetypes, not stereotypes. They are based on real data and research, not simplified assumptions and desirable attributes.

We started to get a feel for our customers in the previous chapter, where we researched and identified specific segments of the market, starting with the young, married female college graduate. Although these segments can form the basis of user research, it’s important to realise that market segments don’t necessarily map to personas.

Market analysis and segmentation are business tools that identify the validity and potential of an app. In contrast, personas are design tools that help create the right product for the market.

For example, market analysis for an online real estate app might identify that luxury penthouse customers generate the most revenue; this is the largest market segment based on monetary value. However, if we design the app around the penthouse customer segment, we might end up with an app that only lists luxury properties over £1 million in value. Design for a more carefully considered persona, perhaps a working graduate looking for a starter home in the suburbs, and you’ll almost certainly meet the needs of both the graduate and penthouse segments.

Market segments primarily identify patterns in demographics: age, location, sex, salary and so on. Personas, on the other hand, embody patterns of ethnography: goals and behaviours.

Elements of a persona

Let’s take a closer look at the information that goes into a persona, to help guide our research. I’ve seen some personas run to eighteen pages of detailed history and personal attributes, which somewhat defeats the purpose of creating something memorable and sharable. A better limit is just enough information to fit on a single sheet of A4 paper, which can be easily stuck to the wall or placed on your desk.


This can be a first name or a full name, but not something humorous or clichéd (Tom ‘The Noob’ McDonald). The person’s name is simply an identifier to remember, and shouldn’t convey any specific information or judgement about the person.

Job, age, family and photograph

Like the name, these can be included to help flesh out the persona into something more realistic and memorable, but not as specific data to base decisions on. The photograph can be any suitable image of a person you find on the web. Use the advanced search in Google Images or Flickr to limit your image search results to Creative Commons licensed photos that avoid copyright and privacy issues. Again, be careful not to include any details that might influence or bias judgement about the person: strange piercings, unusual clothing and so on.


These are problems or ambitions that the user will gain satisfaction from solving or achieving – the things that they want to do. Cooper, the agency founded by persona pioneer Alan Cooper1, recognises three types of goal: life goals, experience goals and end goals.

Life goals are aspirational (to retire to the south of France, for example) and are not relevant to most web app design decisions. Unless your app is helping people to achieve their life goals, perhaps through appropriate investment, you can safely ignore these.

Experience goals are a little more important: they describe what the user wants to feel when using an app. This might include feelings of trust and confidence for a financial app, or excitement for an online gambling app.

End goals are the most important to capture. These describe goals that the user expects to accomplish through using the app, either directly or indirectly. For example, a manager might want to reduce the time spent creating tedious daily sales reports, or a chef might need to make the right decision about where to source ingredients.

Remember that all goals should be related to your app – if it’s not relevant, don’t include it. Keep it short and simple.


Whereas goals are specific actions or tasks, motivations are the reasons behind them: goals are what someone wants to do, and motivations are why. They are not always necessary in your personas, but can often clarify goals and inform better design decisions.

For example, the chef in our previous example might want to source the right ingredients because they feel guilty about using meat that has not been raised ethically and don’t want to feel the nausea of culpability. Alternatively, they might be motivated by the risk of losing business if a supplier has poor hygiene standards. Both are valid motivations that will influence the design of an app.

Frustrations and attitudes

Like motivations, you should include these if they help to better articulate goals. Frustrations might concern existing attempts to solve a problem: that they’re too difficult to use, are slow to respond or give inconsistent results. Attitudes are more general: the user might be scared of new technology or perhaps they are enthusiastic early adopters.

Work day, skills and environment

These need to be appropriate for whatever time period and context are relevant to your app. If you’re building an app that reminds people when their houseplants need to be watered, don’t detail their daily tasks as you would for an expert database administrator in an open-plan office. Instead, describe the inside of their home and their evening routine.

Tagline or summary quote

A summary phrase or representative quote is especially useful if you need to quickly distinguish between multiple personas. A tagline might be the stay-at-home dad or the enthusiastic amateur cook. Alternatively, a quote could read: I get to watch sports all day with my kids – perfect! or If only I enjoyed exercise as much as I enjoy cooking.

Keeping the behavioural attributes that need capturing in mind (attitudes, motivations and goals), it’s time to move on to the research.

Persona research on zero budget

Good user research can be expensive. It’s common for persona development to include the identification of relevant users, interview design, interviewee recruitment, conducting the interviews and a lengthy data analysis phase, all over a number of weeks. Costs can easily run into tens of thousands of dollars.

What’s your budget for persona research? Zero? That’s fine, too. We can get many of the formal research benefits with a little bit of informal online investigating.

All data sources have pros and cons, depending on how the data is collected. Good research reduces bias by combining data from multiple sources. What data sources are available for persona research?

Guided Observational
Direct User interviews
Surrogate interviews
Stakeholder interviews
Workplace/Contextual observation
Remote Surveys
Email/IM interviews
Social media conversations
Search analytics
Website analytics
Support/Call centre logs
Membership profiles
Industry research
Social media behaviour

Guided research

Data is collected through specific questions. This provides greater insight into the reasons behind behaviours, but can also inadvertently influence answers through poorly worded questions.

Observational research

Monitoring the independent behaviour of participants may give a better idea of what people actually do, rather than what they say or suppose they do. On the downside, it’s more difficult to unearth the motivations behind behaviours while only observing.

Direct research

Face-to-face research is crucial for detecting non-verbal2 communication: sighs, slouches and vocal inflections that can highlight hidden attitudes and frustrations. Unfortunately, it can be expensive and time-consuming.

Remote research

Online research can be fast, cheap and incorporate responses from a much larger audience than formal direct studies. Drawbacks include a potentially less engaged and less responsive user base, no physical reaction data, and difficulty in directly following up responses for clarification or justification.

Although some of these research methods aren’t practical or applicable for a small team developing a new app, many are.


With no budget, your opportunity to conduct face-to-face interviews will depend on whether you have friends, colleagues or family who are part of your target market and are willing to participate.

Alternatively, use your social media connections (Twitter, Facebook, LinkedIn and so on) to identify relevant people and ask if you can arrange a brief video, IM or email interview with them. Explain that responses will remain confidential and that there are not many questions. If necessary, use early access to your app or even the promise of a free account as a sweetener. You’ll eventually need beta testers anyway.

For informal interviews such as these, where the interviewee is participating as a favour, you should carefully limit the number of questions. With little time and obligation it is better that they feel able to give in-depth replies to a few open questions rather than being rushed into succinct responses to many questions. Motivations and behaviours will only surface in longer responses.

What questions should you ask? Let’s say we’re designing a short email interview for an app that helps amateur cooks to better organise their recipes and ingredients. The following four open questions would identify many of the goals, motivations and behavioural patterns of the interviewee:

If you are able to find multiple interviewees who are willing to participate, don’t hastily send out your lovingly crafted interview to all participants immediately. Conduct the interview with one person initially and refine your questions based on gaps in the response.

Contextual observation

With this method, you study behavioural patterns by watching the user perform the task that’s relevant to your app in the correct context and environment: creating a sales report at their desk, cooking a meal at home, and so on. Unless a particularly tolerant friend is willing to set up a webcam for you to remotely monitor them, this really needs to be done in person. Again, friends and colleagues are your best bet.

You need the environment to be as natural as possible: don’t remove or minimise distractions and interruptions, and try to save questions (the all important ‘why did you do that?’) for when the task is complete.


It’s easy to create a free online survey that mimics the probing interview questions using a tool like Survey Monkey3 or even Google Docs4. Apart from your interview questions, be sure to capture some general information, such as job title, age and location, so that if your survey gets into the hands of people who aren’t your target users you can easily filter out their responses.

Once you’ve created your survey, get it out to the right people by politely asking for responses on Twitter, in relevant Facebook and LinkedIn groups, and on relevant discussion forums and niche community sites. Be sure to include some brief background to your project and how you hope it will benefit people in their community.

Social media conversations

This is the equivalent of a particularly informal survey or interview. Ask interview-style open questions through social media: Twitter, Facebook groups, LinkedIn groups, discussion forums, mailing lists and so on. This is less intimidating for potential participants, and the ensuing discussions may reveal key patterns in behaviour and attitude. As usual, take care to avoid spamming and to filter out responses from non-relevant users.

Social media behaviour

People are almost certainly already talking about topics related to your app. Much can be revealed about attitudes and end goals by studying active discussions and even analysing the tags that people use on relevant blog posts and sites like Delicious5.


Twitter stream containing relevant keywords

You need to follow up directly with interesting users to extract the most value from this research. This is particularly easy on Twitter: just ask them a question. Try to convince a few people to complete your simple, quick survey or interview: personas are better developed from full responses by individuals rather than single data points from a crowd.

Search analytics

The Google Keyword Tool6 is not going to give you the deepest insight into individual attitudes, but when corroborated with other sources the popularity of relevant searches gives some indication of end goals and motivations. For example, popular searches for recipe demonstrate that people don’t just search for recipes based on ingredients (pasta, shrimp, steak) and end result (soup, salad, curry), but also on convenience (easy, free), time of day (breakfast, dinner) and lifestyle choice (vegetarian, healthy).


Results from the Google Keyword Tool reveal different kinds of searching around a general term

Once you’ve conducted your research, how do you convert the data into appropriate personas?

Creating personas

To create personas you need to identify patterns of behaviour in the research data. Read through your research and extract frequently mentioned variables that govern or describe the users’ behaviour and goals, such as available time, cost, expectations and so on, avoiding demographic values like age, location and skill level. For each variable draw a horizontal line on a piece of paper, to represent the range of values for that behaviour. For example, time might range from restricted at one end to relaxed at the other. Draw each behaviour line below the previous one.

Next, re-read the interview and survey data for each user and map their behaviour onto the lines. This doesn’t need to be particularly accurate; you may want to divide the lines into five or even three equally sized sections.


Behavioural mapping for personas

What we absolutely don’t want to do next is describe the ‘average user’, who doesn’t exist. Let’s say that the variable for time in our example ranges from 1 (extremely time conscious and restricted) to 10 (cooking behaviour is relaxed, time doesn’t really matter). If our data shows two users at 1 (allotted time very much influences behaviour) and four users at 10 (time doesn’t come into it, they’ll take as long as it takes), calculating the mean would give us 7. In other words, this average reading would incorrectly tell us that people are neither particularly relaxed nor particularly time conscious when cooking. Design decisions based on this behaviour would not satisfy any of the six users, as none of them matches it.

Instead, we need to find commonalities: groups of users who share the same behavioural attributes. Draw a vertical line for each user, connecting their dots; this often makes it easier to identify similarities.


Finding commonalities among a group of users

The clusters of lines that represent people who share the same kind of behaviour become the basis for your personas. Your research may highlight a number of distinct clusters, or perhaps just one primary persona.

Expand each cluster of behavioural data into a full persona by writing it as a narrative: use sentences and paragraphs rather than bullet points. Remember to include a few personal elements to help bring them to life. Constantly refer back to your original research during the fleshing out phase to ensure that the description uses real data.


Stephen is a 33-year-old town planner in Manchester, where he lives with his fiancée. A couple of nights a week, he will call into his local high-end delicatessen on his walk home from work to buy whatever great looking food takes his fancy.

For Stephen, food is one of life’s pleasures: he enjoys cooking a great meal and has been doing it for long enough that he has quite a few dishes that he knows really well, so he doesn’t often consult instructions. Variety is the spice of life for him, though, so he’ll play around with introducing a new ingredient to his repertoire, especially if a friend has suggested an interesting idea.

Stephen and his fiancée frequently hold dinner parties where he likes to show off his culinary skills. On these occasions he’ll plan ahead and try new dishes to wow his friends.

He’ll get interesting new recipe ideas from the internet, and takes his laptop into the kitchen to follow the instructions the first time he makes a new dish. Cooking is a sensual, relaxing hobby for Stephen so the computer needs to play a minimal role in the process: he wants to use it for inspiration and to learn about new techniques and ingredients, but it shouldn’t disturb the physicality and spontaneity of cooking.


The more you know about your users, the better and faster your can meet their needs.

Web App Success book coverAlso available to buy in a beautiful limited edition paperback and eBook.

This work is licensed under a Creative Commons Attribution 4.0 International License.