Presumptive Design: Design Provocations for Innovation

This Book’s Value Proposition

PrD will be familiar to any designer because it involves the creation of artifacts for the purpose of engaging with stakeholders. It will be familiar to any UX researcher because it involves understanding end-user needs through a form of interviewing. With that said, PrD shifts traditional ways of working in ways that may be disorienting to both designers and researchers.

For product managers and market researchers, PrD provides a rapid, qualitative-based research method. It supplements large-scale aggregate statistical investigations. PrD is an inexpensive way to explore the customer/user landscape, identifying “white spaces” that would otherwise be hidden or unavailable through quantitative methods. It is a customer-centric approach relying on small numbers to reveal important data.

For business leaders, PrD enables frank and open discussion about pain points in the organization. When rolling out a new strategy, changing the organization’s culture, or providing a vision for moving forward, PrD rapidly identifies the underlying values of the group. PrD, because it is a “codesign” approach, establishes a two-way conversation about what the vision could be. It engages constituents before the final vision is rolled out, starting their investment in it by incorporating their contributions as a part of it.

PrD is not limited to the for-profit world. It is an easy tool to empower communities seeking to improve services, representation, access, and civic engagement. In the world of social innovation, in which communities make their voices heard, PrD rapidly uncovers issues that matter to community stakeholders.

Although one of us (Leo) discovered the process independently, PrD has been around for many years, in a variety of contexts and with a variety of names: Suzanne Howard of IDEO calls it “Sacrificial Concepts,” [1] Koskinen et al. call it “Constructive Design Research,” [2] and Anijo Matthews of the Institute of Design at the Illinois Institute of Technology (ID-IIT) calls it “provotyping” (short for “provocative prototypes”). In spite of it being used by design firms, academics, and applied researchers for over 30 years, we could find no book providing a step-by-step way of doing it. As we dug into the process and teased out its steps, we engaged with other practitioners who had used it. Throughout the book, their stories and case studies help illustrate PrD’s breadth and effectiveness.

A Twist to the Familiar

PrD relies on an approach to problem solving peculiar to the ways in which designers approach their work. The “design thinking” model we use throughout the book is based on a long-standing framework originating from Chuck Owen at the ID-IIT. [3] We go into details of this problem-solving approach in Chapter 2 because design thinking is fundamental to PrD execution and success.

Agile Culture

Because it fits within the context of design thinking, PrD is part of a larger set of tools and techniques emerging in the early twenty-first century. Titles such as The Lean Startup, Lean UX, and Business Model Generation are indications of how the discipline of design is moving from the studio to the factory floor and ultimately to the boardroom. Inspired by Tim Brown’s seminal article in Harvard Business Review [4] (and by the introduction of revolutionary devices by Apple) organizations of all stripes recognize the need for design, designers, and design thinking. PrD and design thinking are inseparable. Design thinking is fundamental to the method’s success.

PrD also aligns with shifts in business thinking and approaches to leadership. Business leaders are being bombarded with messaging about changing the culture, changing thought processes and behaviors. Robert Schaffer’s article on “basic behavior traps” managers often fall in is an example.

“To escape the [behavior] traps, managers have to do battle with their own resistance, as they would in trying to change any well-entrenched habit. Each person needs to experience viscerally the dramatic improvement that is possible, which is why individuals should start with their own modest, low-risk experiments.” [5]

The attraction and benefit of PrD is its immediacy—an antidote to what Schaffer identifies as the fourth of four behavior traps: waiting. [6] With PrD there is no reason to wait.

Another benefit of PrD is its inherent agility. Agile (originally a means of delivering software solutions) is spreading into the boardroom. Its low investment, along with its speed, positions PrD as a research technique well suited to agile cultures—whether in the product development context or in the boardroom.

In their Harvard Business Review article, business consultants Marin Reeves and Mike Deimler list four tenets of contemporary strategy: reading and acting on signals, experimentation, managing complex systems, and enabling people to act, [7] in brief, rapid adaptation. If the context wasn’t managing large corporations, the article might as well have been discussing the culture of agile software development.

Participatory

Building consensus through a process of inquiry, as opposed to top-down advocacy, has become a standard part of business leadership. [8] This inversion of attitude is fundamental to PrD, leading to PrD’s political implications. This inversion also forms the basis of Participatory Design, of which PrD is a part. Participatory Design is an approach to designing with constituents as opposed to designing for them. In brief, Participatory Design sprang from populist resurgences in the 1960s to provide a voice to labor and to reestablish its influence on the design of national policy. In a similar way, agile software development mirrors that populist ethic. Engaging with your targeted population, in fact, having you as the target of them, is a key transposition of roles and orientation. This mind shift is an essential part of PrD, as you’ll read throughout this book.

In Liz Sanders and Pieter Jan Stappers’s map of research approaches, [9] PrD is bimodal: It has one foot in Critical Design [10] (in which objects are used to provoke reactions to stakeholders) and the other in a generative tool (in which constituents design with researchers) (Figure 1.2).

In an adaptation of Konno and Fong’s map [11] (shown in Figure 1.3) we position PrD as a qualitative research technique focusing on the goals, attitudes, and mental models of user/customers/stakeholders. To minimize risk to our projects we must learn which of our ideas resonate with these constituents and which don’t. More important, we need to know why those ideas fail.

Looking through the lens of “user intimacy” and time, PrD is quick and intimate as illustrated in the constellation map given in Figure 1.4.

A High-Wire Act

In the hands of masters, PrD is a fluid, exciting, and extraordinarily fast method to identify stakeholders’ needs. But, as with any high-wire act, it requires practice to master. Understanding customer and user needs is challenging. Doing it quickly requires nuance, subtlety, and quick wits. With that said, the skills to do PrD effectively are easy to learn and are likely in your team just waiting to be released. And, as with any masterful performance, PrD is immensely fun. At its heart the process is a seriously playful approach to capturing your stakeholders’ needs.

Much of the preceding discussion may sound familiar, especially to individuals who use rapid prototyping in their practice. Rapid prototyping is integral to PrD, but, once again, there is a catch. PrD employs rapid prototyping to capture the internal team’s assumptions about the external stakeholders’ problems. Where rapid prototyping refines a design solution, PrD artifacts focus on the external stakeholders’ problem space. PrD artifacts are designed to be disposable: The artifact is important only insofar as it drives good conversations and illuminates insights.

The Five Principles of Presumptive Design

The following subsections provide an overview of PrD’s fundamental principles. Each is covered in depth in the chapters that follow.

Design to Fail

Consider the following scenario: You are about to engage with a group of people who don’t know you very well, who may harbor reservations about doing business with your organization or aren’t completely bought into your mission. Even if they are not outright hostile, they may not be forthcoming about their needs, concerns, or fears. (In fact, they may not be able to articulate these things.) People rarely have accurate insights into their own needs, let alone their constituents’ needs, and so, if you simply ask them, their answers are likely to mislead. [12, 13] At the same time, you know a change must be made—whether it’s to the operations of the group, the strategy for the company, or a new product or service. It may be as basic as getting access to fresh water. You can’t afford to be wrong; you rarely get a second chance.

This first principle of PrD gives us permission to be wrong. In fact, it outright requires us to assume we are wrong and assumes we will fail. Consider that shift: If we know we are wrong and we know our audience will chop to pieces whatever we’re about to offer them, how might we feel going into the engagement?

Foolish.

And that is exactly the frame of mind PrD requires. We must accept as fact any proposal, whether it’s a new vision or new product, is always wrong, even after it is fielded. Brooks wrote in 1975, “The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.” [14] Let’s face this fact: Nothing we do is ever perfect; we simply need to be “right enough.” Our goal is to raise our confidence we’ve crafted an experience crossing a threshold of “fitness.” PrD requires us to engage with our constituents so they will chop our offering to pieces as early as possible. In engaging our constituents in the process of critique, we engender intimacy and buy-in, not only with the end result but with the process itself, and this in turn helps improve the likelihood of the effort’s success.

As we describe in the detailed chapters, keeping Design to Fail in mind at all times is one of the key benefits and differentiators of PrD.

Create, Discover, Analyze

Create

PrD, being a design research activity, rooted in theories of design thinking, starts with the creation of artifacts. It is distinctly different from other forms of research in which we spend time researching our audience before offering them artifacts, presumably designed based on those discoveries.

Discover

PrD proceeds by offering artifacts as provocations, purely in service of making discoveries. Because we know the artifacts we’ve created are wrong, we are assured our audience will have something to say about their fitness to their world view, values, and latent needs.

PrD relies on the design process of critique, but it uses critique very differently from traditional design:

• Whereas design critiques are focused on the offering itself, PrD critiques focus on the assumptions behind the offering.
• The objective of design critique is to improve the design; PrD critiques are to improve the internal stakeholders’ (your team’s) understanding of the external stakeholders’ (customers’/users’) problem space.
• Design critiques are performed by other designers (in design reviews); PrD critiques are performed by external stakeholders (the users/constituents not on your team).

To be clear, design critiques are not the same as design presentations. Presentations are a form of sales and knowledge sharing, from the team to the audience. Design presentations gather feedback from the audience around the desirability of a solution. In contrast, PrD requires audience engagement with the artifact—they are asked to use it to perform a task.

In PrD, the critique reveals elements of the problem space, not the solution space.

Analyze

Only after the design/research team has had the right conversations with external stakeholders (through offering presumptive artifacts) does it proceed to analysis. But even in the analysis phase the process differs from many social science research approaches. In many traditional research approaches, the team is asked to hold off drawing conclusions or finding patterns until enough information is available. But in PrD, commonalities emerge after only a small number of engagements with external stakeholders. Almost immediately, because the artifacts offered to stakeholders are likely wrong, the team discovers misalignments between its own world-view and those of its constituents.

PrD’s analysis is similar to codifying the stories and conversations ethnographic researchers collect. In PrD, analysis is in service of two outcomes: identifying underlying values, needs, and mental models of the target audience (similar to ethnography) and identifying ways in which the artifact and subsequent interviews can be changed to test these new presumptions (as opposed to simply refining the artifact). As The Case of the Black-Magic Batman illustrates (see Appendix A for all of the cases), Evan and his team were surprised by their users’ reaction to the artifact. Rather than changing the artifact, they changed their protocol.

Make Assumptions Explicit

In The Case of the Business Case, the team set out to test a key assumption: whether external stakeholders would comprehend the concept of an “app store” (à la iTunes) in the context of their work. The idea had already been demonstrated in a marketing deck but had never been tested with its intended stakeholders—that is, key users who would recommend the solution.

A remarkable thing happened during a debrief session after working with the users. The technical lead suggested an app store like iTunes wasn’t at all what he’d had in mind when he first proposed the idea earlier in the year. This came as a surprise to the product manager (and to the UX team who were relative newcomers) since we had been talking about it as part of the PrD for the prior month. How much longer would that misalignment have continued before the team realized they weren’t all talking about the same thing?

We all operate with assumptions about how the world works, how our employees think about us, our organization, our organization’s mission, how our customers think about our brand, products, and services, how our users think about the features and attributes of our offerings, or how our services can improve the lives of our constituents.

As we embark on something new (whether a new feature, a new service, or a new strategy) we harbor beliefs and assumptions about the right thing to do. One of the greatest risks of starting a new venture is beginning with firmly held—and completely incorrect—operating assumptions. Failing to align on operating assumptions leads to disastrous results.

But in many organizations it is those very assumptions driving discussions, plans, and, ultimately, work products. In the worst cases, the teams discover only after they’ve released their offering how wrong their assumptions were. PrD forces the issue by surfacing the team’s assumptions at the outset of the project, when it’s least expensive to learn the most. By surfacing the team’s assumptions to both itself (and other internal stakeholders) and, more critically, the external stakeholders for whom the experience is being designed, the organization quickly learns the value of those assumptions.

Iterate, Iterate, Iterate

Here’s a thought experiment: It’s the kickoff of a new project. Team members are excited to start something new. The early optimistic glow of doing something big, bold, and impactful is in the air. You decide you’re going to try this new approach to delivering value to your customer: PrD. Within a few days of the kickoff your team is in front of real customers with your first artifacts. Hooray! You’re on your way to getting to the heart of their concerns, values, and needs.

What are the chances you will have learned everything you need to know in that first round?

Slim.

In that first round, you’ve probably uncovered more questions than answers.

PrD depends on multiple iterations for your team to raise its confidence in its findings or, put another way, for you to reduce the risk of proceeding down a specific path. As you’ll learn in Chapter 7, doing multiple iterations with a handful of people (perhaps the same people, perhaps different) will reveal far more insights, far more quickly, than doing fewer iterations with more people.

As with agile software development, Lean Six Sigma, and Transient Advantage, [15] the key here is to experiment, iterate, and learn. You know you’re done when one or more of the following conditions are met:

• You’ve not learned enough different in the most recent iteration to warrant doing another.
• You’ve run out of time.
• You’ve run out of resources.

Getting the most out of PrD requires finding the least expensive ways to iterate (addressing the final bullet) and to find ways to iterate quickly (discussed in the next section). The process requires team members who can quickly identify what is being learned and whether it is novel. This last point may seem odd, but as we discuss in detail later on, teams may not immediately see stakeholders’ disruptive and awesome revelations without some professional interpretation.

The Faster You Go, the Sooner You’ll Know

In his oft-cited article “What Is Strategy?” Michael Porter laid out the principles of strategy for a generation of business leaders. [17] More recent thought leadership from Harvard [18] has argued against Porter’s notion of “strategic positioning through sustainable competitive advantage.”

The world is changing. Fast. Strategies, once thought to last years, are crafted on a yearly or even quarterly basis. Product features are continuously being updated, uploaded, and swapped. Amazon, Google, Netflix, and other giants change their offerings every few minutes.

Even companies and organizations that must move more slowly (companies requiring years of lead time, such as hardware manufacturers or pharmaceuticals) are under extraordinary pressure to find strategic advantages as quickly as possible.

No matter the product life cycle or its timing, every organization faces shorter and shorter cycles to identify desired end results with greater pressures for their success. How do we know an initiative is going to return on its investment? How do we know what the customer and user reaction is really going to be? In brief, how can we reduce risk as quickly as possible?

PrD, as a research method, is fast. Really fast. In a matter of days the team crafts an artifact suitable for testing with external stakeholders. In a matter of weeks the leadership can learn what, if any, value there is in pursuing further investment. As new competitive threats arise, the team goes back out quickly and tests their assumptions against the market.

Have Fun!

As the next chapter describes in detail, PrD depends on design thinking and, for designers, designing is fun. Think back to times when you had the time to think, and play and simply get silly. For most designers, that was likely just a few minutes ago. The design process requires a relaxed frame of mind.

For designers, the act of creation is massively fun. For others, maybe not so much. As you’ll see in the next chapter, design thinking requires switching “sides of the brain” [19] from left to right and back again. For individuals who have spent their lives on the left side of the brain, the right side can be uncomfortable, disorienting, and in some cases painful. That doesn’t sound like fun! Yet, the design process in general, and PrD specifically, succeeds when teams enjoy the work and explore wild possibilities.

Later on in the book we’ve provided example exercises to increase the fun factor of your team and of your work.

So, Why Bother?

PrD is a powerful means of discovering information leading to strategic advantage through a rapid series of engagements with our constituents. The lessons learned from these engagements inform everyone on the project, from the product managers to the technologists and the UX team. One of the greatest benefits of PrD, and, ironically, its greatest risk, is how easily teams identify disruptive innovations. Because we offer our constituents views into the future, we learn where our predictions don’t align with our constituents’ reactions to them. More often than not, their reactions don’t negate our predictions; instead they adjust them in ways we cannot anticipate. Those insights are the source of game-changing opportunities. 

Discount—Buy Presumptive Design: Design Provocations for Innovation and other Morgan Kaufmann titles from the Elsevier store online, using the discount code COMP315, now through December 31, 2015, and save up to 30% off the retail price.

References

[1] IDEO. Human-Centered Design Toolkit: An Open-Source Toolkit to Inspire New Solutions in the Developing World. 2nd ed. IDEO, 2011. Retrieved on July 24, 2014.

[2] Koskinen, I., J. Zimmerman, T. Binder, and J. Redstrom. Design Research Through Practice: From the Lab, Field, and Showroom. Waltham, MA: Morgan Kaufmann Publishers, 2011.

[3] Owen, C. “Design Thinking: Notes on Its Nature and Use.” Des Res Q, 2007.

[4] Brown, Tim. “Design Thinking.” Harvard Business Review, 2008. Retrieved on August 11, 2014.

[5] Schaffer, Robert H. “Four Mistakes Leaders Keep Making.” Liberty Mutual Insurance, 2010. Retrieved on August 11, 2014.

[6] Ibid

[7] Reeves, M., and M. Deimler. “Adaptability: The New Competitive Advantage.” Harvard Business Review, 2011. Retrieved on March 16, 2015.

[8] Garvin, D.A., and M.A. Roberto. “What You Don’t Know About Making Decisions.” Harvard Business Review, 2001. Retrieved on July 9, 2014.

[9] Sanders, E.N., and P.J. Stappers. Convivial Toolbox: Generative Research for the Front End of Design. Amsterdam, The Netherlands: BIS Publishers, 2013.

[10] Dunne, A. Hertzian Tales: Electronic Products, Aesthetic Experience, and Critical Design. Cambridge, MA: The MIT Press, 2005.

[11] Konno, M., and B. Fong. Agile UX Research Practice in Android. San Francisco, CA: Google I/O, 2013.

[12] Nielsen, Jakob. “Interviewing Users.” NN/g, 2010. Retrieved on July 21, 2014.

[13] Nielsen, Jakob. “First Rule of Usability? Don’t Listen to Users.” NN/g, 2001. Retrieved on April 21, 2014.

[14] Brooks, F.P. The Mythical Man-month: Essays on Software Engineering. Anniversary ed. Boston, MA: Addison-Wesley Longman Publishing Co., Inc., 1995.

[15] McGrath, R.G. “Transient Advantage.” Harvard Business Review, 2013. Retrieved on August 13, 2014.

[16] Gothelf, Jeff, and J. Seiden. Lean UX: Applying Lean Principles to Improve UX. Sebastopol, CA: O’Reilly Media, Inc., 2013.

[17] Porter, Michael E. “What Is Strategy?” Harvard Business Review, 1996.

[18] Reeves and Deimler, op. cit.

[19] Edwards, B. Drawing on the Right Side of the Brain: A Course in Enhancing Creativity and Artistic Confidence. New York: Penguin Group, Inc., 2012.