Personas: They actually do work
See how a persona can influence a design thinking approach
Want to create kick-ass product experiences? Start with a kick-ass persona.
Personas are research artifacts that capture the behaviors, attitudes, education, use of technology, workflow and the like of a particular user group. Primarily, personas are meant to help us understand our users a little bit better.
Without a doubt, personas are essential tools in a design professional’s toolkit, but they seemed to be losing their appeal as quality sources for inspiration and building empathy.
I can think of two reasons why personas are underrated: people don’t use them correctly and people don’t develop them. Personas might be tossed in at the last minute or just abandoned, not reaching any level of depth and nuance. I asked Lead Design Researcher for IBM Cognitive Systems Margie Villanueva to give her take on personas:
The main issue is that people have gotten lazy about creating them and so they lose their strength. I see so many crappy personas out there that aren’t based on real research. I think that’s the real problem.
If we keep in mind the main purpose of personas and actively develop, maintain, and use them, not only do they deepen our understanding of users, they can empower designers/researchers to become better creative thinkers, problem solvers, and user allies. When used appropriately, we are put on the path to getting the right design and getting the design right.
The best example in my experience of using personas deliberately was at the industry hire bootcamp IBM hosted last spring.
Bootcamp: A Case study
At this bootcamp, twenty new industry hires met in the San Francisco office eager to learn about IBM’s design thinking toolkit. We were given the task to improve the user experience of Cognos Anlaytics, a data analysis tool owned by the Business Analytics (BA)team. Over the next three days, we worked on empathy maps, need statements, as-is/to-be scenarios, and prioritization exercises to tackle this broad design challenge.
The topic was purposely broad and I was left wondering “How was I going to contribute?” I had never heard of Cognos Analytics until then. We weren’t completely left in the dark. Luckily, we could consult with members of the BA team if we had questions and we had some kick-ass personas to start with.
The BA team provided us with four proto personas they used for Cognos. Each persona included details about their knowledge type, programming and data visualization skills, tasks, background, pain points, and tools used. These included: Ricki, a Sales Manager, Sam, a Senior Financial Analyst, Claire, the Chief Data Officer, and Lucas, a Data Scientist.
They split us into four teams and gave each team a persona. My teammates, Ana Manrique, Mike Sun, Marc-James Abi-Jaoude, and I were Team Lucas.
Who was Lucas?
Based on Lucas’ profile, we concluded that he was a 20-something year old with a masters in data science who loved to create data models but lamented the fact he couldn’t help with generating insights. He neither had the time or the opportunity. We also made an assumption that he got grumpy whenever he was overwhelmed with requests from Ricki and Sam.
Our process
First we did an empathy map with our persona. We dissected every piece of information that was given to us, even his picture, to draw conclusions about his feelings, values, behaviors and potential things he’d say. This helped us expand his profile further.
From there, Lucas was our launching point and frame of reference for the rest of the design activities. We did a needs statements exercise where we listed out as many needs and painpoints as we could. Next we created As-is/To-be scenarios to highlight Lucas’ current and ideal workflows.
What would Lucas do? How would he feel about this? Ultimately we wanted to know what could help Lucas be a hero at work.The ideas starting flowing like water. In typical design thinking fashion, we had tons of post-it notes on every vertical surface in reach— to the windowwwwww to the walllllll. By the end of the day, we had plenty ideas, which we prioritized to a few.
As a result of using Lucas throughout our activities, we came up with a compelling story around 3 key themes — playing, collaborating, and sharing.
- Playing: He likes to get hands-on with a data set to see what he can find.
- Collaborating: He wants to collaborate with other stakeholders.
- Sharing: He wants the sharing channels to be fluid and open.
So how could we improve and/or design the play, collaborate, and share experiences for Cognos Analytics in a way that Lucas would approve?
Our solution
My team came up with an experience that would be appealing to a curious, ready-to-go data scientist like Lucas. For example, Lucas could demo the product first before setting up an account. Lucas could select a profile that matched his role, which would then take him to a sandbox of relevant things (data tools and features) to demo. For sharing and collaborating, we came up with a way to integrate Slack and include an add/invite people or teams feature in the product. We felt these could help Lucas thrive at his job and improve his relationships with other stakeholders.
This didn’t just happen for us, other teams were equally productive with their personas in creating new experiences for Cognos.
The playback to the group at the end of each exercise was one of the most memorable parts of the day. People told vivid, often hilarious stories of how their persona went from being frustrated to happy achieving workers. It was amazing seeing everyone contributed in some meaningful way even though, for most of us, it was our first time being exposed to the product.
Interestingly, all of the personas were still in a proto state; they were not fully vetted. Imagine if Lucas was fully fleshed out. For one, we would’ve known his goals, which would’ve given us a sense of what he hoped to accomplish at work and beliefs about the impact of his work. Secondly, we would’ve known details about his relationship with Ricki or Sam and how it related to receiving requests and sharing reports. Certainly, such vetted info would’ve given us a better understanding of high level priorities and the deep-seated issues that irk data scientists. We would’ve been able to create a much richer product experience that encompassed multiple aspects of his workflow.
Conclusion
The BA team did a good job getting us started with solid proto personas. Though these personas weren’t perfect or complete, they weren’t sidelined or used as an after thought; they were foregrounded in our conversations and embedded throughout all of the design thinking exercises. Used this way, they provided immense value in the form of new perspectives and creative human-centered concepts.
Proto personas can only take you so far. Though we used reasoning and imagination to fill in the gaps, a fully vetted persona, in which we had data from talking with users, would’ve let us design with a little less uncertainty.
In a follow-up article, I’ll talk about how you can take your persona from proto to validated, creating a rich, kick-ass persona along the way.
Shout out to Sasha Kerbel, Esther Kim, Joy Jean, and Ron Poznansky for y’alls help :)
Roosevelt T. Faulkner is a Design Researcher at IBM based in Austin, Texas. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
