Personas with personality

Personas are stand-ins for real people – useful abstractions that can be as specific or general as you need them to be. That kind of abstraction may seem unnecessary, but consider the alternatives for thinking about your users. Get too specific, and you can get caught up in paying attention to too many people. That takes a lot of time and can make prioritization challenging. Get too general, and you may fall into the trap of either designing for everyone (an inherent fallacy) or designing for an ideal (eloquently described recently as “designer-focused design“).

I have created personas for different kinds of projects, and have found the most useful ones to be archetypes as they are lightweight (easier to use) and behavior-based (easily map to roles). They are particularly useful for systems whose users have intrinsically different roles or motivations, especially when they interact with each other.

The good, the bad, and the ugly

Online communities are a prime example of different motivations. These communities simply do not exist without users interacting with one another, and the range of emotion and behavior that people exhibit on the internet can go far beyond what they would do in person. The system can be designed to include checks and balances so that the people within it will be encouraged towards good contributions and will correct for bad behavior.

I noticed this balance with LinkedIn’s Groups, and this became a critical component in designing ways to help groups moderate for higher-quality content. To tackle this, I created a set of lightweight personas to capture the different behaviors I’d observed. Each had just enough information to make them identifiable for a particular motivation: a name, a photo, and three or four brief bullet points about why they did what they did.

Much of the nuance in the moderation tools we built came from thinking about the differences between the snarky-but-occasionally insightful trolls, the clueless-but-hopeful networkers, and the true indiscriminate spammers. The personas continued to be useful as we sorted out the best way to introduce publicly-visible content in open groups while being mindful of privacy and data considerations. These personas were not only present in the designs – we’d periodically stumble upon examples of these personas “in the wild” as we used groups ourselves.

Mutually beneficial relationships

One interesting and unexpected side effect of creating these personas once was that they appeared in other contexts. When I transitioned to the Recruiter product, I realized that some of the personas that could be problematic in Groups came up in a much more positive light in this context. People on both sides of hiring use Groups as one of many ways to find each other, sometimes to the consternation of fellow group members just looking to have quality conversations. Knowing their motivations, I now had an opportunity to offer more suitable alternatives for them to find each other.

The Recruiter product was already a natural fit for personas for a few reasons. One: my designs often represented flows that moved between people. Using personas helped keep the context straight. Two: having a group of personas helped me represent the dynamics that occur within teams of recruiters. Three: personas were an effective way to keep particular roles and relationships straight since it was an enterprise-level product that included sales, training, and administration.

When to get real

I did find that personas weren’t quite as useful for designing for Photoshop and Illustrator since those are designed around the activities of an individual. While a Photoshop or Illustrator user does collaborate and share with others, the act of doing the work itself is largely a solo process. There were many different types of people using these products, but how could I prioritize one person’s type of work over another?

In this case, everything I needed could be served by a more direct approach. For prioritization and the big picture, I relied on market segmentation. For understanding the knowledge and mindset of users, I relied on real people. I went on site visits whenever possible, and worked closely with an alpha team that represented many different types of users. This made me familiar with many different people and their motivations, and I could always draw upon the many stories I heard when thinking about the individual experience.

Overall, personas can support that delicate balance of designing for complex interactions between people. They can be overkill for more individualistic projects, but when it comes to designing multi-user systems, a little personality can go a long way.