Purposeful Persona Building: Design Thinking Part 2

Remember our friend Empathy from the previous article? Well, now that you’ve interviewed, observed, and worked alongside your end-users and fully understand what it means to walk in their shoes, it’s time to leverage that new knowledge.

You’ve likely interviewed people in many different groups or roles within your organization. While analyzing your notes, you may begin to notice that certain people have similar needs, pain points, goals, etc. You can use this information to start persona building.

 

What Are Personas?

A persona is not based on any specific person, but is an abstract representation of many people with similar characteristics. Developing personas based on your research insights can help you focus on designing solutions without having to concentrate on dozens, hundreds, or thousands of people in your target audience. Personas help you keep a high-level understanding of people in mind during design without necessarily having to keep every person in mind.

 

 

Something we often hear from our clients is that it’s difficult to start projects with a broad or undefined audience.  Males and females. Ages 20 to 65. Business and IT. Sales and Finance. New Hires and Veterans. Thinking at too high a level doesn’t let you make any valuable connections. How do we get more specific without completely blowing out our project timeline?

Start by looking at the clues from your research. Where are there natural groupings? Is it around a particular role or job function? Or a type of user? Or skillset?

Here’s an example based on the process we use for persona building. First, we create persona buckets (based on research or your pre-research intuition).

• Executive – Finance
• Department Administrator
• Front-line Contributor

 

Names and Background

You need to create names for each persona – this is critical because you’ll refer to this name often. Names bring your personas to life. You’ll begin to think of them as real people as you design, which is really the key. Saying things like “Alice would never do that” or “Scott would find this useful!” will suddenly seem normal to you. It’s a professional excuse to have imaginary friends with the added benefit of better designed products and services.

• Executive – Finance (Victoria)
• Department Administrator (Geoffrey)
• Front-Line Contributor (Lucas)

With names in place, we can then create a quick back story or biography to provide context.  Don’t add too much fluff like “enjoys coffee and works out daily” unless it is relevant to the project you’re working on.  If you get too cute, people will dismiss this valuable tool.

Let’s start with Victoria, our first persona:

 

Executive – Finance (Victoria)

Victoria is the VP of Finance at the organization and is the ultimate authority within her division. She is responsible for managing the financial health of the division, and oversees multiple departments within it. With 18 direct reports, her status meetings consume much of her time and this leaves her fire-fighting instead of proactively addressing issues.

The Victoria persona is a combination of several executive-level users uncovered during discovery who shared common needs, processes, pain points, and perspectives distinct from the needs of the other personas. All had multiple direct reports and financial reporting responsibility, so we captured them in a single persona to easily keep track of their perspective as we went through analysis and design. Similar combinations were performed for the other personas below.

 

Department Administrator (Geoffrey)

Geoffrey is the Department Admin for the BI practice. He is responsible for managing the practice, setting strategy, and adhering to the financial targets that the Finance department sets. He meets weekly with Victoria to receive financial status reports, but he is struggling to pull actionable insights from the reports.

 

 

Front-Line Contributor (Lucas)

Lucas works as an Analyst in the Consumer group. He does his job well, but is frustrated at the lack of progress his group is making. He feels that they’re putting in more effort and achieving less. He wants to pinpoint where the bottleneck is.

Make sure to include relevant information in your biography.  If you project is heavily focused on process, be sure to include how your persona behaves.  More on that below.

 

Adding Detail

With their core backgrounds defined, we can begin to expand our descriptions of our personas’ goals, motivators, frustrations, behaviors, key needs, current tools, and processes.  It all comes together into something like this persona template we use at Ironside.

 

Download Persona Template

 

After you enter the basic demographic and biographic information, start to fill in the other details called out above.

1. Photograph
   It’s important to have a visual representation of your persona. It helps to put a fake face to the fake user you’re creating. Select an image that strikes a balance between a generic stock photo and jarringly unique. Go for believability.
2. Key Quote
   This is a one-line quote, either captured directly from interviews or paraphrased, that communicates your persona’s perspective or experiences.
3. Goals & Motivators
   What does this user hope to achieve? What task do they want to complete? What is driving this project/conversation/need? Asking why during interviews helps flesh out these details. The user doesn’t need a report, they need a tool that helps them prove their value, provide support for their team, turn the business around, etc. It’s a much deeper need than a feature, function, or output.
4. Ideal Experience
   Ask the users what their ideal experience looks/feels like. Bonus points if they close their eyes while doing this as you know they’re really imagining a future state. Here you’ll gain some insight into their thought process, goals, key features, etc. This field helps tie together the other fields.
5. Current Tools/Processes
   How do users currently solve the problem that sparked the project? If they can’t currently solve the problem, what tools or processes do they use that might be related to this project. The key here is to identify their problem solving methodology and user flow.
6. Key Features Needed
   During your user research you’ll likely identify key features that they need. You can either ask them outright or you’ll hear the feature(s) referenced repeatedly by multiple users. These typically tie back to goals. Capture them here and remember to validate the need for these features during analysis and design.
7. Frustrations/Pain Points
   Here you’ll note things the user wants to avoid or obstacles that prevent them from achieving their goals. Sometimes frustrations are loud and clear during research phases. You may hear “I hate that it does X” or “I’m sick of having to do Y.” Other times it can be subtle “I wish” statements, such as “I wish we could have X.” Or a very generic statement, like “our data quality sucks.” Make sure you probe during the interviews to identify the root cause of the frustration.
8. Behaviors
   This is the “day in the life of” category. What it’s like to be the user on a daily basis; what links their goals, motivations, pain points, and process together. It can be used to describe how they relate to others, how they relate to technology, when and how they will use the product, and other behaviors that might apply to their daily routine as it relates to this project.

 

Fine Tuning

A persona template can be flexible.  If there are things you need to capture such as devices used or skill level with a certain software or process, then add it in. If you don’t want as much detail as outlined above, drop out some categories.  At a minimum, you want to have goals, motivations, and pain points recorded.

Keep in mind as you develop and customize your persona building process that the purpose of this tool is to distill and easily communicate high-level information about your audience.

With all of the personas in place and validated with research from your interviews, you can now leverage these in your design process.  When thinking through any user flow, feature, functionality, or analytical need, ask yourself WWPD?  What would <persona> do?  This links back to our discussion on empathy.  Put yourself in your user’s place.  A persona helps abstract many different users while still keeping their needs front of mind.   You can then begin to develop user-centric solutions by walking through your design as that user.

Our example personas above can be used to discuss which design direction or user flow to implement:

“Victoria may want to see the high level summary, but Geoffrey and Lucas need the details to determine what’s driving those metrics.  Maybe we need two dashboards instead of a one-size-fits-all dashboard that doesn’t satisfy everyone’s needs.”

 

Or product features:

“Victoria wouldn’t care about this detail data…it is buried too far in the application.  Should we drop it or refine the access path?”

 

Or priorities:

“This doesn’t help Lucas achieve his goal of a single page dashboard with metrics specific to his role/department, let’s parking lot this requirement for now.”

 

Conclusion: Persona Building in Your Organization

Creating personas doesn’t have to be a long exercise. In fact, as the previous sections have shown, it really boils down to a few simple steps:

1. Run through your notes from the discovery phase.
2. Identify commonalities between users.
3. Group related users into a single persona.
4. Name your persona.
5. Fill in the details about that type of user.
6. Reference your persona when going through the feature prioritization and design stages.

Persona building is a useful gut check that helps you justify decisions during an analytics project while keeping users in mind. Your users will appreciate it and you can keep reusing and refining your personas in future projects, making sure you always arrive at results that fit your organization’s needs.

 

Enter your email below and download the Persona Template

Read the rest of the Design Thinking series and related articles:

• Get By with a Little Help From Empathy
• The Dashboard Design DL
• Analytics End User Adoption

 

 

 

 

About Ironside

Ironside was founded in 1999 as an enterprise data and analytics solution provider and system integrator. Our clients hire us to acquire, enrich and measure their data so they can make smarter, better decisions about their business. No matter your industry or specific business challenges, Ironside has the experience, perspective and agility to help transform your analytic environment.