An Alternative to User Personas
I’m not sold on the value of user personas, at least not the way they’re commonly used. Don’t get me wrong, personas can be useful in theory, but in practice the personas I’ve seen in the wild have been unexamined implementations of generic templates. So many templates. These dressed-up mad libs may serve as a starting point, but for personas to be really useful requires more critical thought and less fill-in-the-blank.
Index on Boundaries, Not Just Averages
In engineering it is best practice to design not only to the desired outcome, but also in consideration of boundary conditions. Civil engineers talk about factors of safety, mechanical engineers talk about tolerances, software engineers talk about edge cases, and they’re all talking about boundary constraints.
User personas as used by product designers are presented as idealized rough averages of a set of user traits and behaviors. The “average” user is no doubt important, but equally if not more important are the boundary personas — the users at the extreme of your demographic.
Over-indexing on the average can lead to under-accounting for boundary behaviors.
Indexing on boundary conditions nearer the edge of your persona distribution accounts for a much wider slice of user behaviors.
As a concrete example, consider the following distribution: 70% of your users are aged 20 to 55, 15% of your users are aged 56 to 60, and 15% of your users are aged 61+. Your median average user is age 42. There are interaction design choices you will likely want to make in concession to the 30% of your users aged 56+ that would be under weighted if you indexed your design sensibilities on the idealized average 42-year old persona.
Generally speaking, younger users afford a bolder approach to design and UX, but simpler and more traditionally intuitive design is more appropriate for older demographics. You’re unlikely to alienate younger users with simpler design, but highly likely to alienate older users with design that is too esoteric. There’s a reason SaaS tools aren’t made to feel like Snapchat.
Signal Over Noise
The typical user persona goes into far more detail is than is actually useful; consider the following advice for describing a persona:
- You should include details about the user’s education, lifestyle, interests, values, goals, needs, limitations, desires, attitudes, and patterns of behaviour.
- Add a few fictional personal details to make the persona a realistic character.
- Give each of your personas a name.
- Create 1–2-pages of descriptions for each persona.
That’s a lot of information and most of it is noise. Before painting by numbers, slow down and ask: what actually matters to my specific context? Someone may use your dating app because the branding is aligned to their personality, but they use SaaS products because they solve a pain point or streamline a workflow in their job. There is no context in which all user attributes matter equally — focus on those that carry weight in your specific context.
In my experience building SaaS tools in real estate and government, the most important persona attributes are role and age.
B2B or B2G SaaS workflows are almost entirely determined by user roles. A buyer’s agent in residential real estate has very different workflows than a listing agent or transaction coordinator, just as a departmental general counsel in state government has daily workflows that diverge from those of a deputy commissioner or a regulation writer. In consumer-land, income often matters more than how it was earned. Your job description might be a factor in how many Tinder matches you get, but it probably isn’t a core product consideration.
Beyond roles and ages, persona attributes such as personality, name, gender, marital status, and favorite flavor of ice cream may be critically useful to your specific context, but you should make that determination — ”Is this trait valuable?” — before you spend time fleshing it out.
People > Personas
An alternative to fabricating user personas out of whole cloth that I’ve found far more informative and engaging is to use actual users as your archetypes. Instead of creating some fictional persona, why not find an active user who actually fits that description? More specifically, they need only match the description of the top 2–3 most impactful traits you’ve identified for your product area. Referring to real users removes guesswork through observation and conversation and holds more weight in the context of a conversation.
We make reference to real individual users all the time when making product and design decisions; imaginary friends just can’t compare — sorry, Tyler Durden.
Utility is Stage Dependent
A corollary to People > Personas is that the value of user personas is highly dependent on your stage as a product or company. A persona, an idealized average, is a valuable abstraction if you have enough users to have statistical significance. If you’re an early-stage startup, you will get 10x more out of customer interviews than you would from an equivalent time spent doing a persona exercise.
Get out and talk to your users!