Understanding your users is critical to developing good products. A “complete” understanding is sometimes required, and always comes at a cost. A contextualized understanding is valuable but less so, and costly but less so. Even a shallow understanding of your users provides value by preventing some dysfunctional behaviors. You do not always need to develop personas before developing products.
Before The UCD Mob Burns Down My Blog
As agile methodologies developed and became mainstream, the tension between big upfront design and emergent design has been a source of many agree to disagree discussions. I am not abandoning UCD (user-centered-design) principles by stating that there are times when you should not develop (full) personas. I’m contextualizing the value of personas relative to other sources of value in the product development process.
TL;DR – combine Reinertsen’s cost of delay framing of decisions, with Godin’s hyper-segmentation of markets, with Adzic’s impact mapping, and Hubbard’s measure only when the cost of being wrong justifies it philosophy; with the agile process – particularly at scale, and in an organization where many of these practices are new. Your conclusion – do limited persona work up front, some additional work at the last responsible moment, and focused investment only when it matters. Now to write it out longer…
Potential Value from Personas
To defend an argument against developing personas universally, I need to unpack the sources of value from having personas, to optimize the value-realization from understanding our users.
Most fundamentally, and most simply, [tweetherder]identifying the people for whom you are building helps you make better decisions about what you are doing[/tweetherder]. Rich Mironov elegantly climbs on a soapbox after what I assume was a series of frustrating conversations with people who should already know better, talking about “users” without clarifying who they are.
Even doing nothing more than identifying the users for whom you’re developing products – and sharing that deep context with the rest of your team – provides value by preventing two well understood anti-patterns.
Firstly, as Rich defines, you assist in the “you are not your user” pattern. Set aside the tiny fraction of startups who are scratching their own itch – survivorship bias explains why many people fixate on this approach. It works if…, but it is a large “if.”
Secondly, you avoid the elastic-user problem – designing part of your solution (or a given flow) for one user, and part for another. This can easily happen when you have different teams responsible for developing different capabilities. You might design your key user flows for marginally computer literate users, yet have an interaction model for adding two-factor authentication which only Brian Krebs could navigate. Your product is broken for both user groups, as the neophyte gets lost in one place and the expert becomes disgusted with the other.
Taking this one minimal step further to identify the different groups of similar users for whom you might develop your product gives you a way to frame your overall market and within which to make prioritization decisions and develop your product strategy.
Get Smarter as Late as Possible
Dave Gray recently updated his empathy map canvas, which helps you articulate an understanding of a particular user, deeply in a narrow context (of addressing a particular goal). This is exceptionally useful when using an iterative and incremental, outcome-driven approach to building your product.
[tweetherder]Being outcome-driven means you are focusing on the realization of a particular benefit[/tweetherder] and building whatever is required to realize the benefit. This is not-so-subtly different from focusing on building some feature because you believe someone will use it to get value.
The empathy map provides sufficient clarity to understand the objective value – and subjective value – to a group of users of solving a shared problem, while also providing some insights to inform otherwise arbitrary design and implementation decisions.
At the last responsible moment, you invest incrementally to understand the contextually-relevant (to the desired outcome) user objectives and perspectives. This additional insight allows you to avoid building something users do not value (enough), and de-risks your plan by increasing the likelihood of suitable design approaches given the improved understanding of your users.
Gain Deep Insight When Warranted
A persona is built on extensive research. Anything not built on extensive research is not really a persona (proto-persona is the term I’ve heard and used – although I’ve also heard “cardboard cutout of a person” when described by a user researcher).
This research comes at a cost in three key dimensions
- You delay decisions (which require user insight) until after the research is complete – this is a cost of delay for whatever you’re building.
- You objectively spend money doing the research – easiest to imagine when contracting to get outside help.
- You incur an opportunity cost in allocating your team to doing this research when they could be doing other, also valuable, work.
How to Measure Anything by Douglas Hubbard is a fantastic book, and one of the most powerful messages in the book is that measurement comes at a cost – so you should only measure (or more specifically, improve your ability to measure) when the cost and risk of being wrong justify the investment.
When you don’t have any sort of understanding about your users, the risk and cost of being wrong about them is very high. In a big-upfront-design world, you would invest in developing personas to de-risk your product investments. Without this investment, you may fail to understand your users or their goals – you may not even design for a single user, or worse yet, design for non-users.
When you take the approach of progressively elaborating users, your choice is not an all-or-nothing wager on the value of a fully research-backed persona. You can be pragmatic
Progressive Elaboration and Personas
As the diagram above shows, a researched persona provides comprehensive deep understanding about your users and their goals. This comes at a cost, and there are times when this is appropriate.
An empathy map does not provide broad insights into a person’s goals in general – however it does allow you to organize your existing contextually relevant insights about the behaviors and environment for a particular group of users in pursuit of a particular goal. This is literally exactly what you need to know, to make decisions for what you are building right now.
A proto-persona may even use the same format or template as a persona, but it is not built on (current) research. The proto-persona captures what your organization collectively already thinks it knows about users. It provides benefits in focus, while bringing a lot of hypothesis and assumption-risk into your product plan.
The empathy map also carries assumption-risk, although the thoughtfulness required to assemble the information often concurrently eliminates or highlights the hypotheses most likely to be a problem.
Conclusion – An Approach to Persona Development
Transformation of large organizations to an agile approach in creating products makes an environment within which many ideas are competing for attention – as people are learning how to do their jobs, and how to work with others, differently. As the organization itself learns how to deliver product differently. It forces a pragmatic approach (which is objectively beneficial, regardless) to new concepts in general, and user-centered design in particular.
Developing proto-personas for all of the user groups in your defined market is a very high ROI “shallow analysis” establishing context for all future decisions while enabling teams to avoid the common anti-patterns of not being user-centric in their approach.
Developing empathy-maps, as needed, creates an incrementally and iteratively better understanding of your users, at the last responsible moment. You avoid waste by not investing to gain insights you’ll never apply. You avoid the cost of delaying decisions which don’t warrant delay.
Developing “real” personas whenever your organization pragmatically decides to reduce the risk of product failure associated with a lack of user insight.
2 thoughts on “Progressively Elaborated Users”