Why do we need well-researched personas?
After we go through the effort of researching who our user is, what his goals are, where he will use our product, and all that fun stuff, we need a way to use everything we learned in our designs and come up with products that have the best chance to become successful.
One of the better ways of doing this, is with the use of personas. A persona is a model, an abstract of the complex results we obtained while working in the field. A summary, if you will, giving us a way to think and communicate with other team members and stakeholders about the target audience.
This will be a two part series:
- Part 1 – we will take a close look at the why of personas. The theory you might say.
- Part 2 – this will be all about the how of personas. A dive into the practical side of things.
What personas are not...
Let’s start by getting rid of a wide spread misconception.
Personas are NOT real people!
While based on the behaviors and motivations of real people, they are prototypes of behavioral data gathered during interviews, behavior patterns observed during research, and in the end a mix of all that data. We use them to get an understanding of the user’s goals within a specific context. We use them to explain our design decisions to others who need to understand why we did what we did.
A persona needs to communicate the user’s goals clearly. You cannot afford to be lazy here:
- It is not enough to slap together a couple of generic profiles using stereotypes.
- It is not enough to staple a stock portrait on a job description and be done with it.
- Oh, and there certainly isn’t such a thing as a ‘pseudo persona’.
For them to be effective, we need to carefully analyse and select those trademarks and patterns most useful for getting the message across and those that represent the broadest cross-section of users.
Personas are not the only way to explain your design decisions, and they should be part of a greater concept. Workflow models, experience mappings, and physical prototypes are all valuable assets to make sure your designs will result is the best possible products.
Why use models at all?
Some argue the use of models like personas being useless. They are wrong.
Models represent complex structures, relationships, and patterns, so we can better understand them. They allow us to visualize, motivate, and discuss these things. In science they have been long accepted as being necessary. In marketing and advertising visual models, such as charts and infographics are widely used. Without modeling, we would need to make sense of unstructured, raw data, without framework, without any means to filter out the noise.
Because we design for real-world users, it is important that we understand and visualize the important aspects of their relationships with each other, with their social and physical environments, and of course, with the products we are going to design.
Just as physicists have created models of the atom based on observed data and analysis of patterns in their data, so must designers create models of users based on observed behaviors and analysis of the patterns in data. Only after we formalize these patterns can we hope to systematically construct patterns of interaction that match the behavior patterns, mental models, and goals of users.
Personas give us this formalization.
The theory of personas
Q: “Who is your target audience for this new product?”
A: “Everyone… I want you to design it so it suits everybody!”
To design a product that must satisfy a broad audience of users, an often chosen approach is to include as much functionality as possible to make it useful for as many people as possible. This approach is wrong!
The best approach to accommodate a wide variety of users is to design for specific types of individuals with specific needs.
When you include functionality to satisfy the needs of many, you increase the cognitive load and navigational overhead for all your users. Functionality that is liked by some users, probably will be an interference for others and reduce overall satisfaction. Software is often designed to please many users, resulting in low satisfaction.
A prime example here is Microsoft Excel. While widely used and often mis-used and abused, there are very few people who know this program inside out.
- Most users hardly reach the intermediate level, compared to the possibilities, even if they are considered the company expert.
- A lot of users, who need the program for their daily work, are actually scared of unexpected things happening. They have no control over the situation and their experience with the program.
- Spreadsheets build by one user, are most often not very useful for other users, unless they remain at a very basic level.
- The variety of possibilities to reach the same goal are off putting for some, and reduce learnability between users as they most likely will have developed different flows to reach similar goals.
- In most recent versions Microsoft introduced Data Models in Excel, even further extending the boundaries as users now also need to know about relational databases. Automatically adding simple lists to this model, with ‘helpful automatic functionality’ not only does not help; the unaware user has no idea what is happening and what he getting himself into.
Splitting the application up in several different programs would help. Having finally realized this Microsoft has started with Power BI and such apps. Introducing several versions of Excel, with different target audiences / personas in mind seems a good next step.
The key to this approach is first to choose the right individuals to design for. These are users whose needs best represent the needs of a larger set of trademarks and patterns found. Then we prioritize those individuals in such a way the needs of the most important users are met without compromising our ability to meet the needs of secondary users.
Personas provide a powerful tool for communicating different types of users and their needs, then deciding which users are the most
important to target in the design of prototypes.
Advantages of Strong Personas
Personas help take away multiple issues that are currently causing problems with digital product development. They help us with:
- Determine what a product should do and how it should behave.
Personas goals and tasks is what we look for as a design fundamental. - Communicate with stakeholders, developers, and fellow designers.
Personas give us a common language for explaining and discussing our decisions. They also help us keeping focus on the user every step of the way. - Create commitment and agreement on our designs.
With the common language from the previous point, comes common understanding and consensus. With personas available there will be less need for other means of visualization and explanation; the narrative structure will bring the different archetypes and profiles to life. Resembling real people will make them easier to relate to and build empathy. - Measuring the effectiveness of our designs.
Just as with user testing, our designs can be tested against the available personas. This does not replace the need for user testing, but it can serve as a reality check. It keeps our designs in check at the “inexpensive whiteboard” stage, allowing for quick learning and fast iterations. Furthermore, it will ensure a better baseline of our designs at the actual user testing stage. - Contribute to other product related channels such as marketing and sales plans.
It is not uncommon for these plans to deviate widely from the “real world research” being done before creating personas. After all, most of these plans are cooked up high up in the ivory tower, far away from the trenches. Once an organization realizes the power of these models, it can greatly benefit from the knowledge they provide.
Other design problems personas can help with
The elastic user
Naturally everyone involved in the design and development of our digital products believes they are designing to satisfy the needs of the user. After all, we are working according to the guidelines of user-centered design.
And yet, here lies the source of a fundamental problem.
Who is this mysterious “user” everyone is talking about? More importantly, is everyone talking about the same thing when they talk about the “user”? The answer is a clear “NO!” The phrase “user” is ambiguous, broad, free for interpretation by all to suit their own needs.
Its imprecision makes it dangerous as a design tool; every person on a product team has his own conceptions of who the user is and what the user needs. When it comes time to make product decisions, this “user” becomes elastic, conveniently bending and stretching to fit the opinions and presuppositions of whoever’s talking.
The development team sees no problem in introducing a complex, nested, tree structure to browse folders and files, as the user of course is computer literate. That same team will happily introduce a step-by-step wizard when they feel like it, as the user suddenly becomes a first time novice.
Designing for such an elastic user allows a product team to basically do whatever they want in the spur of the moment. And while doing so still claim with confidence they are meeting the needs of their user.
Of course, our goal should be to design products that appropriately meet the needs of real users. Real users, and the personas representing them, are not elastic, but rather have specific requirements based on their goals, capabilities, and contexts.
Even focusing on user roles or job titles rather than specific archetypes can introduce unproductive elasticity to your designs. For example, in designing clinical products, it might be tempting to lump together all nurses as having similar needs.However, if you have any experience in a hospital, you know that trauma nurses, pediatric intensive-care nurses, and operating room nurses are quite different from each other, each with their own attitudes, aptitudes, needs, and motivations. A lack of precision about the user can lead to a lack of clarity about how the product should behave.
Self-referential design
Self-referential design happens when designers or developers project their own goals, motivations, skills, and mental models onto a product’s design.
Many “cool” product designs fall into this category.
The audience doesn’t extend beyond people like the designer, which is fine for a narrow range of products and completely inappropriate
for most others. Similarly, programmers apply self-referential design when they create implementation-model products. They understand perfectly how the data is structured and how software works and are comfortable with such products. Few non programmers would agree.
Edge cases
Another scenario that personas help prevent is designing for edge cases, those situations that might possibly happen, but usually won’t for the target personas.
Typically, edge cases must be designed and programmed for, but they should never be the design focus. Personas provide a reality check for the design.
We can ask: “How often will Mary perform this operation? Will she ever?”
With this knowledge, we can prioritize functions with greater clarity and confidence.
Final words
So, now we know why personas can be an important model with great influence on the success of our designs.
Now let’s turn our attention to how we create these archetypes of our user bases.
Until next time…
