Effective personas — a comedy
To build all-around empathy for the end-user, craft different persona libraries for different audiences.
Personas are getting increasingly more attention as an essential tool in using human-centered design to drive better business outcomes. Work by Forrester Research has repeatedly shown that effective use of personas during product development exponentially increases revenue. Creating your own library of personas takes some effort but isn’t difficult. Snazzy templates abound on UX resource sites to complete with your own relevant and specific data. As long as these personas are based upon the words and actions of actual users and not invented by anyone inside the company (no matter how much they claim to “know their audience”) they can prove to be an effective tool in better focusing design efforts.
But does “based on user data” go far enough to making personas useful?
After conducting several rounds of user tests and shadowing end users I poured back over transcripts, identifying roles, demographics, responsibilities, motivations, and frustrations. I crafted a persona library that built a picture of end-users based on roles, demographics, and user quotations. Product management found this library very helpful in creating a picture of our customers.
The development teams, presented with this same library, rolled their eyes and said “Oh no! Not personas again!” This was the voice of frustration! Personas had completely failed to build empathy for the end-user within the development teams that would actually be building the product.
What went wrong?
What exactly is a “persona” (in human language)?
Persona: an individual’s social facade or front that especially in the analytic psychology of C. G. Jung reflects the role in life the individual is playing. (Merriam-Webster definition) In Latin, it referred to a character mask that a theater actor would wear. In UX, user personas allow us to act out scenarios to solve design problems.
It’s common, I think, to see to a template including a face, demographics, a list of responsibilities, and say ‘this is what a persona is…all of this kind of information about a fictional character’. Remember, the word means “mask”. We all put on different masks many times a day. In the morning, that mask may be “super mom” who shepherds children off to school and makes sure no one forgets their lunch. At work that same person can become “leader”, then “teammate”, or even “court jester” interchangeably depending upon the situation. She dons different masks, different personas, to navigate changing scenery in the theater of life.
Management and Development are not watching the same play
Both of these audiences want to see the character that is our user come to the same conclusion that is buying and successfully using our product. One audience wants to watch a comedy. The other only likes documentaries.
The personas I originally created were used to great effect when speaking to management, sales, and support teams. These parties could understand who that user was based upon the persona I constructed. The information they prioritize about users was front and center: who are they, their job title, age, experience level, and what people in that role said during user research. Management understood that narrative and loved these characters. These personas were readily incorporated into their work and presentations.
These personas failed to build a picture of the user’s character which made them directly pertinent to developers’ thought and work processes. Development teams need to hear the message of user empathy played out by an entirely different type of narrative. You would not try to force the same solution onto two external users, why do that internally?
Enter stage left: the development persona library
I went back to my user feedback and identified characteristics users embodied as they worked with the product, regardless of role or demographics. Re-collecting user quotes in this way, a new cast of characters came into view. Instead of “Case Manager Julie” we had “Frustrated Frank”, “Not-tech-savvy Nora”, “Empathetic Emily”, etc.
Each had identifiable goals, frustrations, and a collection of quotes pulled from user research that embodied this character. I deliberately used alliterative names so they would stick in memory better and be better shorthand for the characteristics to consider during development.
Putting the new characters into action
My ultimate task is to constantly stand up for these characters and bring them into the design conversation. Having the sets of characteristics and user quotes framed with an appropriate name has made pulling these sets of concerns into any discussion or user story much easier.
Would “Nora” understand this feature? Would she know to hover here or click there? Will this help Emily or will it add clicks and slow her down as she tries to do patient care? Will Frank go through all these steps? These personas built a relatable story of the end-user and were an effective shorthand for people’s specific concerns.
Often I find myself presenting data from user testing to developers and colliding with a mindset of “that’s just stuff the designer is saying.” I consistently need to build empathy for the end-user so that usability directions are not viewed as “stuff that gets in the way” of product development but rather as “how we can be more effective”.
Development personas, with their alliterative names and copious quotes, brought real users into each discussion. They brought usability out of the theoretical realm into something concrete that built real empathy.
Personas are one of many gateways for getting the words of the user in front of the team that is building the product so that users’ concerns are kept front and center during feature development. Building both work-role-related and characteristics-based pictures of end-users gave the entire team information they need to move the ball downfield toward greater usability and product adoption.
