UXers, we need to stop bashing 'assumptions' and start aligning them
Rapid Personas, Alignment Personas, and the art of wrangling stakeholders.
Assumption icebergs exist, whether you can see them (or believe in them) or not. We all assume data can dissolve assumptions. In real life, it doesn't.
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
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.
30
30
More from UX Collective
Following
We believe designers are thinkers as much as they are makers. Curated stories on UX, Visual & Product Design. https://linktr.ee/uxc · 451K followers
Adrian H. Raudaschl
·Updated just now
Member-only
Innovation is slowing down
Innovation is a critical driver of economic growth and societal progress. But worryingly, tech innovation has been slowing for decades. — Bill Gates once said, "The idea that innovation is slowing down is one of the stupidest things anybody ever said." But today, I want to convince you of the exact opposite. That not only is technological innovation slowing down, but it has been doing so for decades.
Innovation
24 min read
Share your ideas with millions of readers.
Write on Medium
Ryan Houk
·Updated 1 day ago
Member-only
New Brutalism and web accessibility: what you need to know
New Brutalism is a trend that has been growing in popularity over the past several years. A rejection of the sleek and modernist style of buildings that came out of the post-war era, Brutalism is more raw and unrefined. …
WCAG
5 min read
Dhananjay Garg
·Updated 1 day ago
Member-only
Why Lite apps are making a comeback
A brief history of Super Apps and why lite apps are required to make a comeback. — We are almost nearing the end of 2022 and I have a feeling that mobile apps will continue to bloat and occupy all of our mobile phone stores in the coming years. There is no denying that apps have become admiringly interactive, packing in a lot more features that allow…
Technology
6 min read
Anuj Uchil
·Updated 2 days ago
The appeal of complex components in user interface design systems
Using the new exposed nested properties and the preferred instance properties in Figma to build configurable UI kits. — Previously, I wrote about the factory model of designing interfaces which proposed that design systems built with configuration as their underlying principle can improve the efficiency of the design process. Since then, Figma has released the updated component properties (beta), which allow for setting preferred instances and exposing the properties…
Design Systems
6 min read
Magic Brick
·Updated 2 days ago
How much money does a Senior Product Designer make?
An answer backed by unsolicited offers in their inbox without any negotiation. — Product designers in tech are typically paid in base salary, bonus, and equity—and data on this topic vary quite a bit. Even with some US states now requiring that the salary band be included in the job description, it only cites the base salary. The other variable is the term…
Salary
8 min read
Read more from UX Collective
Resume Membership
Tamara Adlin
359 Followers
Startups, UX, Personas, Corporate Underpants & Career Badassery. That's me.
Follow
More from Medium
Caitlin D. Sullivan
in
UX Collective
Tracking the impact of UX Research: a framework
Autumn Kotsiuba
Creating UX Writing Case Studies
FlowMapp
Clean UI Guide: 15 White Space Design Tips
Laís Lara Vacco
in
Bootcamp
5 learnings of a Product Designer turned into a Product Manager
Help
Status
Writers
Blog
Careers
Privacy
Terms
About
Knowable