Imagine you were tasked with building a transportation vehicle for two individuals. What would be your first step? If you dove head first into your list of features, you made the wrong move.
What if the person needed to travel from Austin, Texas to Oxford, England? Or what if he only needed to go across town? Knowing who this machine is for and what they’re trying to accomplish is the difference between building an airplane or assembling a bicycle. The first step to building a great product is to understand your users, and creating product personas is a key element.
A product persona is a fictional representative of a user group (role, category) with similar goals that are rooted in data (primary and secondary sources). A product persona is not:
- A true user
- The only representative of your user base
- Based on stereotype
Alan Cooper pioneered product personas and detailed their benefits in his book “The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity.” Ultimately, product personas are parameters that limit the team’s scope thereby limiting waste. Without personas, a team is guided by internal motivations – “what can we do?” – instead of external, user motivations – “what does our user need it to do?”
Decreased waste and better products that users will actually use are key benefits of product personas. In addition, since one persona represents an entire group, it prevents the team from the limiting practice of designing for one specific user. Having more than one persona for the same role/group also gives designers a source of healthy conflict when comparing the goals and desires of the different personas (which they come to see as “real”).
If you don’t have time or budget to gather data for a product persona, the team can use educated guesses to create a proto persona. According to Cooper, proto personas are better than not having anything at all, but should only be used as a short-term solution.
Product Persona Elements
Naming the persona adds context and will help the team remember important information, particularly if the name alludes to a certain detail. For example, “Ed the Executive.” With a name, the team begins to refer to Ed rather than “an executive” or “the CEO.” As they talk about that “person”, he becomes more real, acquires more characteristics, and informs design and implementation decisions.
2. Current Behavior
What does the user do in their spare time? Do they have hobbies that are relevant to product design? How does their lifestyle affect their choices and decisions?
3. Pain Points
Different from marketing pain points, which address the reasons why someone would want to buy the product, these pain points allude to the product experience. What is it that the user cannot do today? What takes too long, too many steps, or is too confusing?
What are the person’s goals when using the product? Is it to save time? Save money? Look cool? Each persona should have 3 – 4 goals. A persona with more than four goals is not specific enough and will not be as useful.
Tinder Case Study: #Goals
One could argue that Tinder’s usability and addictive swiping feature allowed it to quickly overtake the online dating market (6 billion downloads as of April 2015). Other dating apps take a lot of the user’s time. You have to create your profile, answer a lot of questions, and write your bio in just the right way. Then you have to look at profiles and answer messages.
With Tinder, your profile is instantly created through the Facebook API and all you have to do is swipe right if you like or left if you don’t – so easy you can do it on the subway. According to a Page Six interview with Tinder founder Sean Rad, Tinder users worldwide swipe 16,000 times per second.
Now one could argue that choosing a dating app is based entirely on the user’s goal. If it’s to find the one, Tinder may not be the app for you, though it may help you cure loneliness, which is the app’s main mission.
By creating product personas through surveys, analyzing site metrics, conducting focus groups, and shadowing users, teams can build a stronger connection with the user which means better products without the waste. Learn more about Agile product management and take our certified product owner workshop. We have a workshop in Dallas at the end of February–click to learn more.