Design Thinking as Decision Framing

Design Thinking is an increasingly hot topic in the corporate world. Organizations should find this as exciting as designers likely find it humorous. It’s exciting because it brings with it skills and techniques people at all levels of an organization can greatly benefit from. It’s humorous because Design Thinking is nothing new.

It’s like they say, “What’s old is new again.” Part of this exciting “rediscovery” may be driven by the popularity of Agile. By design or not, Agile has put the focus on builders building and then getting feedback, often excluding formal design from the process altogether. As Laura Klein recently pointed out, this comes with certain hidden (and sometimes costly) implications, such as:

Design technique can offer an expanded view—given that you approach it correctly. Design is not another process for teams. It is not something you squeeze into Agile, or whatever else you’re doing. (As Erika Hall notes, design is broader than Agile. See image below, adapted from Hall.) Design technique hopefully gets you to examine your core approach to problems, from the very top of the org down.


As Kees Dorst notes in his phenomenal book, Frame Innovation, most attempts to apply Design Thinking in business are not successful. The reason echoes the reason why Agile so often fails to make a real difference. The new idea is “adopted” (read, “preached at teams”) but the focus is kept on solutions (output) and not on executive decision making, strategy, framing, and the generating of real options.

This brings up something that’s been bothering me for quite some time, and that’s the concept of degrees of freedom. You won’t grok agility if you don’t understand degrees of freedom—freedom to vary, the existence of options. At all levels, the focus should be on the creation of options, on the creation of possible paths to value.

When leaders try to keep the control at the top, they often don’t realize they’ve also sapped the system of its options. Leaders should instead focus on what they want ACHIEVED. Design can help them frame their thinking, derisk assumptions, and arrive at a better understanding of what, specifically, they would like achieved and why.

When leadership ventures beyond this and starts making unnecessary decisions, needlessly soon, it spends the degrees of freedom prematurely. This robs the system of its ability to pivot, learn, and innovate. This is what Andy Grove meant when he said you should want decisions made by the lowest levels possible. That’s how you keep your degrees of freedom unspent. That’s how you maximize real agility.

Design can and should help with this. Design Thinking is most valuably applied at the level of strategy and executive decision making. Confining design technique to low-level tactical dev decisions robs it of impact. By then the degrees of freedom have been spent, and most leeway is gone. (Model adapted from Jesse McMullin.)

This is why executives should also study design. If culture is driven by leadership behavior, then culture change is primarily driven by leadership behavior change. Design has a lot of techniques to offer. Design Thinking can help you chunk up the application of technique from coded user interfaces to the “interface” of organizational belief systems and assumptions.

Design Thinking, however, is not a silver bullet. I have argued there is no such “thing” as Agile. Well, there is also no such “thing” as Design Thinking. There are roots in cooperative design and urban planning, IDEO’s take, the Standford D School, some of which oversimplify, risking reduction to a checklist: “Well, first you empathize, then you do Step 2, then Step 3, and—hey presto!” Except it doesn’t work that way.

Dorst describes five self-sabotaging traps that design can help organizations with. In what follows, I’d like to briefly riff off them.

The first Dorst calls the LONE WARRIOR approach to problem solving, which is the old idea that a problem needs an “owner” who in effect dictates the frame for everyone else. This approach prevents the type of rich collaboration needed for today’s problem solving. “Owners” tend to misinterpret collaboration as interference, which throws up barriers to success.

Without an open exploration and vetting of both the desired outcome and the underlying assumptions being made, the result is “frame blindness.” When the owner has unwittingly fixed the frame, she has also unsuspectingly frozen the context. This shuts out learning and insight, constrains discovery, and precludes value-adding options.

Typical planning practices also lean on a FREEZE-THE-WORLD approach to problem solving. Conventional solutioning pretends you can stop the world and plan a meaningful solution based on a static snapshot of the past. With a dynamic and open problem, however, the borders around the issue are permeable and the picture keeps changing. Design Thinking encourages an open, experimental approach.

Scaling frameworks can exacerbate this. As Tim Ottinger has noted, scaling implements a “scatter-and-gather” approach to collaboration, institutionalizing slow, large-batch learning. If the goal is to shift from a planning approach to an empirical one, it is important to realize you’re only free to pivot whenever you “unfreeze” the world. (With SAFe, for example, the world is really only unfrozen four times a year.)

Much of the goodness of Design comes from leading people to break free of unrecognized habits, the click-whirr “tape loops” you don’t even think to question. You need to involve the very top of the org—the people at the top are typically the only ones with the power to think freely. Working with frames with middle management, Dorst stresses, is often not very effective, as the frame is already frozen for them.

As you move upstream to the top of the org, “work” increasingly takes the form of people having conversations in meetings. Design excels at offering alternative ways of holding such conversations and making key decisions. The challenge, however, is that you have to be invited to do so, and when conformity is perquisite to invitation, you’re trapped in a SELF-MADE BOX. Real transformation is an exercise in box-breaking.

When you commit the above, Dorst says, it’s typically coupled with CLAIMING THE RATIONAL HIGH GROUND. You throw pragmatism out the window in service of believing you’re “right.” Pragmatists care more about achieving outcomes. Orgs that claim the rational high ground also love to honor sunk cost with respect to past ways of working, long after they have stopped bearing fruit.

Part of the problem is that your very identity can get wrapped up in this. It’s important to remember that whether talking Agile, DevOps, Lean, Design Thinking, what have you, they’re just lenses that you can look through. Sometimes they frame your thinking in value-adding ways. Sometimes they don’t. This constrains options and can leave you with the wrong metaphors, framing thinking in suboptimal ways.

As Box famously said, all models are wrong, some are useful. In creating options, you should also want optionality in the models you apply. As therapist Virginia Satir would say, one option is no choice, two is a dilemma, three means you have possibilities. When an organization equates ESTABLISHED PRACTICE AS IDENTIY, it ignores this.

Think about it. If the same people at the top keep working the way they’ve always worked and making decisions the way they’ve always made them while trying to find the right changes for OTHERS, then the system is sealed. The result is called “organizational autopoiesis,” a closed culture where change efforts are self-stultifying and doomed to fail from the beginning.

2 thoughts on “Design Thinking as Decision Framing

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s