UXers, we need to stop bashing ‘assumptions’ and start aligning them.
Rapid Personas, Alignment Personas, and the art of wrangling stakeholders.
TL;DR — Tamara’s Axiom: Any tool that helps to promote alignment around measurable goals, user needs, and priorities — even if that alignment is not based on data — is a good thing.
People building things bring a huge, invisible pile of assumptions about who their users are, what those people need, and how those needs should (and shouldn’t) be addressed by your company and / or project. These assumptions end up bashing into each other like icebergs clobbering each other deep under the ocean’s surface. Disagreements, passionate stances, and political undercurrents send brainstorms to the bottom of the ocean.
So, what’s the alternative? In the best possible scenario, data about users would be translated into some usable form (perhaps data-driven personas) and embraced by everyone. In reality, this doesn’t happen for all the familiar reasons (no time or money for data collection, data collected but no presented in a memorable or usable way, data presented in a memorable and usable way but ignored, etc.) This is why, even after co-authoring the Persona Lifecycle books, which focused on how to create data-driven personas, I’ve never done data-driven personas as a standalone project in my 25-year consulting career. Instead, I figure out how clients are already thinking about users and how to change their habits.
Persona purists insist that the only good personas are the ones created out of data. That’s certainly how Alan Cooper wrote about them, and he’s right: personas are an excellent way to communicate critical data about users. Arguably, personas created without data shouldn’t really be called “personas.” (You can read Cooper’s article Defending Personas for his feelings on seeing his invention co-opted and misused. And if you’re doing any persona work at all, read his Inmates are Running the Asylum book first.) I’ve already broken that rule, and, for me, “personas” are realistic descriptions of people that communicate “differences that make a difference” with respect to a product.
If the biggest problem we all faced in communicating with stakeholders and building empathy for our users was in fact lack of data, then data-driven personas would be the way to go.
Lack of data isn’t what gets in the way of great design and user-centrism, and presence of data doesn’t guarantee either. Sometimes data even makes things worse. There’s a bigger, or at least earlier, iceberg-esque problem that we have to conquer: invisible misalignment between key decision-makers. Everyone on the team is making dozens of decisions every day, and everyone needs to be aligned, top-to-bottom and side-to-side.
Key decision-makers are *always* misaligned.
It’s easy to assume that our bosses, grand-bosses, and great-grand-bosses are all “on the same page.” We think that they have spent a lot of time getting crystal-clear on the goals for projects, the metrics for success, the product/market fit and success potential for whatever you are working on, and certainly the people who are going to line up to buy and use your product.
The truth is, even if they were aligned at one point in time, the alignment doesn’t last. Every time two or more stakeholders have a meeting, something shifts and no one writes it down, and they certainly don’t continuously communicate changes in strategies or tactics to product teams.
Misalignment means that every word in a stakeholder’s vocabulary could have a definition that’s totally different than another stakeholder’s.
Guess which word stakeholders use a lot? “Users.”
If we assume all stakeholders have “users” in their minds, and that these “users” impact all the conversations about your product, then it matters (a lot) whether these “users” match. If they don’t, then arguments about what users need and want end up being won by the most powerful person in the room, and the definition of user tends to flex between meetings (or even between sentences).
It’s a given that these “users” aren’t realistic and reflect all sorts of biases, personal agendas, and imagined problems that can only be solved by this product.
Why align around assumptions if they’re guaranteed to be problematic?
Because in the real world, the alternative to alignment around assumptions isn’t alignment around data. It’s misalignment around assumptions.
My controversial hill-to-die-on: even if the assumptions everyone has about users are incorrect, surfacing and aligning assumptions is critically important. The danger of misalignment is far greater than the danger of designing based on assumptions (which means the danger is huge), just like designing for everyone is more dangerous than designing for the ‘wrong’ persona.
If you can’t see assumptions, you can’t kill them.
Assumptions inevitably reflect biased, non-diverse, and non-inclusive ideas about people. Aligning assumptions doesn’t solve any of these important problems. But aligning assumptions does make assumptions visible, and my argument is that making assumptions visible is a necessary first step if you want to change those assumptions in any way. That’s because data can disrupt assumptions you can see, but it’s bad at killing invisible assumptions.
My experience is that many teams, especially startups, become more user-aware during the alignment process with or without data, which improves their products. Many teams are so far away from thinking about how humans experience their products that creating and prioritizing personas like “Nell New Member” or “Ronnie Returning Subscriber” is game-changing. The existence of these personas, and many of their wants and needs with respect to the product, often don’t need to be validated by data. The common language they create are a huge part of their value.
Quick and easy ways to see assumptions: Dan Brown’s Rapid Personas and other fast, collaborative workshops
How do we get assumptions out on the table? Get everyone in a room talking. Better yet, use an activity that compels them to highlight their differences. Dan Brown’s Rapid Personas workshop is great because it forces everyone to codify and share their assumptions about users, with the added benefit of a pre-scripted vocabulary that’s based on data.
With the Rapid Personas play I’m trying to address a couple of challenges in the design process:
1. Encouraging stakeholders to keep specific user needs top-of-mind during a brainstorming exercise
2. Encouraging stakeholders to let go of their misconceptions about their users. — Dan Brown
In Brown’s Rapid Persona workshop, “participants construct one-sentence mad-lib-style personas by selecting a role, a need, and a challenge from a limited list of options.” Anyone who has heard me talk about creating measurable business goals for all projects will know I’m already a fan of Mad Libs formats.
Brown creates the choices for roles, needs, and challenges in advance, and ensures that each is independent of each other. He bases the choices on user research he’s already completed. Participants end up considering all the combinations of roles, needs, and challenges as they create their rapid personas. Brown provides detailed instructions for this exercise in his article, so I won’t repeat those here.
If you are interested in Rapid Personas, you can also read about Proto Personas workshops, which use a different, slightly longer process to create non-data-driven personas.
One step further: Alignment Personas
There’s a reason I compare stakeholder assumptions to icebergs: they’re very deep and very difficult to manage. I think everyone should try Rapid Personas at the start of a project and certainly before a brainstorm. I also think that there are some issues that Rapid Personas can’t solve (and I’m pretty sure Brown would be the first to vigorously agree).
I created Alignment Personas (previously called Ad Hoc Personas) over the past 15 years to help senior decision-makers create more user-centered product strategies. Where Rapid Personas are tactical design tools, Alignment Personas are strategic. They are the result of workshop-style meetings with project leaders that can take several weeks to several months to complete. The process makes assumptions visible and helps stakeholders align themselves around a collaborative-created set of needs-based personas. We don’t just identify assumptions — we work through them. Alignment Personas are quicker than traditional, data-driven personas but they still take significant time and commitment. That’s why I love the idea of starting with Rapid Personas, seeing if they help, and then building an appetite for the clarity Alignment Personas deliver.
Alignment Personas are the result, but the real work (and magic) are in the process. I guide decision-makers through well-organized and carefully-wrangled conversations. They think they are creating Alignment Personas, and they are. They just don’t realize how much emphasis is on the “alignment” part.
Measurable business goals for the project (in Mad Libs format!). “Increase/decrease [important metric] by [actual number] in [defined time period].” This is way harder than it seems.
Identifying current language used to describe “users” (in the organization and in the brains of key stakeholders). This part is easy.
Identifying “I want…” and “I need…” statements to group “users.”
Extracting candidate personas.
Prioritizing the personas based on business goals, so you get to the magical sentence: “Our goal is/are X. If we don’t make <persona(s)> ridiculously happy, we’ll never meet our goal.”
Identifying data-gathering requirements. Alignment personas can (and should) be treated as a set of hypotheses to validate or invalidate — this is how and when data can be used to restructure thinking.
If you think there are issues in your organization or project that are too big to be solved by Rapid Personas, Alignment Personas could be your next step. Deep stakeholder alignment depends on surfacing a lot more of the iceberg and completely transforming the language everyone uses to talk about goals and users. The meetings address some of the politics of leadership teams and help experience professionals understand the ‘language of business’ to improve cross-team collaboration.
No matter which tool you choose, the goal is the same: get those assumptions out into the light of day. Then, and only then, can you align, or better yet, re-shape them based on data.
The next challenge: remembering that alignment isn’t an event, it’s a discipline.
Tamara Adlin has been in the UX field for 25 years and co-authored the Persona Lifecycle books. She was at Amazon from 2002-2005 has been consulting ever since. She has honed the delicate art of aligning stakeholders without bloodshed. Contact her for alignment persona and strategy workshops, UX diagnosis and repair, any and every question about persona projects, and leadership and team coaching.
Thanks to Dan Brown for writing everything he writes, inviting me on his podcast, awesome edits to this very article, and excellence in the art of emojis.
And also thanks to Katie Geminder who has been thinking about this stuff with me for decades.
