Understanding user needs is a fundamental value proposition for user experience work, and personas are a well-known user experience tool. You might be wondering how practical they are, though, particularly if you are building applications for users within your own organization. Besides helping you learn more about those users, personas can be a great communication tool for the product team in every phase of development.
Align the product team and reveal assumptions.
Personas have to start somewhere. You might already have market research, or user profiles, or even legacy personas to work from. These can be great resources for deciding how many people to interview. If you don’t have that, though, you can start by interviewing the people on the product team who know the most about your users. Get everyone together for a workshop to create “assumption personas.”
Even if you do have some initial user segments to start with, I would still have the workshop, because at the end, you have a group of stakeholders who are all thinking about the differences between users. They get the chance to discuss their assumptions with each other. They can also start thinking about which users are most important.
While you validate, you’re building empathy. So what?
The next step is to validate those assumption personas by talking to actual (or representative) users.
Your team might already be intimately familiar with the analytics–the metrics you’re trying to improve. If you’re working on the application, chances are decent it’s because you’re passionate about solving the problem, and you already have some very good ideas about how to do that. But, you’re not your user, in most cases. And having a good idea of what is broken in your business processes is not the same as knowing why the humans who use those processes are having trouble.
During persona interviews, listening to people tell their own stories, you get two major benefits:
- A healthy appreciation of that person’s point of view. You might think you know why they aren’t doing things right. You will learn something from hearing in their own words about their struggles and concerns.
- Ideas about which details will matter most to which types of users. It’s the little differences that make daily use of a work tool either seamless or hellish.
This is why besides having personas as a reference document–besides a bullet list of user goals–people on the product team who participate in creating the personas get additional understanding that can’t be fully captured in persona posters and business cards.
Big win for organizations with a variety of users: the ability to prioritize.
Which users are the most important for your project? You know who is sponsoring the project. You know the goals for the project. So, which users will have the most impact on those goals? OK, maybe you know that, too. But what will make them happy? What will help them? Those are the qualitative details you get from sitting down and asking them about their day-to-day experience.
When you map the behaviors, attitudes, and needs of your various personas to your project goals, you can figure out which users to focus on at a more granular level. You also learn which users pose the biggest risk to those goals.
Make design decisions that favor your priority personas.
Let’s say you have three personas:
- Brad is your new employee, with relatively little domain knowledge and high expectations for software usability, based on the consumer apps he uses.
- Julie is your veteran superstar, who uses 80% of the product features and has expert workarounds for known issues.
- Beverly is your part-time employee, performing the same small subset of administrative tasks frequently.
If you prioritize Brad, here are the types of design principles you might have in order to accommodate him:
- Terminology: task-based menu and field labels, rather than references to legacy systems. Avoid cryptic abbreviations and codes without descriptions.
- Layout: group functions together that are used together, even if it means some replacement of legacy code. Prioritize the time and effort it takes to define field and button validation and instructional content.
With your personas, you can also keep your discussions organized when you think about things like:
- How flexible do you need to be with these principles when you need the app to have robust functionality for your expert users?
- How do the use cases differ across personas?
- How do the different personas prefer to review content? Scanning a list to compare items? Reviewing records one at a time?
Personas will be useful throughout the product life cycle.
They’ll help you answer questions like:
- Which groups do you need include when you are eliciting requirements? You’ll want to talk to people based on role segmentation, but also based on personas.
- Who should help with pilot testing? Perhaps those who are more inclined to be flexible and to provide constructive feedback.
- Who can be a champion during change management? Or, who might need more focused communication in order to bring them on board?
Just get involved in the workshops and observe the sessions. You’ll be brimming with your own ideas about how to use the information.
