You’ve spent months working closely with stakeholders and business leaders and have gone through several development iterations. You’re confident this feature is perfect … until it goes live. Then, you start to receive overwhelming negative user feedback, or users aren’t using the feature.
Personas can help solve this problem by showing you how to develop a product in the way users will actually use it. Deploying a successful development product depends on meeting the needs of each unique user of your solution. It’s important to understand what each potential user wants.
If a persona reveals your user is colorblind, you don’t want to develop a bunch of colorful screens that lack the required contrast, thus, making everything indistinguishable. Personas can also reveal why a feature or product isn’t noticed or used.
This is the first article in a three-part series where we’ll discuss how personas guide decisions in the development process that lead to better products, services, features and interfaces. This first part explores what a persona is and why we use them.
We agree with defining a persona as a representation of a user, based on research that incorporates their goals, needs and interests (Ilama 2015). The word “fictional” is used in many other definitions. Fictional means something feigned, invented or imagined. We dislike the association of the word fictional with personas.
Although a persona isn’t a real user, it’s not an imagined user either. A persona represents real users of your feature or product and helps us keep their wants top of mind during development.
Personas were born from User-Centered Design (UCD), a framework that puts the user at the center of focus. The main goal is to understand the communication process between an object and a user. This was popularized by Don Norman, a leading expert in user experience, in his book, “The Design of Everyday Things.”
* captured from various user-centered design resources & research
Personas are depicted as a specific person or character who represents a real user group. A persona is a one-page description that typically includes the user’s name, occupation, goals, behaviors and limitations.
An effective persona acknowledges the business goal by being refined to eliminate extraneous details. For example, when we initially interviewed our group of users, one woman mentioned she wanted to be a professional golfer.
It’s a fun detail we included in the persona’s first draft. Then we reviewed and discovered that detail had nothing to do with our business goal, which was to improve the timeliness of expense reports submission by providing users with a mobile expense reporting tool. We refined our persona and removed that extraneous detail to keep the team focused on our business strategy.
You may have seen various examples of personas and noticed differences between them. Personas have evolved over the years, which has led to various types of personas. You may have heard of, or even used, some of them, depending on your situation or goal.
Provisional personas are based on secondhand perspectives of the user. An example of this is having the analytics and survey results for an expense reporting tool but not having firsthand interviews or observations of actual users. This type could be considered the base of all personas.
Proto personas are created from secondary research and teams’ informed guesses. This could involve interviewing the manager of the sales team who shares with you the process he thinks his team is following to log their expense reports.
However, you aren’t able to interview or observe the salespeople who are experiencing the pain points and using workarounds for unique scenarios that don’t fit into the standard process. Despite this gap, a proto persona is better than no persona and is a good starting point to seek validation.
Buyer/customer personas represent a large segment of your audience involved in purchasing your product or service. There’s a difference between buyer and customer. If we were a third-party provider of an out-of-the-box expense reporting tool, the buyer persona would be the procurement team or the accounts payable senior management buying the product or service. The customer persona would be the managers and field employees who use the purchased expense reporting tool.
Marketing personas are focused on demographic information, shopping preferences, motivations, concerns and media habits. This type investigates how a buyer/customer would first encounter your product or service and their purchasing process that would transition to a user/customer.
You might find other types of personas because personas have evolved over the years. Throughout our careers, we’ve used all of the different types based on the situation and need.
Provisional and proto might be the most common because there isn’t always the option to interact, observe and interview actual users; typically, just a few business owners and analysts are involved. The big thing to remember is if you want to create a product/feature your users actually use, personas will reveal insights into your users. And that’s better than no persona and no insights.
Part 2 of this series will dive deeper into the persona creation process, but we wanted to introduce it. The creation process for personas follows these steps:
Personas help guide decisions about products, features, navigation and visual design by revealing the users’ goals, habits and pain points. A persona’s memorability and relatability enable development teams to stay focused on the users’ goals and tasks rather than on creating a slick feature. Personas will provide validation and informed guesses rather than assumptions.
Personas allow us to make development and design decisions that address user needs and behaviors and fix user problems. Personas can lead to a product or feature that, when a user uses it, makes his or her life better — thereby avoiding developing features no one uses.
Learn more about creating personas in part 2 of this three-part series.
Part 1 of the personas article series was authored by Jessica Rensing with contributions from Kris Schroeder.