You’re on a project team. The team has just formed, so you haven’t done any user research, but various internal stakeholders already strongly feel they know what the solution should be. They’re wrong, of course, but how can you dissuade them from believing in their assumptions and ideas? You could protest, stressing the need for up-front user research, but that would generate thrash. You could wait until you’ve prototyped something, then have the stakeholders watch usability testing with users, but the time that would take would likely be too much of an investment—especially given how early in the development cycle it is and how little there is to go on.
As our new book Presumptive Design argues, there is a third way—a middle way. Instead of telling the stakeholders they’re not going about things right or allowing them to overinvest in what’s most likely a bad idea, you can accept their ideas without judgment, get them to unpack the assumptions that lie behind them, build junk artifacts representing their current assumptions, then, without hesitating, test these artifacts with users and watch them fail.
Presumptive Design (PrD) is a method that reduces the risk of inventing the future. In brief, it is a design-led process that depends on crafting an artifact you offer to external stakeholders to capture their reactions. In this article, we’ll detail key elements of PrD’s nuance and power.
Presumptive Design takes the generally accepted process of user-centered design and turns it on its head. It relies on the UK Design Council’s double-diamond diagram—an elegant representation of design thinking’s divergent/convergent process—shown in Figure 1. It also relies on Steve Sato’s variant of Vijay Kumar and Charles Owen’s design-thinking framework from ID-IIT, which is shown in Figure 2.
While PrD conforms to Sato’s model, it starts in a completely different place. Presumptive Design starts with concepts, as depicted in Figure 3. Consider the implications of that statement: designers, without any foreknowledge of the intended user population, just start creating stuff.
But wait a second. Isn’t that exactly what we, as UX professionals, encounter in our daily lives in most companies: engineers taking slim requirements and immediately building solutions without ever understanding the targeted user population? So, how could PrD possibly be a step forward?
Design to Fail
Think about it this way: when you know absolutely nothing about the targeted population, what are the chances you’ll design something that actually resonates with them? Close to zero. When you design and build a solution that is wrong, this improves your research protocol how?
Let’s go back to that definition: Presumptive Design is a design-led process that depends on crafting an artifact you offer to external stakeholders to capture their reactions. The key word here is artifact. What sort of artifact should you create, given you have absolutely no understanding of your stakeholder group?
The focus here is on the internal team’s assumptions about the putative solution. How many of you have had the following experience: you work closely with your Engineering team and/or your Product Management team, and they tell you what the solution should be? This happens to us all the time. There are people—whether in Product Management or Engineering—who think they know the answer—even though they have minimal data to support their position.
About ten years ago, Leo got tired of fighting people who
would win because they were better positioned in the organization than he was and
wouldn’t approve any user-centered research because it was too expensive and would only validate what they already knew
Taking a more Eastern philosophical approach to the problem, Leo accepted the possibility that they were right. Rather than making it a war of opinion or trying to fight them, Leo performed a bit of metaphorical Judo and let his opponents proceed as they would like. In the spirit of true user centricity, why not let the users give the team their opinions of the solution?
The essence of PrD is letting go of a specific point of view. Because we haven’t got a shred of data, any proposed solution is as good a starting point as any other. Why not start with what the internal team sincerely believes? However, typically, that’s where this scenario would end: internal stakeholders would mandate the solution and development work would begin. But in PrD, that’s where things begin. Instead of diving immediately into engineering a solution, PrD requires the team to craft the least costly artifact reflecting its assumptions about external stakeholders.
That isn’t easy to do, but it’s a lot easier than building a full-fledged, operating prototype. Teams often have lots of different assumptions—some of which couldn’t possibly be right; others they may not even be aware of.
PrD resolves the apparent quandary of focusing on a solution too soon by instead focusing the team on crafting the simplest artifact that can capture its assumptions about a solution. Figure 4 provides an example.
In PrD, we call this process of artifact creation the Creation Session. It could have a lot of other names such as the Alignment Workshop or Vision Quest. The people who matter attend this cross-organization workshop to ensure their opinions and beliefs are heard and incorporated into an artifact. Doing this is a little tricky. We devote a considerable amount of space in the book to describing how to run a successful Creation Session. The outcome: an artifact the team has created that expresses everyone’s assumptions.
Playing the Fool
So you end up with an artifact the team is proud of—because it reflects their heartfelt beliefs—but you know it’s wrong. Next, Presumptive Design asks you to take this pathetic excuse of a solution to users. Doing this is exhilarating, actually, because you know that neither the assumptions nor the artifact are right. In fact, knowing they’re dead wrong going in lets you relax. Your real concern should be: how wrong and in what ways?
Consider this typical PrD scenario: you engage with users just as you would during a normal usability test:
You confirm they are interested in engaging with some future-leaning concepts.
You establish a safe and empathic relationship as early as possible during the engagement.
You offer them the artifact depicting a solution you assume could truly solve their problem.
Then, you sit back and let them tell you, in excruciating detail, just how wrong your assumptions were about them, their needs, and your solution.
It’s fantastic. But let’s be clear: it’s not a usability test. You aren’t interested in task-completion errors, task-completion times, improving the design or anything else you’d focus on during a usability test. All you’re interested in is the users’ reactions to the team’s assumptions—because, frankly, that’s all you’ve got since you didn’t do any up-front research!
We call these interactions with users, Engagement Sessions. They are conversations about the artifact in the users’ context. We ask each user to perform a task using the artifact—a task that is just as likely to be wrong as the artifact itself. Here’s a hypothetical exchange:
Facilitator: We’re grateful you’ve taken the time to meet with us. We have a mockup of a concept we’d like you to use that addresses the acroma process. <Facilitator hands the artifact to the participant.> Please use this to work through the acroma process.
Participant:Umm. <Screws up face, looking at junk prototype.> Really? You want me to do the acroma process with this?
Participant: <Shaking head and turning the artifact in various directions.> Well, first of all, I’m not sure I even care about the acroma process. But, for the moment, let’s say that I do. Where would I start?
Here, the facilitator has several choices. Clearly, the participant’s admission about the acroma process’s lack of relevance is potentially interesting. But the team knows the acroma process is central to the product’s success, so the Facilitator may choose a different path, using the Rogerian therapy technique of mirroring.
Facilitator: Right. Where would you start?
Participant: <Laughs.> You’re kidding, right? There’s no way this thing could help me with the acroma process. Where’s the loopnova function? I can’t begin the acroma process without the loopnova function.
And, in all likelihood, the team has just struck gold. As participants begin to buy into the validity of the artifact, they inform the team about the qualities of the experience that matter to them and simultaneously provide direct and blunt feedback about the team’s assumptions.
For example, the lack of relevance of the acroma process. What’s that about? It’s possible the team is correct in thinking the acroma process is central to the participant’s business, workflow, or task. But it’s equally possible the world has moved on, so the participant has long since left the acroma process behind, replacing it with a more profitable approach.
PrD brings a future-leaning artifact into the present. Clearly, the artifact isn’t just any old piece of junk. In fact, it is a highly designed object that needs to fulfill several objectives:
embody the team’s assumptions
provoke the right sort of conversations with external stakeholders
be easy to make
be easy to change
be ambiguous, even as it fulfills all of its other qualities
The internal team has crafted the artifact in service of its assumptions and in the spirit of provocation, not in service of the solution. That’s a big difference—one on which the design team members may need to reflect.
In this case, facilitation isn’t like what you’d do for any old usability study or user interview. Instead, it’s a form of improvisation. You’re about to offer a piece of junk to external stakeholders as the solution to all of their problems. What’s that about? But, when they offer blunt critiques, you roll with the punches, letting them take you wherever their annoyance leads. That’s a huge difference—one on which the research team members may need to reflect.
Picking Up the Pieces
Something very curious happens during most Presumptive Design Engagement Sessions: external stakeholders offer amazing, revelatory insights into their underlying needs. They usually make these admissions in the heat of passion because they truly want to make the object work for them in a way that makes sense. But, often, these revelations are not related to what the team originally perceived the problem to be.
Their critiques are exactly what you’re working so hard to hear. But external stakeholders’ criticisms may be in direct conflict with the team’s original idea. In the worst cases, the disconnect may be so great the team leaves the sessions feeling devastated. The external stakeholders may have destroyed the team’s vision—its heartfelt belief in the solution. That could be a complete disaster!
However, the reality is that nothing so extreme has happened during our Engagement Sessions—even though some team members may feel as though it did. In our experience, PrD results in several possible outcomes:
The results of the initial Engagement Sessions clearly indicate the team is not close to a solution. The team needs to either abandon the entire idea or reconsider something significant about it.
The external stakeholders are keenly interested in the team’s approach. The fact that they understood the solution and were willing to engage with it suggests it was resonating at some level. However, they’ve spent most of the time pointing out where the artifact has failed them—sometimes superficially, but often structurally.
More rarely, the team actually gets most of it right. This typically happens after several iterations through the process, during which the team has made modifications to the artifact.
After reviewing the results, the UX team interprets them—potentially helping other team members to dig deeper into what may superficially appear to be insurmountable negative criticism.
Presumptive Design is not for the faint of heart. It is an advanced technique requiring confidence in facilitation, design, and, ultimately, organizational psychology. PrD begins by aligning your internal stakeholders—your team and your sponsor—on their assumptions about the problem space. It proceeds by crafting an artifact that captures those assumptions. It concludes by offering external stakeholders—customers and users—the artifact, along with a list of tasks your team assumes they can complete with it.
The artifact is like a stone you’ve cast into a pond. The ripples it makes are your stakeholders’ reactions to the assumptions it embodies. The artifact is gone. It’s a “sacrificial concept,” as Suzanne Howard of IDEO says. It’s served its purpose: to provoke a conversation.
Workshop at UX STRAT 2015—Would you like to learn more about Presumptive Design? Join us for a half-day workshop on applying PrD to testing strategies. This workshop will take place at UX STRAT 2015, on September 8, in Athens, Georgia. All participants will receive a 50% discount on our forthcoming book, Presumptive Design: Design Provocations for Innovation, which Morgan Kaufmann will publish in late September.
Get in touch with Leo and Charles—If you can’t make UX STRAT, please feel free to get in touch us at presumptivedesign.com. We’d be happy to discuss training, workshops, brown-bag lunches, or Webinars.
With over 30 years of experience in design—as both a bricks-and-mortar architect and a UX designer—Leo drives highly differentiated and innovative solutions by applying Presumptive Design throughout the product lifecycle, from ideation to execution. Most recently, as Product Design Manager at Intel, Leo led multiple UX teams on mission-critical programs. Prior to joining Intel, he worked on Tektronix’s Logic Analyzer product line, generating several patent filings and spearheading product vision and definition for its next generation of instruments. Leo is a Certified Scrum Product Owner. Over the past 15 years, he has served as Program Chair, Chair, and Vice Chair on the board of CHIFOO (Computer Human Interaction Forum of Oregon), the Portland Chapter of SIGCHI. Read More
As a UX Designer at Intel, Charles works on tools that employees use to get their jobs done. His background is in human factors, research methods, and behavioral science. Charles approaches user experience holistically, insisting that it be more than an add-on to business as usual. Doing genuine user-centered design typically requires whole-team involvement and process change. Justifying such change entails demonstrating that achieving business goals actually requires getting certain targeted populations—of users, customers, or employees—to behave in certain desired ways that sustain the business. What elicits such desired changes in behavior? UX Design. Thus, UX Strategy is really not very different from Business Strategy. In fact, you cannot achieve the goals of Business Strategy without a successful UX Strategy. Read More