Create Shallow Personas

Design personas to help you move on to more interesting work.

Creating personas as an exercise can be super useful to introduce user-centered design concepts to teams or organizations where those concepts are new, but I don’t think they’re the most useful tools when actually designing the service.

This is because the services or products we design well are puzzled together around solutions users need rather than who users are.

But often when experience design is new to a team we jump on the persona bandwagon hard because satisfiscing Googlers see “personas” and “card sorting” at the top of the search algorithm, and popular low-hanging fruit like that’s just asking to be picked.

Personas are useful, but when resources are tight we get more bang for our buck creating shallow ones. There is a breaking point when time and effort invested in creating research-rich full-bleed personas is more than their practical value as a tool for designing or refining a service.

Rather, our time is better spent identifying shallow personas who broadly represent our userbase, and use the resources we might have exhausted going deep to perform jobs-to-be-done style interviews with actual people within those groups.

Why? While I think persona-making has value to train organizational empathy, personas don’t tend to generate loads of actionable insight. They can help refine tone and identify pain points resulting form prior decisions made without that empathy, but this is the stuff of course correction rather than course direction.

The key word here is “actionable.” There are a-ha moments unique to deep personas, but in general these rich personas morph into slide decks or are taped-up on the wall collecting dust.

Imagine instead we come together and draft personas that help us identify our core user groups, which we use to identify and recruit actual users to interview. We interview not to seek our users’ opinions but to help us identify the jobs they need done.

These jobs and journeys translate easily to service blueprints, with which we acutely identify usability problems to specific touchpoints, opportunities that map to a to-do list. Our first step in improving usability is to reduce the complexity of a touchpoint to zero. Actionable.

What’s more, when we start thinking about the services we provide as solutions to jobs users need done, we learn to think about our services as means to an end rather than fundamental truths about who we are as a team, or a company, or an organization. If, for instance, one of the many jobs a library patron needs done is to find escape from the rigamarole, the answer is just as much cosplay workshops as it is a good book.

It is with this frame of mind that we are able to think orthogonally when it is time to create something new.

Where I work, we have teams of journalists who publish daily newsletters (you should subscribe if you’re in Miami, Seattle, Portland, or Orlando). We spend a lot of time thinking about content and refining our publishing tools, the internal services our local teams use to do amazing work.

Sometimes, we muse about identity: are we a tech company that makes newsletters or are we a news organization that makes technology?

What is the answer if we approach this question with jobs-to-be-done thinking? Both and neither.

Our mission is to connect curious locals to their communities. That we publish newsletters at all is a means to an end for making locals feel connected to their cities. Newsletters are one of the many things we do, but it’s not who we are. We’re connectors.

If instead we were just a news organization, when trying to figure out whatever it is we do next, our choices would be limited to something news-y.

However, we connect curious locals to their communities. This means that we can create all sorts of services that are orthogonal to news to serve this job. We could get into the local event business, or create a local social network, or — woof — a dating app. I’m riffing, but you know.

The idea is that what-we-do-next is divorced from the notions of who we are and who we have been, but purely dictated by the demonstrable jobs our users need done . Not, you’ll notice, who are users are.