Personas and how to increase the quality of solutions

I recently gave a presentation about personas, and specifically how they can be used throughout a project lifecycle to ensure the highest quality. I thought I’d share that presentation with you. I’m a big fan of the approach to presentations advocated by Garr Reynolds in his book Presentation Zen. When I present my slides have no more than 1 – 3 words on them. That way people listen to what I’m saying. I also tell people that I am happy to share my slides and notes with anyone that would like them. My notes tend to be bullet points only, that way when I speak I’m not reading, I am working from my brain and it’s more of a conversation with the audience. This conversational tone is more engaging (I hope). Anyhow, on to the presentation!

Life before Personas

Life before Personas

This is my vision for how life must have been for users before Personas came into widespread use. A barren desert with users wandering forlornly around the worlds of the internet and software. Stumbling around looking for an oasis of usability and accessibility!

It stuns me when I think that Personas really came into popular use after Cooper’s The Inmates are Running the Asylum. Things must have been (and were) pretty bad before that. Thankfully though, Personas are coming more and more into widespread use. There is still, however, some fear and reluctance towards their use.

Primarily this is down to the cost and time it can take to create them, and in some cases a failure to see the great benefits that they have. I think that we, as user experience professionals, need to be better at communicating their value and selling their uasefulness. Primarily we need to be able to demonstrate that the cost and time spent has far more value that just the Persona itself.

The Anatomy of a PersonaThe Anatomy of a Persona

I’m not going to go into much detail about what a Persona is or who we create them. A Personas is a representative of our target user. I like Personas to capture the following:

  • Some very brief biographical information (age and gender bias etc.)
  • Habits
  • Skill levels
  • Environmental factors
  • Tasks
  • Frustrations

Environmental factors can be things like where they use a computer (think of a parent at home with a baby) or how they access the internet – this is extremely important when you are building for mobile devices. Does our Personas use their mobile on a bus? While walking? Important to know when you’re designing your interface.

Tasks, frustrations and goals are the really important ones. This is where we learn what we should be building and why!

Personas are not just for the use of user experience team, but for a much wider audience. Therefore, they need to be concise, accessible and a little fun (so as not to be daunting to people that have never seen or used a persona before). This is because they should be used throughout the requirements, design, development and delivery phase of the solution creation process.


For me one of the most powerful things that we get from using Personas is empathy. It can be looked on with a certain amount of suspicion in the business community as it seems too emotional and not logical enough! Empathy allows us to identify with the needs of our users. It allows us to get to know who were are developing our solution for. Empathy brings us close to our users and helps us to understand their goals.

Empathy helps us to build usable and accessible soutions. We have traditionally concentrated on having empathy with our end users, but (for those of us in an agency/freelance/consultancy environment) we also need to have empathy with our clients.  I always encourage having a personas for your client also.

Personas allow us to understand the needs of the end user and the client alike.


Understanding the needs of our end users has been accepted as being important. However, I feel that it is equally as important to understnad the needs and motivations of the client. This allows us to speak to them in a language that they understand, and speak to them with authority about their business and needs.

This is important as it gives the client confidence that we understand their business and business needs, and what they want from the solution . It also builds trust.

I  believe that it is really important to be embedded in with the client. Be part of their process and allow them to feel like an integral part of the project. Too often the approach is taken to have some requirements meetings, dissapear for a period of time, and then present back the solution. We need to be more engaging and engaged with our clients.

Understanding, and its role in Personas, allows us to interact more efficiently with our clients.


The Holy Grail of what we do! Good usability is what we strive for in our profession. By empathising and understanding we put ourselves in the shoes of the user and take that first step towards a usable solution.

Usability is also good for business! Jared Spool tells us about the $300 million Button, where some usability tweaks resulted in an increase in revenue of $300million. [When I was presenting I talked through this story, but online I think you’ll prefer to read Jared’s account itself.]

A usable solution is likely to be a successful solution. Personas are an integral part of getting the usability right and getting the solution right.


We employ lots of different techniques to build a Persona. Quantitative, where it’s all about the numbers and the data:

  • Surveys
  • Web Analytics

Qualitative, where it’s all about the individual:

  • User Interviews
  • Contextual Enquiry
  • Focus Groups
  • Diary Studies

These methods allow us to understand the user, but they also allos us to understand the problem space that we are working in. They can help us to find new opportunities for growth and to identify competitors. They also give us more insight into user trends in general.

The research that we do for Personas should not ust be used for the creation of Personas, but we should see it as another source of valuable business information.



Personas play an integral part when it comes to designing the solution. By using Personas, and the data that we get from creating them, we now know who we are designing for and why.

Personas allow us to make the right design decision. There’s a quote I like (but I can’t remember who it is by) that speaks volumes for the use of Personas:

Personas keep the You out of User

By constantly thinking about our users, in the form of Personas, we ensure that we design the right thing, instead of something that we think is cool, interesting and exciting.

Personas, and understanding our users’ goals, allow us to make better design decisions.


Understanding the goals of our users means that we build the most appropriate solution. This understanding allows us to validate if our ideas are what the user really wants and needs, rather that what we (or the client) thinks that they need.

I was working on the rebuild of a mainframe CRM/Claims Management system about 8 years ago, moving from a green screen VMS/VAX system to a Java based web system. The clients was very excited and was talking about colours and the design of the screens. However, when we say down with the end users we got a very different stories.

The user goal was to process as many claims as possible in a day, as they were bonused on throughput. They were very skilled at navigating the system using keyboard only, and rarely looked up at the screen (eyes on the claim form and fingers processing and navigating).

The screens that we presented to the client were not at all pretty, and initally got a cold resonse. However, we explained that the users needed a quick system that maintained their kepyboard shortcuts – otherwise getting buy in of this new system would be very, very difficult. It also meant that the throughput of claims would stay the same, which was good for business.

The end solution was functional, usable but not a pinnacle of design! Everyone was happy (except our internal design team!).


As I mentioned earlier, I strongly advocate having a stakeholder persona. This helps us to ensure that the needs of the business are also kept in mind – after all, they are paying the bill! They also allow us to further understand the business itself.

They are particularly important when you are building something like a content management system. We not only concentrate on the end user of the site (for example), but also on the person generating the content. During the redesign of we had an editor Persona who represented the editors that generated and updated the content on the site. Have a back end system that was easy for them to use was very important. It allowed them to concentrate on the content and not battling with a system that made it difficult for the to do their job!

Personas are not just about the end user, they are also about the stakeholder and the business in general.


Personas play a really important part in the development process, especially in an Agile environment. There are blogs and discussion groups dedicated to the pros, cons and challenges of integrating UX into an Agile development process, so I won’t go into that here!

Thinking about testing, agile and UX are ideal bedfellows. Microsoft coined the RITE (Rapid Iterative Testing and Evaluation) method, where we test early and test often. A technique widely advocated by UX evangalists and gurus. By knowing who are users are, we can quilty find people that match our Persona; thus aiding in this iterative testing technique.

Agile is all about user stories and our Personas represent our users and their stories.


I think that it is important to always ask who we are building a solution for and why; and to ask this question regularly. During the development phase we need to question which user we are referring to in a user story, what is the benefit to this user and what is the benefit to the business of doing this piece of work.

Personas should be everywhere! At every meeting, especially iteration planning meetings. There are many ways of presenting Personas and making the available at all times:

  • Posters
  • Cardboard cut outs
  • Mood Boards
  • Top Trump style cards

To name but a few I’ve seen and heard about!

Personas ensure that we focus on building the right thing for the right people.


Personas can play an invaluable role during brainstorming meetings, using the presentation techniques I mentioned in the last slide but also by employing role playing!

When trashing out ideas of a solution it can be both fun and helpful to have someone play the part of the Personas and answer questions as that Persona. This is a great way of making sure that we focus on the user and build the right thing.


I like to have a Persona that has a disability, be it physical or intellectual. This makes sure that we keep accessibility at the forefront of the design and development phase. It ensures that we always ask ourselves how a user with a disability will interact with our solution.

This also plays well with progressive enhancement and agile processes (build and iterate). From the point of view of the business by keeping accessibility to the fore, we are taking really positive steps towards good SEO (Search Engine Optimisation).

Personas bring value at every stage of the process.


Personas allow us to determine the effectiveness of our approach to and design of a solution. The allow us to do this early in the development phase.

This is important for our client as they know that we are building the best solution for their users/customers. This is also important for us, to make sure that we are on the right track.

So, how do we measure this?


Test early and test often! I am a big fan of Guerilla testing, quick and dirty testing to make sure that we’re on the right track. This is not a replacement for formal testing, but a valuable addition to the testing arsenal.

This works really well in an agile development process as it is low cost and high value. It is also quick, as testing with 5 people will get you good enough results (if you’re doing it regularly and iteratively).

Personas allow us to identiry the right people to test.


By conducting regular testing we can catch issues early and address the quickly. This means that there is no snowball effect of missing an issue, which may result in a dirty patch later to address it at a late stage.

Regular testing also helps to underpin the Agile was of iterating over features/stories – which is very often overlooked and skipped!


Personas play a really powerful role in communication.

Both out communication externally with our clients, but also internally within our project team.


Humans are, by nature, storytellers and storylisteners. We are more receptive to a story. Research has shown that the recall of facts is much, much higher when the facts are presented in an anecdoatal fashion.

Personas tell a story, or more specifically, allow us to.

By telling a story, based on a Persona, we can more easily communicate our ideas and sell our vision.


This helps us to build consensus. By telling a story around a design or feature we make it easier to get consensus. “Joe gets home from work and likes to catch up on the news. He doesn’t have much time before he goes back out to meet his friends…“. By couching an approach like this we are not imposing our opinion, rather we are saying what is best for the user.


Since we are not presenting our idea, which may not be the same as the clients’ idea, but the best way for our users, we can build consensus. But this also helps us to get commitment.

We are presenting the best thing for the user – it’s not an opinion, it’s the best thing for this neutral party. This means that the client doesn’t feel that we didn’t listen to them and their idea and that we imposed our ideas. Instead, it’s all about the user.

This reduces the chances of hitting that unpleasant moment during a meeting when a client says:

I’d like to revisit the idea I had 6 weeks ago…

Personas allow us to keep the You our of User.

Start to Finish

Start to Finish

Personas are not just an instrument that we use at the beginning of the solution building process. They are something that we can use to great effect from start to finish.

They help us to DETERMINE waht it is the solution should be, by giving us empathy and understanding.

They help us to COMMUNICATE our vision and help us to build consensus and commitment.

They allow us to MEASURE our ideas and the effectiveness of our designs.

And they can CONTRIBUTE to the work of different groups, be it development, marketing or sales.

All this end to end value by providing us with an insight into our users.

The EndQuestions!

It’s at this point that I thank people for listening, tell them I’m happy to share my presentation and notes and ask for questions to kick of a discussion on points that people agreed or disagreed with!

Online I’d like to mention that the images I used were primarily from stock.xchng, with 1 or 2 from Flickr.

I hope you found this useful and interesting, or that you disagree with it – it’s all about sharing ideas and debating them, something I’m always happy to do.

The slideshare for this is here: