Design Thinking at Stanford d.school
When John called to let me know he had an extra ticket to a 6 hour design thinking workshop at Stanford, I honestly wasn’t sure what to expect. Given the university’s not-so-secret reputation for innovation, I assumed it would likely be an interactive, group-think type process that would offer an alternative strategy to the way the military had trained me to think. Having spent several years of my life following a stringent set of procedures in which inadvertently skipping step 3a resulted in a formal 7 hour root-cause analysis on a Saturday, we’ll just say I hadn’t spent much time stretching my creative legs in a structured environment in quite some time and looked forward to the opportunity. Knowing John, I knew that at worst it would be an entertaining experience.
I touched down at San Francisco International Airport after the treacherous, almost hour long flight from San Diego (ladies and gentlemen, we’ve reached cruising altitu… anddd, we’re beginning our initial decent into the San Francisco Bay Area), and almost serendipitously met John and his co-worker Bruno (spoken boss) at the gate as they deplaned. After watching John stand in traffic at the arrivals passenger pick-up yelling “no, the blue bag, can’t miss it!” for 15 minutes, Darryl, another MLC member, and man of many talents and an inexhaustible amount of focus, arrived and we were off to Palo Alto.
In typical military fashion, we arrived on campus roughly 30 minutes early, found the d.school, and proceeded to mingle with the fellow workshop attendees that also had a penchant for showing up much earlier than necessary. The variation of participants was wide, from a group of seasoned consultants attempting to determine how best to fuse 27 separate bay area transit entities into one seamless system to a young team of San Jose city recreation employees looking to better utilize after school programs for inner city kids. John and Bruno, who actually facilitate design thinking workshops as part of a new initiative for the Navy, had a firm grasp on the concept and kept hinting at related topics in conversation only to tell me they didn’t want to “ruin it” for me, as if there was some kind of M. Night Shamalan twist mid-workshop. My imagination ran back and forth between a rigorous process involving formulae and rule-sets and a free-flowing “there is no box” journey tapping into the subliminal and somehow arriving at a mind-blowing solution.
We split into groups of four and were assigned two graduate students in the program to act as guides through our journey in design thinking. The first big concept was the fundamental idea of breaking down the process of problem solving into 2 spheres: framing the problem and creating a solution. These two overarching steps were further broken down. The first step is empathizing with the group that is affected by the issue at hand; to truly understand why this is a problem, what constraints exist, and what really matters to this group. Next, we need to define, or identify the actual cause of this problem and determine an end-state that would equate to a solution. We were five minutes in and I already had my first mini-epiphany. It occurred to me how often I had seen these first crucial steps almost skipped entirely, and how often I had been guilty of it myself; immediately jumping into attempting to identify solutions without truly framing the problem and fully identifying the issue and the desired end-state. Next, we discussed the problem solving process, which was a little more familiar: brainstorm solutions, determine alternatives, create a prototype, test the solution, and refine. With only a few short hours to gain the most knowledge as possible, within 15 minutes we were out of the classroom and putting theory to practice.
Given the relatively short duration of the workshop, our problem was already framed: how do we get millennials to save more money for the future? Simple enough right? Over the next few hours, we were guided in brainstorming possible solutions, rather informally voting on best options, and expanding upon and refining our winning ideas. The trick to this whole design thinking thing, and the part that ran counter-intuitive to my undergraduate studies, military career, and even personal endeavors in diving and climbing, is moving quickly – very quickly. Have an idea? Write it on a sticky note and put it on the board. Think you’ve barely scratched the surface of what constraints and problems might be associated with a proposed solution? Time to move on to the next stage. The pace was rapid, borderline chaotic for a first-timer, but it wasn’t without merit. Within 2 hours we had analyzed alternatives, created a prototype, and were outside chasing undergrads around to seek their participation in a scenario we had crafted out for them to try our solution. Design thinking, at least in my untrained mind, was all about getting that 70% solution out there and putting it in the hands of the audience or customer. Is it perfect? Absolutely not, but it is an invaluable tool for letting the actual user base work with your prototype before too much time, or in a real-life scenario, money, has been invested. If the root idea and framework for what could eventually become a final product is a total flop, isn’t it best to identify that at the earliest stage possible? If the customer views it as a viable solution, refinement can commence and progress through numerous iterations, each time testing the prototype before you’ve gone too far down a path that will ultimately not support the end-state.
In participating in this quick exercise, I am now able to look back at how design thinking is applicable in the military. I’m sure each of us, in our own respective branches with unique problems and systems, has been presented a solution and wondered what the heck the mastermind of this solution was thinking. Did they talk to anyone who would actually use this solution or did they simply get a list of technical specs and work in a bubble? In the fleet I saw this time and time again – a great capable system is delivered that looks great from 100 feet back. Unfortunately, it needs 40 hours of maintenance a week, takes 3 techs 15 hours to take apart, and is extremely difficult to use for an average operator. Fortunately, I’ve started to see the design thinking concept increasingly used throughout the force, and it is certainly gaining traction at high levels, as the creation of John and Bruno’s program can attest to. If there’s anything I’ve gained from this experience, it is that whether it be a physical product or more abstract process, it is crucial to involve the customer in the experience and solicit feedback before too much detail is put into the product or solution.
Stanford hosts this design thinking workout every year in the winter time, and generally sells a few hundred tickets for a very small fee. If you’re interested in attending a future session, I would recommended contacting John Hawley or Darryl Diptee as two great contacts that have been multiple years in a row and are intimate with the process.