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.
Champion Advertisement
Continue Reading…
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.
Design Led
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.
Figure 1—UK Design Council’s double-diamond diagram Figure 2—Steve Sato variant of Kumar & Owen’s design-thinking model
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.
Figure 3—PrD starts with concepts
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.
Figure 4—Team’s assumptions about an intelligent drinking glass
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?
Facilitator: <Nods.>
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.
Summary
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.
Great article, guys. One question that comes to mind is: How do you position the Engagement Sessions with the project team. Do you give them insight into the likely outcome—that their assumptions of what people want or need and what they truly want or need are often very different—or do you take a “let’s build the asset to facilitate feedback and see what happens” approach? Do they go in understanding that the likelihood of getting a solution right on the first pass is extremely low, or do you allow them to be blissfully ignorant?
Great article, interested in reading the book. PrD sounds quite compatible to good practice in project management, especially for projects dealing with high degrees of uncertainties as typical for innovation. These projects often build and learn from artifacts as part of their normal risk-mitigation procedure. In this sense, “Engagement session” is a risk mitigation action for the risk “impact of unproven assumptions about users of the future product” and adds to the body of knowledge of project management. Western philosophical approach in stakeholder management of projects. ;)
Some team members just can’t hear us when we suggest the artifact may not resonate with external constituents as they’re hoping. In other cases, team members may be skeptical that anything about the artifact will be interpreted in a useful way.
What’s most important to impart to the team is that there are always surprises—that the assumptions they think they’ve embodied in the artifact aren’t necessarily the assumptions users will react to. So, even a well-prepared team, one that is bracing for the most surprising outcome, will need to expect the unexpected. It’s that attitude we want to make sure is in place.
We do hope the book is of interest to project managers! One of the concerns we’ve heard from our UX design teams is how little project managers understand about the general process of design, discovery, and so forth.
It’s our hope that project managers who are interested in getting a better handle on UX design and research processes will see value in PrD exactly as you suggest: as a risk-reduction strategy for projects. In brief: if we can figure out in two weeks what isn’t worth building, that hopefully will save months of wasted effort.
With over 30 years of experience in design management and design—as both a bricks-and-mortar architect and a UX designer—Leo drives highly differentiated and innovative solutions. At The Home Depot QuoteCenter, Leo leads a dynamic team of UX professionals in delivering engaging experiences for Home Depot associates. Previously, as Product Design Manager at Intel, he led UX teams on mission-critical programs. As Principal UX Architect for Tektronix’s Logic Analyzer product line, he filed several patents and spearheaded product vision and definition for the next generation of instruments. Leo is a Certified Scrum Product Owner. Over the past 20 years, he has served as Program Chair, Chair, Vice Chair, and Treasurer on the board for 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
