The personas I worked on for a major financial institution took months of research to create. I wanted to involve the company’s interested stakeholders so that they were involved in the creation process as well. At the very least, I wanted their feedback on what they needed in personas so that I could meet their needs.
When I shared the personas with my colleagues for the first time, I did not want it to be a “Big Reveal.” I wanted to reflect that I had taken the stakeholders’ feedback and suggestions on board. I had researched and built a first draft of the personas. And I wanted my persona presentation to reflect that these were not just “my” personas, but in fact, they belonged to the whole organization.
Some of the Persona Feedback session included:
Sharing the stakeholder feedback I had gathered
Explaining what a persona is
Showing the difference between UX persona and marketing segments
Illustrating the persona development journey
Showing the first draft of the personas
Presenting the components and portions of the personas and describing the purpose of each part
After I explained the process of creating the personas, defining them and sharing them, then I asked the groups to critique them. I wanted feedback on four aspects about the personas:
What they liked
What they did not like
What they needed more information about
What they needed less information about
After gathering their feedback, my intension is to roll that feedback in to my next round of qualitative research. I want to make sure I am meeting the users’ needs. In this case that is the stakeholders, including designers, design lads and product managers.
I know there are many ways to build personas. Sure, you can build them on assumptions and guesses and just throw something together quickly. But actions like that just leave a bad taste I’m my mouth. I want personas to be based on research, not assumptions.
One major project I am working on now is to create personas for vehicle purchasers. Where I work, one of the products we are working on deals with the consumer automobile buying space. One things we don’t have is personas. An even bigger flow of our organization is that we are designing products without having personas to consult for our design validation. I won’t dwell on this aspect too much. Let’s just say our organization is coming to light and recognizing the importance of having personas.
My task is to build kick-ass personas. I am up for the challenge.
One of the first steps I took in building personas is to talk to several stakeholders who would have interest in these personas. I talked to designers, design leads, product managers and researchers to find out one thing:
What information do you need from a persona?
I asked a few other questions as well, but this was my primary goal in this phase of my research. I am sharing the information about “What do stakeholders need from personas” is in the attached deck.
Different people, be it a User Experience Designer or someone in the Marketing department of your company may have a persona. So what does a “persona” mean in the UX world? Wikipedia defines a person as: a fictional character created to represent the different user types that might use a site, brand, or product in a similar way. In other words, a user persona is a representation of the goals and behavior of a hypothesized group of users. In most cases, personas are synthesized from data collected from interviews with users.
How do you make a persona?
No you don’t just make it up. Pick a fictitious name, throw some random facts on a page and say “This is our personal Sally Student.” No, no, no. You use actual user research to develop a persona. As mentioned before, a person is created from combined data based on interviews and other research methods. The most important factors in a persona are generally not demographic information like age, political interests, or what type of car a person drives. Though some of these types of factors can be used to give the persona some human characteristics and personality. They key is to use information that is important to portraying the persona. They type of driving habits a person has, would not be important for a persona representing a user of medical software. But that information would be important for an app that tracks a person’s mileage and gas consumption when they drive.
Generally personas consist of:
The user’s name
Age or level of expertise
Title or some occupational reference
And perhaps a quote that summarizes the user’s goal, feeling or general outlook about the product or process
There are many advantages of using personas. Some of these include:
They simply provide a “face” for the user story.
Provide an emotional link to the person so you can build empathy with that user.
Promotes surfacing a real goal, pain points and motivations rather than just making them up as the discussion evolves.
When you need to play out a use case, the persona is a true character to use as reference, along with all of her data and behaviors.
Keeps the “facts” of the user more concrete. If it’s recorded on paper, traits of the user are less likely to morph and change.
Gives the team a focal point of on person to discuss rather than a theory about a group of users. You can specifically reference how “Sally the Student” would use the product so you make sure you are meeting her goals.
To focus the design on a “real” user rather than what we “think” is the best solution.
Now that you have a better understanding of personas, I hope that you will use them on your next project. If you are using personas now, please share your process of how you develop them and how you use them with the team.
There are many people trying to figure out how to make the jump in to the UX field. I too, not too long ago, was trying to transition (or to use the buzz word “pivot”) in to the field of UX. Thankfully, I made the transition and I am now a UI Designer. However, it took a lot of hard work, networking, self discipline, education and pushing myself to learn more about UX every day.
One way I went about getting experience about UX was to learn as much as I could about the deliverables in the UX field. I would hear a term like “personas” or “wireframes” and decide that I was not only going to learn as much as I could about these topics, but I was also going to put it in to practice.
Here’s an example. Say you are a web designer for a flower shop. Sure, you could just design the website per the shop owner’s request. But why not take it a step further? Why not do a bit of discovery and research before starting the design project? You could interview the owners and customers to find out what the business goals and customer goals are. You could do a bit of ethnographic research by observing people shopping for flowers or employees performing a transaction. Sketch our a few concepts before diving in to the code.
If you are trying to get experience in UX, and want to build up your portfolio, use some or many of these methods to show that you are so much more than a visual designer or developer. Show off your analytical skills and how they are applicable to a career in UX.
Here is a brief list of UX deliverables to get you started:
Information Architecture (Taxonomy)
Examine Business Goals
Examine Customer Goals
Site Map and Architecture
Whiteboard and Sticky Notes
Use Case Scenario
Persona Empathy Map
Cognitive Walk Through
Now take all of these deliverables and practice creating them. Then, use the most important UX skill of all: Tell us Your Story.
Jennifer Blatz explores the world of UX through words and imagery