Personas are great aren’t they? Everyone loves personas! (But ssssh! 🤫 don’t admit that very few teams use them to their potential.)

This isn’t a post about creating good personas – there’s a lot written about that that by more knowledgeable people than me. I’d highly recommend reading Indi Young’s writing on personas if you haven’t already.

This is a post about what’s missing from personas and part of why they can be hard to use with complex multi-user products … and what we can do to make them useful again.

Personas are archetypes of users: representative traits and behaviours of groups of users that inspire us to design product that works well for that group. Personas often get more useful as their scope is narrowed, they need to be specific enough to for us to imagine the world through the eyes of that user archetype. This is personas’ strength. But that specificifity comes at the cost of broader context – not a bad thing, it just is.

When your your product is targetting a large range of users the necessary specifity of personas starts to be a weakness. Either you need hundreds of personas (that you don’t have time to make and no one has time to use) or you have just a few that leave large gaps. Those gaps create vacuums in understanding that get filled with unresearched assumptions and generalities – often bolted on to the personas that do exist, diluting them beyond usefulness.

A map helps

A map of the personas landscape helps everyone see the gaps and differences that aren’t recorded in fully developed personas.

An simple example: When I worked at Thread – a utility asset management SaaS platform – a lot of our users were engineers in charge of maintaining the power line network. Inside Thread, “Engineer” was used pseudo-personas: “As an Engineer I want to…”. Some basic user research showed that ‘Engineer’ can be split into many different specialisms: Reliability engineers, Structural engineers, Electrical engineers etc. Each will have their own processes and needs for the data in our product.

That’s already more useful.

As well as varying in speciality, we knew that engineer users of our product spanned the many years of experience and seniority. From interns and juniors, to mid-career, team leads, and senior management. Each will have different needs and might have very different experiences of using the product. Interns often did a lot of data entry type work in our system, manager level engineers were more likely to be interested in high level risk analysis and reporting to regulators.

Now we have a reasonable map that unpacks the idea of Engineer, we could go into more detail but for us this was enough. It allowed us to name the different categories of engineer and speak about the variances and overlaps. Now when we spoke about ‘an engineer’ we had a shared understanding – a shared language – allowing us to be more precise as a team and organisation.

With a shared visual understanding of our engineer user landsacpe it gets easier talk about target personas, feature prioritiastion and roadmaps:

“Yes, that’s a great idea but it creates more value for structural engineers than reliability engineers and we aren’t targetting structural engineers in this release.”

“Reporting features aren’t on our roadmap for the next two releases so we are focusing on the needs of general engineers rather than management.”

And we can set out our product and design strategies more clearly: “We’ll start by targeting mid-career reliability engineers then… “

A map of the persona landscape allows everyone to see the totality of the user-space, and where our developed target persons sit, allowing the personas to deliver the meaning and insight they are meant to rather than be unwitting vessels for adjacent ideas that don’t have homes.

The map is not the personas

A map is not the territory, persona lanscape maps aren’t the personas. Each point on the map can have none, one or many associated personas. An example from Thread was linemen; linemen are the workmen who maintain electricity lines and poles. Linemen culture in the US is a whole thing in a way it isn’t on this side of the Atlantic (as far as I know), with all the differences and variety that entails. Different linemen had different attitudes to using drones for inspections; some linemen were very happy to use drones and work with professional pilots, others were unionised with a ‘no drones’ policy. Both occupied the same point on our persona landscape map but needed two distinct personas to model the different attitudes and behaviours.

A quick technique that makes personas better

Generally with user research and developing personas it’s the detail and quality that takes the time. (As it is with anything really…). Personas landscape maps don’t need detail and they don’t need to be perfect – the map’s job is to situate the detailed and developed personas so they can stand out and work harder – and this makes them quick.

If you have a complex user environment it’s nearly impossible to have 100% coverage of personas, but you can map the full persona landscape. The map defines helps define everything you target personas aren’t – adding essential context clarity – and allowing the personas to live up to their full potential.