If you’re creating user personas, How-To articles often tell you that you only need two or three personas at most. That’s fine for most web-design projects. However, if you are working on an enterprise-wide system that has modules for different types of professionals who each perform distinct and substantial tasks, then you will have a larger number of user profiles.
Imagine a product suite the size of Microsoft® Office that actually consists of very different pieces: Excel, Word, Access, PowerPoint, and more. Usually, the only persona who is involved with every module of a suite is someone like Ivan the IT administrator, whose tasks are very different from most users.
That may sound obvious, but I really struggled for a while with the notion that I was “doing it wrong” because I couldn’t squeeze the user roles and needs into a mere three user personas—or five, or seven, for that matter. When you have a dozen user personas, it’s challenging to keep them all apart, but most teams only need a few at a time. Likely, the only people who need to know all the user personas are on the user-experience and product-management teams. And the alternative—to have a catch-all user persona whose role is to “use the software”—is of no help at all.
If, by chance, you find you need many user personas, then beware once the projects wrap up and the teams turn to their next projects. They may have incorrectly learned to begin a project by creating user personas (“…well, that’s what we did last time…!”) instead of re-using and tweaking the existing user personas. [Not everyone agrees with re-use; see the comments.]
User personas will influence your product design and affect how people throughout Development and Marketing think, strategically and tactically, about their work. So you need to get the user personas right. Getting a series of user personas reviewed—not rubber-stamped but mindfully critiqued—is a challenge; nobody ever makes time to do it well. Here’s my solution: after you research users and then write your draft user personas, review them together with some subject-matter experts, Marketing staff, and developers, in a barn-raising exercise. Pack them all into one afternoon for the initial review. Then meet the first Friday of the month until you have agreement about each user persona. During one such meeting, one of my subject-matter experts said to another: “Oh, this user persona is just like [a customer named H—]!” The user persona was so on-target that that it reminded her of someone I had never met or researched. That was a nice way to learn that I got it right.
For detailed How-To advice on developing user personas, try these readings:
- User research for personas and other audience models, by Steve Baty at UXMatters, which introduces user personas and gives advice on creating them.
- Bringing the everyday life of people into design, a PhD thesis by Froukje Sleeswijk Visser at TU Delft. You can skip most of the 250-pages that describe the author’s user-persona journey, and zero in on Chapters 6 and 7, which offer a framework and guidelines.
@jamie:
I think it’s the wrong tool for long-term continuity. For that, I’d use experience visions, which use personas for development, but focus more on the overall experience and less on the attributes of the users.
Long-term (say 5 or so years), your target audiences are going to shift and shimmy, but your vision of the experience should stay relatively the same.
Jared
Jerome and Jared–
What about continuity in a product, application, or site? Wouldn’t “detailed and deep” personas focused on short-term functionality specs contribute to the risk of disjointed function-itis? Or are you suggesting that necessarily there is a long-term design and development strategy established at the outset, a strategy chunked into phases (thus each phase warrants a set of detailed and deep personas)?
Cheers,
Jamie
Actually, we have a bunch of UX-of-1 clients who are doing just this.
The fact is that you’re likely spreading yourself too thin by trying to create all-encompassing personas for the entire team. What if, instead, you picked 2 or 3 key pieces of functionality and built the key personas just for those elements?
By going detailed and deep, our research says that you’re more likely to get the quality hits you need to have the impact you’re shooting for.
Jared
What a luxury to be able to develop user personas for each project. My advice, above, was based on my experience in a company where I was a lone practitioner, and the ratio of Developers to UX-and-Usability staff was 50:1, with the bulk of customers are in remote (non-urban) locations on all five continents (poor Internet connections). I would so love to work on a UX/IxD/Usability team of n, where n>1 . :)
Hi Jerome,
Thanks for sharing your experience.
Interestingly, our research has shown that the most successful teams don’t try and create permanent personas that they’ll reuse for every change to the entire product line.
Instead, they create personas for the key functionality they are developing over the next few months. When you narrow the persona scope to specific functionality, you only need 3 to 7 to do the job well. Once the functionality is done, they put the old personas into cold storage and develop new ones for the next project.
We talked about this in depth in our Virtual Seminar, Building Robust Personas in 30 Days or Less.
You can hear about what we discussed in the follow-up Q&A session podcast (free).
Hope that helps,
Jared
I found this gem in the PhD thesis by Froukje Sleeswijk Visser at TU Delft: “The fundamental perspective of context mapping is that every user is an expert in his experience domain(italics mine).”
I couldn’t have said it better.
Jerome,
Thanks for sharing!
I read somewhere that there are teams within Microsoft that keep posters of their personas on the wall in their workplace to remind them who their work is for.
Best regards,
Tom