Design Thinking in Action: Analogy and Metaphor Thinking

Imagine we need to travel a complex journey from Point A to Point B with a group of co-travelers, and the group is unclear about why or how. Sharing an analogy or metaphor can help! Why? Because analogies and metaphors help us understand complex ideas by equating them to known or simpler ideas. People naturally gravitate to analogies and metaphors because they help us quickly align, get people on the same page, and get ourselves moving together and in the same direction. Consider how the common analogies and metaphors here can help us simplify the complex:

• Animals. We might ask how a crocodile or a hippo or collection of animals in a zoo would solve a problem. Similarly, we might use the old “eating an elephant a bite at a time” analogy to describe a long-running project or complex design, or describe a legacy system as a dinosaur.

• Everyday items. We might view an initiative as a boat on a journey, a set of choices as points on a dart board or radar, a problem as a speedbump rather than a roadblock, and a day of battling situations as a rollercoaster. Future options may be considered through the lens and analogy of a wheel, and we may consider prototypes as clay to be molded and shaped.

• Nature. We might use a lake as an obstacle to cross or a tree as a way to break down a situation (where a tree trunk is a problem, the tree’s roots reflect the problem’s causes, and the tree’s branches are the effects or consequences, a la the Problem Tree Analysis exercise). Tree analogies can also be useful when creating Guiding Principles, and they serve as another example of fractals a la Fractal Thinking.

• The waterfall. We might bring together several analogies to construct a richer situation with many different outcomes. Consider how a group of people can survive together on a boat in the middle of a lake, for example. Change the size and type of boat to reflect the team’s size, position, limitations, and so on. Add a finish line on one end of the lake and a waterfall at the other end. We might further explain how each person or role has a job to do on the boat to help the team reach the finish line. We might plan for the inertia that will naturally pull the people and the boat toward the waterfall, including storms and currents and even dysfunctional relationships (see Figure 11.1).

  

• Fictional characters. We might ask how a fictional cartoon character or superhero with a set of super powers or gifts might tackle a situation. Or how that cartoon character might avoid the situation altogether.

• Historical events. We might compare a pointless activity to “rearranging the deck chairs” on the Titanic, or an antiquated way of thinking or operating to “horse and buggy.”

• Popular movies. We might consider how Lieutenant Caffe coaxed the truth from Colonel Nathan R. Jessup in A Few Good Men, or how Jack Dawson gave his everything to ensure his fictional love, Rose, would survive the sinking of the Titanic.

• Sporting events. We can use an endless supply of sports analogies to help explain how we might work together or achieve the goals ahead of us. Consider how golf and motocross, or a soccer game or rugby game, or American Baseball’s World Series or the National Football League’s playoff process can help us explain the need to work together to realize our mission, or how our individual performance or the team’s collaboration will be measured, will help us get to the finish line, and so on.

Such exercises help us think through complex and difficult matters in less-stressful and more easily comprehended kinds of ways, opening the door to buy-in and deeper understanding.

Design Thinking in Action: Good Enough Thinking

Imagine if we need to get from Point A to a far-off land called Point B, and we’ve only been given $50 and two days. We don’t need a perfect experience or a luxurious yacht or personal jet. We simply need a way to arrive at Point B alive and healthy. What mode of transportation would be adequate or good enough to get the job done? How might we recast the need and replace transportation with another solution, such as a telephone call or virtual meeting?

Long ago, the French philosopher Voltaire said, “Don’t let perfect be the enemy of good.” That is, don’t spend so much time and energy seeking perfection that we ignore good enough and instead find ourselves wasting time, money, energy, and more for no real reason. Perfection costs dearly, and it’s just another reason why budgets get drained unnecessarily.

Perfection versus Good Enough scenarios are all too common in tech, particularly when we are reacting to urgent demands or new needs. Good Enough Thinking gives us the mindset to consider the bare minimums and the point of diminishing returns. When we know our boundaries in terms of scope, schedule, and budget, we can use these guardrails to drive solutioning within those needs and constraints.

Good Enough therefore saves time, optimizes budgets, and preserves other resources. Trade-offs might include experience, quality, long-term supportability, and more, so it’s important to weigh these trade-offs carefully. But when “better” simply wastes time and resources, Good Enough is, well, good enough. Consider the following Good Enough dimensions:

• Acceptable Quality. The longer we refine a product, the exponentially more expensive that product becomes. Why? Because increases in effort and time are often synonymous with exponential expense. Increasing a product’s quality 1 percent, from 95 percent to 96 percent, for example, could actually double the product’s cost or double the schedule needed to achieve 96 percent. Ask ourselves and confirm with one another what “good” looks like so we know when to stop.

• Acceptable Time. If we have been working on an assignment and met its requirements, then any additional time we spend on that assignment is beyond good enough. Unless there’s a really good reason to do more (implying we didn’t fully understand the requirements), doing more is a waste of everyone’s time. Know when to say we are done, and truly finish.

• Acceptable Risks. Risk taking is a part of life. Don’t get stuck weighing the pros and cons for too long. Instead, quickly evaluate the situation and make the next best step or decision to start on that journey.

• Acceptable Downstream Impact. Decisions and trade-offs we make today have lasting impact. Ensure that impact is acceptable for now or create a plan to address less-than-favorable impact that might be realized as we work to make progress today.

Good Enough Thinking is therefore about acknowledging diminishing returns and trade-offs. Reach a shared understanding about what “good” looks like; know the boundaries of scope, quality, schedule, budget, and other resources; and don’t go beyond those boundaries without good reason. When we do the work and meet its requirements, we need to call the work done. And be done, knowing we can always iterate later against a fresh set of requirements and good enough quality bar.

Design Thinking in Action: Edge Case Thinking

Imagine if we must change a large community’s experience between Point A and Point B and ensure the final experience encompasses the needs of the full community. We probably know generally what the community wants in the final experience in terms of capabilities, but what if we don’t know everything they want? What if our understanding only represents 80 percent of their wants? How might we think about the 20 percent of the edge cases we don’t know today, edge cases that might derail us once we arrive at Point A?

Edge Case Thinking is a Design Thinking technique for inclusion through empathy for the “edge” (see Figure 11.2). The term edge case is just another way to describe the needs of people on the fringes of our situation or solution, people who have additional needs or expectations beyond what we already know and intend to solve.

People on the edge help us think and see and deliver differently. If we hope to cover all of our bases, then we need to consider and include this 20 percent who reflect more about what our solution is missing as we understand it today. Ensure we don’t inadvertently marginalize the needs of those who sit on the boundaries or edges.

• How might they act or respond in a way that’s different from what we are thinking or planning?

• How can their needs be helpful to the broader community?

• How can we bring all of these needs together to serve the whole of the community?

Such insights help us understand the breadth of our problems and situations more deeply, so we can create smarter designs and solutions in the long run.

Design Thinking in Action: Inclusive and Accessible Thinking

While Edge Case Thinking represents the missing 20 percent in terms of product needs or solution capabilities, Inclusive and Accessible Thinking represents the even greater percentage of our community with special usability and accessibility needs. Consider how any community is made up of people with vision and hearing impairments, people with technology and bandwidth limitations, people with unseen and invisible disabilities, and people with other needs who are inadvertently excluded from using our product or solution. As we see in Figure 11.3, these are the people who typically do not have the same homogeneous background, education, experiences, capabilities, and needs embodied in the core community. We might think we have a shared understanding of a need, but when we avoid or skip Inclusive and Accessible Thinking, we overlook a tremendous cross section of our community. Some have suggested that ignoring accessibility and inclusion can marginalize nearly half of a user community!

Imagine we are on a journey from Point A to Point B and we cannot afford to exclude anyone. Getting the whole user community from Point A to Point B requires Inclusive and Accessible Thinking as early in the journey as possible, including before we even leave Point A. Inclusive and Accessible Thinking helps us think holistically early enough to avoid usability and accessibility missteps so we solve for the whole community’s needs.

Inclusive and Accessible Thinking is about finding and taking care of the people that we too often marginalize or forget about altogether. It’s about giving a voice to the customer, especially the voiceless and ignored. How do we make vocal the voice of those not generally heard? The answer lies in intentionality and by asking ourselves:

• Who is missing in our discussions and discovery as we seek to broadly learn and understand?

• Who are we intentionally excluding today and why? Who can we help climb out of the abyss that the organization has accidentally or otherwise created or reinforced over time?

• Who is missing in our problem solving as we consider solution and product capabilities and how to release them?

• Who needs an ally when it comes to designing our solution? How might we serve in that capacity?

• Who can we help make a place for, so we all cross the finish line together?

• Who requires a unique way to participate in what we are doing, and how might we include those colleagues with differing abilities in our journey?

• Who else needs to be included even when it’s not convenient or not part of our plan?

Consider the whole of each person, including their obvious and less obvious abilities and disabilities. Consider how each person likes to work, think, communicate, interact, and be treated. What are their distinct cultural, language, ethnic, and other distinctive dimensions? Consider what connects the community to one another, too. Where are the common threads and themes that can unify a community fragmented and isolated over time?

Finally, when it comes to our community’s accessibility challenges, abilities, voice, and coping strategies:

• Learn how accessibility affects communications and inclusion and use language that builds up rather than tears down as a way to set the bar for inclusive and respectful communications across the board.

• Create inclusive boards and councils to drive greater awareness and inclusion.

• Discuss and agree as a team and community how to quickly resolve disagreements and conflicts.

• Use analogies and metaphors that are also inclusive, so they bring people together rather than alienating a subset.

• Consider how people may be intentionally hiding or muting what makes them unique; work to give people the freedom to be themselves.

• Proactively consider the overlap between edge cases and the need for greater inclusion and attention to accessibility

• Drive awareness campaigns to drive greater inclusion and enhance a team’s ability to work and communicate together; awareness in this case is about respecting differences rather than driving uniformity.

• Finally, promote allyship across the problem-solving and solutioning spectrum. Attention to Inclusive and Accessible Thinking means that everyone has a friend and ally. Allies speak up to correct oversights and preserve healthy relationships across teams and the community being served, playing a key role in course-correcting along the journey from Point A to B.

Beyond a community’s accessibility challenges, abilities, and coping strategies, consider culture, values, lifestyle, and more, as covered previously. Allow this knowledge of the community’s cultural diversity to influence how everyone shows up, thinks together, and solves together.

Design Thinking in Action: Modular Thinking and Building

Let’s say we have a tremendous number of people to get from Point A to Point B as we develop a new solution to their problems and challenges, but their needs differ from one another today and will probably continue to differ when we arrive at Point B. How might we make this journey in a way that lets us develop the solution and onboard different groups of people to that solution over time? How can we think in a way that lets those making the journey increase in numbers over time as our solution accommodates their unique needs? Can we accommodate such needs in a parallel kind of way, or should we pursue them in more of a linear kind of way?

We need options. We need ways of decomposing the problem and its solution into modules so we can deliver that solution over time (stepwise or horizontally), including to larger groups of users at a time (horizontal with a vertical aspect).

Modularity is about interchangeable components too, so we can work on the whole by working in parallel on the parts. Designing for modularity creates opportunities to improve and upgrade the whole by incrementally improving and upgrading the solution’s parts. It’s why modularity is so popular in automobiles, homes, computers, and literally millions of other products and services. Modularity gives us freedom and options. Imagine having to buy a new computer because we could not replace the hard drive or upgrade the memory or make the system perform better by upgrading the operating system and its applications.

A popular take on Modular Thinking is captured in another technique called Regenerating through Combining. Consider how we can combine the old with the new in a modular way, the outcome of which is naturally “less new” and therefore easier to realize and highly consumable to our users (compared to something completely new). Being modular is about small wins through incremental add-ons and plug-ins that introduce a new or better set of capabilities to take us another step closer to our goal. As we think ahead and work to bring a complex group of people on a complex journey, consider how to build the new foundation in a modular way so we can bring everyone along.

Design Thinking in Action: The Premortem for Thinking Ahead

Consider bringing a group of people from Point A to B on a journey where the entire trip is fraught with danger. Before taking the first step, wouldn’t it make sense to run through that journey mentally and consider the dangers and perils along the way? This is where running a Premortem exercise can be valuable. Most of us know what a postmortem is: it’s taking a look at something after that something has died. And the learnings in the wake of a postmortem can be useful for sure, but in the end the thing is still dead. There’s gotta be a smarter way to think and learn. The Premortem gives us that way, to take a look at something while the initiative or project is still viable and alive.

This “pre” version of the postmortem was coined by Gary Klein and published in the Harvard Business Review in 2007. It calls for a detailed assessment before death as a way to hopefully avoid death in the first place.

The idea is simple, too. We need to purposely think ahead about what might fail in our project, or what might happen externally to cause death, or who might fail to deliver key aspects of the project. We do this thinking ahead of time before such failure or death occurs. As Gary Klein explains, “In a premortem, team members assume that the project they are planning has just failed—as so many do—and then generate plausible reasons for its demise. Those with reservations may speak freely at the outset, so that the project can be improved rather than autopsied” (2007).

Premortems include building in mitigations or additional user involvement to avoid these failure scenarios. Such mitigations and involvement can help us identify and avoid the kinds of fantastic failures that otherwise surprise and shut down projects, initiatives, and more.

A Premortem also gives people the ability to call out potential issues in a “here is what happened” looking-back kind of way that’s less politically sensitive than “What if Marcy in our integrations group fails to deliver the system integrations on time?” The Premortem is therefore another way to brainstorm by looking back rather than looking ahead. Premortem exercises are useful to help teams

• Identify potential issues.

• Prioritize those issues in terms of impact.

• Design mitigations in advance to avoid those unwanted issues.

• Identify potential biases and missteps we might encounter along the way, including mitigations or next steps.

• Think ahead about how potential risks might become actual issues in light of our plans, up-and-coming industry trends, and other events we might be tracking or planning.

Running a Premortem exercise is easy, and because it’s performed prior to failing, it’s generally low stress if not fun. Consider the steps here:

TIME AND PEOPLE: A Premortem exercise requires 3–10 people for 60–120 minutes per project or initiative (and can extend much broader and longer depending on the nature and complexity of the project or initiative).

1. Identify the project or initiative on which to execute a Premortem. Remember we are doing this exercise early in the project or initiative’s lifecycle, well before anything might have failed.

2. Bring the team together and set the stage: we’ve traveled into the future, and our project turned out to be a disaster!

3. Ask each person to imagine what caused the disaster and share these ideas one by one on physical or virtual sticky notes. Note duplicate answers as a way to later prioritize the riskiest areas, and push the team for fresh ideas as well.

4. If ideation has stalled, introduce a risk or project methodology taxonomy to help the team think anew.

5. Revisit and note the ideas with the most votes.

6. Identify and group the ideas and answers into Affinity Clusters or themes.

7. Identify the ideas’ most critical clusters or themes through a risk management lens.

8. Brainstorm and potentially run SCAMPER exercises to consider early focus areas and preventive steps and discuss these together.

9. Document, prioritize, and introduce mitigations and decisions in a formal risk register.

Once we’ve executed a Premortem, it can make sense to dig deeper into the single most troublesome area for any complex endeavor: schedule. Let’s take a look next at a popular Design Thinking exercise for assessing schedule challenges.

Design Thinking in Action: Boats and Anchors for Schedule Risks

Imagine we are on a journey and simply need to get from Point A to Point B. It’s a simple enough premise. More to the point, though, what might slow us down or stop us completely on our journey? What do we need to be watchful of? How might we run aground or stray off course? Use Boats and Anchors, a fun and helpful exercise, to think about schedule challenges. Identify the obstacles or “anchors” that might slow down our boat and assess these anchors to consider how to minimize their drag on the boat or cut the anchors off completely.

Expand the exercise by identifying more than just the anchors. Consider the rocks and shoals along the way too. What about the sharks in the water? Hurricanes and other storms on the horizon? Pirates seeking to plunder and pillage? How might these factors affect the people on the journey and the project or initiatives (the boat) making the journey? For each of these factors or obstacles to progress, use visuals and stick or draw them atop a visual of our boat. And then—the most important part—once we’ve identified the factors, consider how each might slow us down and determine how to cut those anchors, avoid those storms, and navigate around the sharks. And we might consider how to at least minimize anchor drag if we can’t free ourselves completely from their hold. Even more interesting, we might also consider how anchors could be transformed into speed enablers!

And we can break up our journey into phases to assess each phase more deeply. For example, what might slow down our project as we mobilize our teams, understand the lay of the land, ideate and problem solve, prototype and develop solutions, test and iterate on those solutions, and so on?

Running a Boats and Anchors exercise requires a team and a bit of imagination. Imagine we have onboarded the group onto our boat, and we are on our way to a beautiful island called Point B. We need to protect and preserve our schedule for arriving at this beautiful island. Now consider this: the water surrounding our boat is our situation. How will we navigate the water to avoid getting stuck along the way? How can we be sure we will arrive at the island on schedule?

Use a whiteboard or poster board to draw the boat, the island, our journey, and so on. Use sticky notes to represent anchors and other factors. Let the team add potential anchors, one per sticky note, and stick those to the board. Will we run out of gas (budget) before we arrive? Do we have the right skills or right people on the team to navigate the boat? Do we need special help during certain parts of the journey? Use this Boats and Anchors analogy to think ahead about other kinds of schedule-related threats that could affect our journey to the island too. Again, we might identify ill-intentioned or dangerous sharks in the water, detour-forcing rocks and shoals between us and our destination, pirates who want to steal our resources or commandeer our boat, and storms or hurricanes on the horizon that might change our course entirely. Consider Figure 11.4 here. Be creative!

How will each one of these anchors and rocks and so on slow us down, or divert us, or in some other way get between where we are today and arriving at the island? What additional resources or help might provide us with speed enablers? With the help of others, now consider how to keep on track or get back on schedule.

Run a Boats and Anchors exercise by following the steps here:

TIME AND PEOPLE: A Boats and Anchors exercise requires 3–10 people for 60 minutes per schedule dilemma or challenge.

1. Establish and share the challenge or situation today.

2. Initialize the shared collaboration space (whiteboard, Klaxoon, and so on). with a picture of the boat (our project or initiative), where we are today (Point A), and the Island (Point B, our destination).

3. Develop a list of potentials obstacles (anchors, rocks, shoals, pirates, and so on) to be explored with the team.

4. Give everyone virtual or physical sticky notes.

5. Round-robin through each team member, one phase at a time, and identify an anchor for that phase. What would slow down our boat? Or stop it completely? Where are the shoals? The sharks? Who might be our pirates to be wary of?

6. If ideation is stalling, introduce a risk or project methodology taxonomy to help people think anew.

7. After completing all phases, review and consolidate the learnings.

8. Populate the project’s Risk Register with these new risks.

9. Begin a new exercise to explore and mitigate each new risk.

A Boats and Anchors exercise therefore combines the analogy of a boat and various forms of Brainstorming and Reverse Brainstorming to view a problem or situation from a schedule perspective, including the challenges and risks we are likely to face on our boat journey.

Design Thinking in Action: Mission Impossible Thinking

Sometimes when we face a very important journey, we might choose to give ourselves an impossible goal as a way to help us achieve as close to that goal as possible. A super-extreme scenario or “moon shot” can help us think and decide differently than we might by default. This extreme way of thinking can unblock how we approach situations that are hard if not impossible. Credited to James Macanufo and discussed by Dave Gray in Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers (2010), Mission Impossible Thinking forces us to think beyond the obvious and easy answers.

For example, if we must get from Point A to Point B with a healthy budget and plenty of time, we can do so pretty easily. But what if we have only $20 and 24 hours, and Points A and B are San Francisco and New Orleans? Now we have a challenge that requires tremendous resourcefulness and creativity.

In the end, we may not find a way to actually complete the impossible mission. We may fall short. But with options in front of us, we will have choices to make that might not have been evident otherwise. And that’s really the point; with more ideas to help us along the way, we set up ourselves and our teams and our communities for a greater chance at success, even if our final journey requires a bit more expense or time-consuming path than we aimed for in our Mission Impossible quest.

Design Thinking in Action: Möbius Ideation

In other cases, we might need to move a whole lot of people from Point A to Point B but need to do so in a way that maximizes our resources most effectively and efficiently. This technique is akin to Good Enough Thinking but with a twist: how might we rethink or reassemble our resources to draw maximum usefulness?

Consider how a Möbius strip may be fully used, front and back, to provide potentially twice the value we might see on the surface (as we see in Figure 11.5). How might we optimize our resourcing model to fully utilize our resources? How might we use our equipment and tools differently? How might we employ our people and teams in fresh ways to deliver more value? Möbius Ideation helps us answer these questions by doing more with the resources we have on hand.

When resources are scarce and efficiency is most important, Möbius Ideation can help us innovate. Consider how some conveyor belts, old typewriter ribbons, and moving sidewalks might use a Möbius approach to double the life of those assets. What can we learn and apply to our own problems and potential solutions? Examples might include redeploying our people to wear more hats or take on more roles, giving us greater efficiency when it comes to onboarding, communications, management, stakeholder connections, and so on.

But we’re not here to twist what we have into a Möbius shape. The Möbius analogy is just to help us view our resources in a new way. The real goal here is to think differently about how we can use what we already have in a way that’s more efficient than today. It’s not about taking away obligations or finding a new budget but rather about maximizing the usefulness of the resources at our disposal as we go about our journey.

To perform a Möbius Ideation exercise:

TIME AND PEOPLE: A Möbius Ideation exercise requires 2–5 people for 60 minutes per problem (and can extend much broader and longer depending on the nature and complexity of the problem and early fit of potential solutions).

1. Bring the team together, identify the project or initiative, and identify the challenge, problem, or situation.

2. Create a list of the human resources available to the team today, organized by people or role and their skillsets, capabilities, experiences, and qualifications.

3. Identify the project’s constraints or boundary conditions, such as a fixed budget or schedule.

4. Identify the project team’s constraints, such as the inability to travel or limited bandwidth.

5. For each constraint, identify why changing the problem or situation is difficult if not impossible.

6. For each constraint, identify what the project or project team is lacking.

7. Finally, consider each person and each resource connected to this situation, and discuss within the constraints today:

   1. What can be changed?

   2. What or who can be stretched?

   3. What or who can fulfill unaddressed needs?

   4. How might the team tackle any remaining unaddressed needs?

   5. What are the trade-offs, and how might they be managed (including burnout, role complexity, and responsibility or accountability misalignment)?

When resources are scarce and we need to “play with the team we have on the field,” look for the Möbius opportunities in our situations. Consider how we might investigate how to use more fully who and what we already have to provide more value at the same cost. Look for those ways to fully maximize how our resources are being used, from people and teams to equipment and tools and more. Reassemble resources differently, look for options to uncover more value from the same people, and benefit from the efficiencies of Möbius Ideation.

Case Study

Consider the following case study and questions. You can find the answers to the questions related to this case study in Appendix A, “Case Study Quiz Answers.”

Quiz

1. While a postmortem would be useful, what else might the team do as it seeks to identify another round of risks and plan for the next upgrade attempt?

2. What exercise might the team employ to aspirationally target zero downtime so as to minimize the required downtime as much as possible?

3. The team seemed to spend extra energy and resources on aspects of the plan that exceeded the required quality goals. What kind of thinking might be useful in this case?

4. How might the team more deeply think about schedule risks as it lays out the next multiweek upgrade plan?

5. Which Design Thinking technique asks us to view a problem or situation through the lens of efficiency?