Innovation Theater vs. Design Thinking Mastery

I’ve been teaching and using Enterprise Design Thinking for eight years now. I activated each of the business units of IBM and many clients and numerous other organizations. I’ve also observed the way that many organizations use design thinking that I didn’t teach or lead. And I’ve learned a few things that I’d like to share.

Innovation Theater Defined

Many people do design thinking wrong and few do it optimally. I characterize the major way people do design thinking wrong by saying that they’re simply doing “innovation theater”. I was doing a guest lecture on Enterprise Design: An Intrapreneurial Perspective at the Stanford d.school last week and used this phrase and Bill Burnett who runs the program said, “ah, innovation theater, I like that and am going to use that”. The way the phrase has resonated so well with experts in design thinking like Bill inspired me to devote this blogpost to it as a cautionary tale for non-experts and to provide them with some guidance for how to avoid perpetuating the bad practice of innovation theater.

The phrase perfectly captures the essence of only appearing to be innovative by standing around with stickies and a sharpie at a whiteboard wall, if you’re in-person, or the digital equivalent, if you’re remote and digital. People doing innovation theater simply use the activities and mapping techniques of design thinking and nothing more. They think design thinking equates to doing a workshop and nothing else.

What’s Wrong with Innovation Theater?

You may ask, so what’s wrong with Innovation Theater? If your goal is to simply look innovative and cool, there’s nothing wrong with Innovation Theater. However, if you want to actually be innovative using Enterprise Design Thinking then you’re doing it wrong. In brief, you’re only doing the "reflect” element of the three element observe-reflect-make loop of Enterprise Design Thinking. Unless you’re going to do it right, don’t call it design thinking because your failed project will give design thinking done right a bad name.

Let’s look at what is typically missing when people do Innovation Theater.

Observe: Innovation Theater typically eliminates the “Observe part of the loop which means you’re not understanding the users you wish to serve. You’re essentially “flying blind” and simply making up out of thin air your understanding of users with no real data. Your project therefore lacks the very foundation that all projects should have, a deep knowledge of and empathy for the user.

Make: When you’re only using the workshopping and mapping methods that are mostly represented by the term “reflect”, you’re also eliminating the crucial element of making, the essential intended result of the effort. You have to make a version of what you’re ideating in order to again observe user feedback on it.

The Principles and Keys: Practitioners doing Innovation Theater also don’t adhere to the Enterprise Design Thinking principles including “a focus on user outcomes”, “restless reinvention”, and “diverse and empowered teams” nor the keys including Hills, Playbacks, and Sponsor Users. They typically don’t involve users at all, don’t iterate, and don’t have true diversity reflecting the diversity of the users they’re wanting to serve and the team isn’t empowered to implement the ideas generated in the session. They also don’t craft Hills articulating the who-is-going-to-be-able-to-do-what-with-what-wow-experience to guide the next stages of the project. They don’t do Playbacks of the evolving user experience to all key stakeholders nor have a handful of Sponsor Users who are representative of their target market to work with for two to three hours per week.

Design Thinking Mastery

So how do you do Enterprise Design Thinking optimally? Well, you need to adopt a Designer’s Mindset and disabuse yourself of the notion that design thinking is a workshop or just just a set of methods and tools to use indiscriminately.

Observe: You need to gain a deep understanding of the users you intend to serve. You can do that by carrying out the type of user research that’s required for what you need to learn. That can take the form of ethnographic observation especially if it is important to understand the environment your users are in, how they interact with one another, and without any undue influence, interference, or potential bias from you. If you require deeper insight into the what your users are thinking and feeling, you may want to use structured interviews. My favorite interview questions include “what keeps you up at night about your job?” to get at deep worries that users have that you should consider addressing. When a design team of mine a few years ago was working on a health application, they asked Oncologists that question and they got answers like “I worry that my diagnosis is wrong or that I haven’t read the latest literature about my patient’s condition”. The application we were working on was able to provide information to address these sorts of concerns. Another favorite question is “what gets you up in the morning about what you do?” which gets at what they really value. Those same Oncologists answered this question by saying “the time I get to spend with my patients” which made the design team realize that we needed to make sure that the technology we were working on wouldn’t get in the way of the physician-patient interaction. Of course, you could use a combination of these two methods or hundreds of other methods. To know what to do, you should call on a trained Design Researcher (also referred to as a User Researcher).

Reflect: You need to consider the tools of design thinking, like Empathy Maps, Stakeholder Maps, As-is Scenario maps, Prioritization Grids, Storyboards, and To-be Scenarios, like the tools of a carpenter uses. They don’t indiscriminately use a hammer simply because it’s the first tool in their toolbox even when they’re dealing with a screw. And they don’t use the first Allen wrench that they see when it may be the wrong size for the job. No. They suit the tool to the task or objective at hand. You need to do the same. For example, if you’re working in a domain where the user and the people they interact with are equally important to understand for the problem you’re solving, consider different approaches to capturing the input. You could use one Empathy map with different colored stickies, one color for each person you’re interviewing. Alternatively, you could create a separate Empathy Map for each person and to be even more comprehensive, link those individual Empathy Maps together into a Stakeholder Map capturing the relationships between the people involved. You can do the same to capture the experiences of people who interact with one another over time using an As-is Scenario Map. You can again use different colors of stickies for the different people or better yet if they play particular roles, you can use what are called “swim-lanes” for each role and then draw lines indicating when the different roles interact with one another. Also, if you’re using an As-is Scenario Map to capture the day-in-the-life of the person you’re observing or interviewing and their experiences involve working with data throughout and that’s important to what you’ll be building, then include the data they’re working with as a swim-lane as well. Make sure too that you have team members work individually especially during ideation and voting so that you truly get the representation of the room and counteract any groupthink or uneven influence of particular members of the team when you have the team verbalize rather than individually write their ideas. My technique is to use the phrase that it’s “quiet time” now and that I should “only hear the synapses of each person’s brain firing away with creativity”. Become a master carpenter by using your design thinking tools to suit the objective of the project you’re working on.

Make: You’re not done until you’ve made the thing you’ve been working on. And what you make again needs to suit the purpose. The various purposes include thinking through your ideas visually and experientially, communicating your ideas to others, getting feedback from potential users, working out technical feasibility, getting buy-in from stakeholders or investors, etc. Again, don’t mindlessly go about making, intentionally make to suit the objectives you have. For example, you could use a Storyboard to think through your ideas visually and experientially as well as a very early way of communicating your ideas to others. You could draw a paper prototype of an app and use it for a user evaluation or if you’re designing the new flow of patients through a clinic, arrange the layout of the chairs, tables, and mocked up new designed artifacts out of boxes or styrofoam for users to literally walk through. You may want to built a coded prototype to test technical feasibility if, for example, you need to determine whether the machine-learning or AI technology you’re using or the data corpus you have access to is sufficiently capable of doing what you intend for it to do. You may want to build a visualization of your ideas focusing on its value to users in order to show stakeholders or potential investors. A polished video is often a great way to do this.

Principles and Keys: Make sure to maniacally focus on user outcomes. Revisit regularly throughout the project, especially as you’re heavily into implementation, whether you’re still delivering on user outcomes or whether the constraints imposed by technical limitations are compromising the user outcome experience excellence. Challenge yourself and your colleagues too whether your team is diverse enough and whether your team reflects the diversity of the users you’re intending to serve. Project leadership should also continue to challenge themselves as to whether they’re empowering the team sufficiently for them to deliver on the user outcomes. Another question to regularly ask yourself and your team is whether you’re iterating enough. Did you settle on one idea too early when you should have explored a couple of other ideas. Are you learning from your user evaluation sessions that you should more significantly pivot your design and iterate on it? Have you written Hills in the form of who will be able to do what with what wow experience and if you have, are you regularly checking to ensure that you’re still aligned with those Hills? Are you doing Playbacks showing the evolving user experience to all of the key stakeholders and if you are doing that, are the playbacks truly telling the story as a first person experience or are you devolving into statements like “and then the user would tap here”? Take the point of view of the user by using a think-aloud approach and saying things like “oh, I see that I change my setting by pressing this button, let me press that now”, etc. Lastly, make sure that you’re getting a ton of user input and feedback from Sponsor Users, a few real people who are representative of your target audience. Work with them intensely and often.

Designing for the Future

Another way you can optimize your practice is to not only design for the here and now but also for the future. If you only focus on designing for the here and now, your product, system, or solution will be out of date by the time you deliver it. You also have to prevent your design from causing unintended consequences.

Strategic Foresight: There is a whole set of tools, methods, and practices called strategic foresight and also often referred to using other names like speculative futures. These are powerful ways of ensuring your designs will be appropriate for today but also for the future, or in fact, alternative futures. The field of strategic foresight is vast and beyond what I can cover in this blogpost but suffice it to say that you should explore this exciting area to further fill your Enterprise Design Thinking toolkit to be able to focus on trends that are relevant in your domain and ways of analyzing them to ensure your designs will be future-proof.

Pre-Mortem: While the field of strategic foresight is vast, there is one future looking tool that I would suggest should be in every designer’s toolbox specifically to prevent unintended consequences of design. It’s called the Pre-Mortem. The idea is rather than doing a post-mortem after a project has failed, you do it before and then get the insights to prevent the failure. It’s really simple. When the team has worked an idea, you get them to imagine that it’s a year from now and you’ve implemented your idea exactly as you’re now planning it, but it turns out that it is a complete and utter failure. You then ask “what went wrong”, not what could go wrong but rather imagining the actual failure and asking “what went wrong”. After you get those insights, you get the team to ideate on mitigations that would have prevented the failure which you then build into your now more future-proof design. People are fond of the phrase “fail fast and often”. I suggest that people use Pre-Mortems to imagine failing fast and often so that they can prevent some of those failures. I firmly believe that many of the unintended consequences that we’ve seen with a number of startups, scaleups, and now enterprises could have been avoided had the teams gone through this simple exercise. And, you shouldn’t only do it once, do it periodically to stay ahead of potential problems. One of the benefits of this tool is that you often see the design project for more than the thing you’re designing and instead realize that you need to be designing a system that has many users, stakeholders, and often some bad actors.

Designing in the Large

You should also use the masterful power of Enterprise Design Thinking when you don’t just open the aperture at the end of a Pre-Mortem but also in tackling big, even societal, challenges. I led a Design Challenge, together with the World Design Organization, Design for America, and IBM Design, just after the beginning of the pandemic last year for designers to have a positive impact in addressing seven major challenges of the pandemic. Many of the designers were surprised that they could apply Enterprise Design Thinking to tackle even huge challenges like this and in a period of only three weeks (check out the article for more details and the website for the results of the challenge). I led another Enterprise Design Thinking session recently with MIT Solve on the Rethinking Pathways to Employment Grand Challenge for people who are job insecure. This session involved having the winning teams of the challenge co-creating a customized version of their proposed solutions (cycling through the loop again) together with job seekers, potential employers, and case workers for particular workforce boards in specific regions of the US.

I believe we can and should be designing and co-creating with affected communities solutions to address the biggest challenges of society using the Enterprise Design Thinking framework.

So, if you’re doing innovation theater today, please consider the ideas above to develop your mastery to realize the true power of Enterprise Design Thinking. If you’d like to learn more about Enterprise Design Thinking and take some free (during the pandemic) self-paced learning, head to our website.