A Mentor Tutorial
This tutorial breaks down the typical persona used by Mentor Creative Group. In this article we will explain some of the hows and whys around our process in crafting this important design tool. You can access a template for this deliverable from the Mentor website.
At this point you might be wondering why we use a generic word processing tool like Google Docs instead of an Adobe product that could produce a high polish, styled deliverable. There are three reasons behind why we use Google Docs for making personas:
- It’s easier to work with other researchers. Using a collaborative tool like Google Docs means anyone can go in and make edits or leave comments.
- It’s a scalable template. Your team won’t have to rethink the layout every time new insights are added.
- It’s easier to share with clients. As soon as you have an outline, your team can add your client stakeholders as view only or view and comment only. We find clients are often excited by this level of transparency.
Now that we’ve explained the rationale behind using Google Docs, let’s take a closer look at the anatomy of a Mentor persona.
A persona name should always include a first and a last. Unless you’re a celebrity like Sting or Beyonce, you have a last name. At Mentor, we use persona names in just about every part of our process from concepting solutions to writing user acceptance criteria on Trello tickets. Once a persona is named, your team needs to start using it everywhere. This will help prevent some of the natural bias we place on our designs.
“Using persona names prevents people from saying things like, ‘’As a user I’d want [insert personal bias]’.”
An archetype is a secondary label for your persona that hints at the broader group of individuals she represents. Archetypes help to categorize new findings and identify what makes each of your personas unique. We often refer to a group of personas as a cast of characters where the persona archetype helps you identify what role she plays in the overall user experience narrative.
“In the first test, the participant was definitely more like Taylor, the adventure seeker archetype. We should add some of our testing insights to her persona profile.”
When picking images, Mentor tends to stick with something that is between amateur photography (most Facebook photos) and stock photography. As a consulting company, we need a certain level of image quality and uniformity for client presentations. Occasionally we use more than one photo if we want to show this persona engaged in an activity or an example workspace.
“Keep asking yourself, does this person seem real?”
For quotes, your best bet is something that was actually said in a user interview. They should be short, memorable, and encapsulate the persona within the context of your project. For example, if you’re working on a e-commerce project, make sure her goal is in some way related to the act of shopping. Quotes are a quick way to gut check an idea by comparing what your persona is trying to do and the concepts you’re coming up with.
“The best quotes are pulled directly from interview transcriptions because they sound authentic.”
Goals help frame user motivations and provide a rationale around why a persona has specific needs and pain points. A primary and secondary goal might not always be needed but if the persona does have more than one goal then make sure they are prioritized. This prioritization will help your team align workflows to the most important thing your persona is trying to accomplish while satisficing the needs of secondary goals and personas.
“Conflicts between personas is common which is why prioritization of personas and goals will balance your designs.”
Behaviors illustrate regular routines based on their existing mental models. You could also think of behaviors as common activities routed in a system of thinking based on her environment and how she learned to do something. This is important because knowing what a persona already does and why they do it will help ensure your ideas map to existing user behaviors.
“A well crafted solution will still perform poorly in testing if you ignore how people currently think.”
Pain points are used to break down the specific challenges a persona faces when trying to achieve a goal. You can think of them as mini problem statements. Pain points act as a rubric when evaluating solutions to see if the problems she runs into are actually being solved. The best solutions design away your persona’s pain points verses addressing the symptoms of her problems.
Treat them like a rubric to evaluate whether your solution is solving the right problems.
Relationships show how your personas interact with each other through different scenarios and can help identify who is the primary persona based on overlapping interests. Just like behaviors, relationships show what users are already doing and who they are doing it with. These real life touch points will have an impact on how people use what you are designing. Leveraging existing relationships in your solution is always a good idea.
“We don’t just live online. How people interact with others peripheral to what you are designing is important.”
Always provide links to your findings as proof that you’ve created a research-driven persona. In my experience, very few clients will read them, but the presence of citations definitely shows that you’ve done your homework. That being said, your recordings and notes should be organized and easy to follow. Finally, respect your research participants and anonymize your data as needed.
“Research citations here are like any other citation. They provide proof that you did legitimate work.”
If you found this article useful, you can find a list of our other tutorials and templates on the Mentor website.