Persona management when there a vast array of different persona types

Hi all,
I’m working on a project that has a wide range of different personas, and within each persona, there is an even wider range of persona subsets. Take this one – “Litigant”, who could really be almost anyone.
image
Since their pain points and motivations for using the service will be quite different, I’m wondering if it’s worth drilling down further and creating a more detailed persona map. How do you manage such a wide range of personas without rewriting Tolstoy’s War and Peace?

PS yes those bullet points are terrible – no one can style a bullet point to save their life these days

Hi,

Keep in mind that I specialize in community management, not UX, but I’m always happy to give my opinions. :wink:

When building an online community, it is important to start small and grow from there. If you’re trying to be everything to everyone, a community will fail.

I would suggest that you not create all the possible personas. Pick the ones that seem the most valuable and go from there. See how many categories you can combine before you get granular.

Good luck!

2 Likes

I recently worked with user research and conceptual service design for a major university website. In the end we had 17 personas and 105 user stories/business problems spread over a 70 page document.

The user groups can be handled individually, you do not necessarily need to figure out how all personas relate to each other. It might even be better to consider each persona as a clean slate and see which attributes or problems they inherit from other personas. Try to define the business problem for a persona against the service and not against other personas.

It might seem like a lot of work but this is what we do. We document.

The bigger challenge will probably be to get the stakeholder or client to understand that the personas cannot all be catered to in the same capacity. You need focus. You can make clear entry points and distinct sections for divergent personas in the information architecture but regardless, some users will not find this service delightful because it will be designed primarily for another type of user. Make sure that you and/or your stakeholder representative has the mandate and buy-in to make the tough decisions on who gets prioritised and the strategic documentation to back up those decisions.

Manage expectations and be the bad guy. The entire library department of said university hates me because I wouldn’t put their opening hours on the front page but since I can see which user scenarios this information relates to and how this in turn relates to the business goals of the client, and have the documentation to support this, I can comfortably say no.

One of my axioms that I picked up somewhere is that a service that tries to satisfy everyone’s needs equally is mediocre by definition. Everyone is satisfied, no one is delighted.

1 Like

That’s sound advice, I think there has been a lot of work around prioritising personas, I just need to dig through the mountain of documentation :slight_smile:

1 Like

Yep. Thats the other thing we do. We read.

It occurs to me that the most obvious first differentiation of litigant personas here is “defendant” and “plaintiff”. From there perhaps you could look at it from a “jobs to be done” perspective, i.e. the plaintiff is seeking remuneration, or recovery of goods, custody of a child, etc. Is that helpful?

1 Like