Personas

Introduction

I have mixed feelings about personas. I think my mixed feelings have arisen from improper usage of personas. Personas suffer from the challenge of… if not done properly then not only are they not helpful they are actually harmful to the User Experience process. However, when created (and validated) and used throughout development they can be very helpful.

Personas are fictional representations of users in order to understand common target user for your product or site. I originally come from an instructional design background which had an important upfront task of audience analysis. Who are your users. What are their goals? What are common traits among them behaviorally? Personas give a vision of what your users are like at a very general level and help you develop insight into how and why you should design content and interactions in certain ways.

Personas Are Not Roles

Personas are not roles. My working experience in UX comes from an internal corporate enterprise IT role. My audience has never been externally facing customers. It is employees of the company. A common persona crutch is to just say that your personas are the roles (regular user, administrative user, special role 1, special role 2, special 3 role 3, and etc.) Understanding user roles is an aspect of generating a persona. I would typically assign a role to a persona because that will affect those personas goals. However, it does not necessarily affect other traits you may assign to the persona (e.g. technology adeptness, environmental properties, patience levels, and things of that nature)

Roles are useful at the IT level to assign permissions and to focus content strategy. Roles are not a good representation of your average user. In several corporate projects understanding roles was an important aspect of understanding the users. However, there were plenty of cases where multiple personas would hold the same role, but their personas were NOT similar.

I feel like this is a very distinct issue within a corporate environment where focus is often put on things like role permissions and levels of access. Yes. Different roles will have different access. Yes, different roles will have different tasks that they perform. But, no, those users in the same role will not typically behave the same way, and do not typically interact with your system within the same environmental context. Make sure you understand your users at a context level, not just a role level.

Examples

How do you develop personas?

My ideal persona creation process constitutes the following steps if we are starting from a blank slate.

Step 1 – Task Analysis

What are users trying to do? Users interact with websites and products to accomplish goals. In day to day interaction they will have common tasks that they perform and they will have infrequent tasks too! When thinking about developing core system functionality it’s important to understand what users want to do.

In a corporate internal software world this is often understood from the start. Systems are implemented or created not from a user-centric view but from a compliance or critical task view. This provides a different motivation view for users. They may only be using the system because they have to use the system. Understand what users need to do and how the system may initially be set up to do those tasks.

In a public facing product where your audience is… anyone how do you understand important tasks? The difference is understanding user motivation and this is what we’ll gather in the next step as we start to develop our personas more!

Creating task flows is a good start! I like to ask developers or project managers. Give me the elevator pitch for your site. This helps quickly identify common tasks and can give you a good starting point for understanding task flows and common tasks within the system.

Step 2 – Audience Analysis

Now it’s time to talk to the users!

No, not ideal users.

No, not SME created users.

What about surveys?

I love data analysis. I really do. I love survey design as well! I would never develop personas based SOLELY on survey results. Regardless of how amazingly designed they are. I would use surveys as a first triangulation point for understanding users. These can be distributed out to a large target population of users. I like to conduct sentiment and thematic analysis on survey results with clearly defined codes that can be assigned to user responses to help categorize responses.

Surveys give us a great starting point for getting a better view of our users! Now, let’s increase the fidelity and conduct user interviews within segments to really fill out the fidelity of our users.

I am a huge fan of user interviews. For more than just persona creation too! How do you pick users? Well, this is where your task analysis helps! Roles too! (Hey roles are not personas!) That’s right they’re not, but they are features of personas that can help you segment your audience based on system capability. I like to develop a list of talking points or questions based on tasks that I’ll ask users. However, ideally I like to let the user drive the conversation.

Step 3 – Develop Personas (i.e. construct persona artifacts)

You may have a bunch of personas. Maybe only a few! It really depends on the complexity and range of tasks within your system. You will begin to see common themes among users. This is where you can start creating your user personas!

Hey, in Agile they create user stories isn’t that the same thing?

No. (kind of) User stories are closer to task analysis not to personas. They help your product team conduct development tasks to create a feature and understand what the ultimate goal of that feature is. As X user I want to be able to do X. That’s a great start! But User A and User B may approach that task differently.

A great anecdote I have for this comes from my corporate experience in UX. There is a common task in a system that is used by all company employees. However, some employees sit at desks in offices. Some sit at desks at home. Some are in manufacturing environments. Some are in the field. Some are international. Some users have additional contexts of accessibility considerations (e.g. poor vision, color blindness, dexterity issues, etc.). They all have the same goal to accomplish but will accomplish those goals in different contexts and in different ways. The at the desk user is in what I call the ideal environment. However, users out in the field often have to accomplish tasks from a mobile form factor. Accessibility issues for users with certain visual or dexterity issues may have to use your system with adaptive technologies which is also a completely different context! They are going to have different pain points and different experiences accomplishing the same task. Same goal, different experience.

Once you have your group of personas next comes the most important task. VALIDATION.

Example Persona Anna - Descriptive Text Follows
Example Persona Anna

User Anna
Standard User
Age 21

Hardware Traits
• Laptop & Mobile
• Mouse & Keyboard & Touch
• Lower Resolution (Laptop)

Behavioral Traits
• Loves aesthetics
• Dislikes long media
• Adaptable to changing site
• Ignores detail text

Goals
• Explores new features
• Spends a lot of time on site
• Switches tasks frequently

Tasks
• Checks personal profile updates
• Checks personal feed
• Adds images to feed
• Create new posts

Frustrations
• Disrupted by timeouts because of multi-tasking
• Dislikes long detailed instruction text
• Dislikes deep site structure (too many subpages)

Example Persona Frank - Descriptive Text Follows
Example Persona Frank

User Frank
Standard User
Age 37

Hardware Traits
• Laptop & Mobile
• Mouse & Keyboard
• High Resolution

Behavioral Traits
• Persistent
• Figures things out
• Keeps to consistent pathing/process
• Impatient with slow loading sites

Goals
• Frequently conducts same tasks
• Spends as little time as possible on site
• Wants to complete task as efficiently as possible

Tasks
• Checks personal profile updates
• Checks personal feed
• Adds images to feed

Frustrations
• Hates having to email/call support
• Hates sudden changes to common tasks
• Dislikes by slow/flashy animations

Step 4 – Validate Personas

This can be done with targeted surveys in conjunction with user interviews. I like to do both if possible. The difference between these surveys and interviews and the prior steps is that the prior steps were exploratory surveys and interviews. These surveys and interviews in validation will take a more experimental validation approach. Since you developed a set of personas based on your exploratory interviews and surveys you can make hypotheses about target user groups. Now you can create surveys and interview users to see if they’re close!

Step 5 – Update Personas

Whew, that was a lot of work to get everything ready. But hey now we’re done right! Maybe. But probably not unless you expect to never have different users or system features. It is important to update personas in alignment with new features and also from what I like to call serendipity personas.

Serendipity personas are things I have often discovered while facilitating usability studies. This is often well after personas have already been created. But hey, remember, personas are never perfect and will not ever be able to represent 100% of your users. You want broad strokes that help cover critical and common themes among your user base. Serendipity personas arise when you start getting down into actually testing for usability and see users interact with it first hand. This did not come in your initial analysis and research because 1. you did not interview 100% of your users (I wish I could) 2. you did not interview about 100% of your tasks (this is more possible but still difficult) 3. you did not consider all user contexts (also impossible typically).

Don’t fret. Serendipity personas will arise but will sometimes only make up a fringe context of users. You should not be reactive and change based on only one or two users. However, if you start seeing a common theme that is arising in from feedback and usability testing… then it’s time to review those personas! You may have missed something… it happens.

Step 6 – Iterate

This follows on with step 5. Always be looking to refine your personas. They are never one and done up front work. They provide a good foundation for future task work, but can become stale pretty quickly especially as your product evolves. Early warning signs that your personas are out of date may come in the form of decreased user sentiment in feedback surveys, decreased performance in usability tests, and changes in system telemetry. (We’ll get into web analytics and using them as a triangulation point for health monitoring and user analysis in a different post!)

Step 7 – Great work!

If you are even thinking about doing personas you have passed the hardest part of personas. That is committing to doing personas. The next hardest part is doing them well! It’s a lot of work to develop robust personas but pays off greatly. This helps move questions from “What do they want?” to “we know what they want based on these personas”. Never assign attributes to personas based on your own intuition or expectations. Users are rarely perfect at conducting tasks and they don’t always act rationally. So you cannot create personas by thinking rationally and in best case scenario. The best way to learn about the user… it to ask them.

More Resources

Nielsen Norman Group: Personas

MeasuringU: How To Make Pesronas Scientific

Comments are closed.