Stanford Webinar - Design Thinking: What is it and why should I care?

Perry Clavon is the Director of Executive Education at the d.school and an adjunct faculty professor at Stanford School of Engineering. He's a seasoned entrepreneur and a product designer. But despite his years of running startups and corporations, Perry's true calling is teaching, which is why we love to have him. It's so much fun.

And then also with us today, we have Jeremy Utley. Jeremy is the Director of Executive Education at the d.school and an adjunct professor at Stanford School of Engineering. He's also an outstanding collaborator and teaches many celebrated courses at Stanford. Gentlemen, it's always a pleasure. Thank you for being here with us today and take it away.

Awesome. Thanks so much, Robin. We're thrilled to get to see everyone today and we're excited to get started. This question, "What is design thinking and why should I care?" is something that we hear often at Stanford and in the world. And there's a great thing about design thinking becoming a popular term, which is that lots of people are curious about it. It's somewhat well-known, but there's a downside, which is that all of a sudden, it starts to seem special or inaccessible. And that's ironic for us, because the goal of design thinking is actually to make the tools and mindsets and ways of thinking that have helped designers solve problems available to folks who don't consider themselves to be designers, or maybe even don't consider themselves to be creative.

So, very simply, design thinking is a way of coming up with ideas and seeing whether they're any good. Very simply. And it's meant to be not some specialized thing that's reserved for the chosen few, but a set of tools that can help anyone in any career, in any organization, in any role in the organization, be more effective at solving the problems you're tackling. There, whether those problems look like introducing new products into the market, or crafting a sales pitch, or writing a subject line to an email, or designing an expense reimbursement process. We see all of those as opportunities for design thinking, or for coming up with ideas and learning whether they're good ideas. Very simply.

Just to get started, we want to start with this quote by Linus Pauling. He said, "To get a good idea, you need a lot of ideas." And that's something that very few people really appreciate. It's the—it's said so simply, as only a two-time Nobel Prize-winning chemist could say it, but it's actually profound. What the research indicates is that the single most important variable that affects how good your ideas are is how many ideas you have. And so, while many people are really focused on coming up with better ideas, the truth is, they should be coming up with more ideas. The way to get to better is actually to generate more. And what we would say is that design thinking is an exceptional idea generation methodology. To put it very simply, it's a great way to come up with a volume of ideas.

And you may be familiar with a process visualization that we've used and popularized now about 10 or 15 years ago through a video that Perry and I made and we released it on YouTube. It ended up being viewed, gosh, half a million or maybe even a million times. And so this visualization became very popular, probably more popular than it should have become. But it became a way to describe one way to think about what designers do, which is very simply: they empathize with people they're trying to design for, meaning they try to get to know them and understand their feelings and emotions, etc. Then they define a problem to be solved, meaning they start with that loose understanding of human beings and say, "What problem really matters to those people?" And then they ideate, they generate a bunch of potential solutions, and through a series of prototyping and testing, implement and refine and discover whether their ideas are any good.

And the useful thing about this way of visualizing the process is it helps us put various tools that designers might use, that we might recommend, that anyone in any role might consider bringing into their problem-solving process. It helps us put them into buckets. That's been really great. The downside of us using this visualization is a lot of people have taken design thinking as a recipe of sorts, or a formula of sorts, and they assume that if you, you know, if you empty the powder into the bowl, and then you add water, and then you beat it, and add an egg, that all of a sudden the cake's gonna come out. And so it's not—it's a little bit misleading in so far as it looks like a linear sequence of events that has a clear beginning and an end point. It's more a set of mindsets.

And so, rather than talking about a fixed process, per se, what we thought would be fun to do is actually introduce design thinking by way of a story. Because we have the incredible privilege of getting to interact with some of the most innovative individuals and innovative organizations, and even organizations that don't really seem innovative, but their employees actually are, and they're doing really cool things. We hear a bunch of great stories, and we feel that we're stewards of those stories. We have the opportunity to showcase how a mindset of a designer leads to breakthroughs and leads to realizations and meaningful impact in human beings' lives.

So, we want to tell quickly the story of our friend, Bill Pacheco. Who has a very—had a very illustrious career, not only as an engineering leader at Cybex, but also as a director at Keurig Dr Pepper. And he now teaches at Trinity College. Most importantly, though, I like to think that his—that the most important organization he's involved with is Perry's Nightmare, where he is my doubles partner in tennis. And we like to give Perry a very hard time on the tennis court. But Perry, would you like to tell the story of Bill and his incredible innovations?

Yes, so pleasure. I just said, just to clarify on the tennis, you know, front there, you know, there's another partner involved. I have a doubles partner, Logan, maybe on the—on the group right now, Logan Deans, and I. And, you know, Bill gets a lot of practice these days. He and his brother play all the time. So, anyway. And I, you know, I'm pretty busy here, Phil. You know, so anyway. Bill also teaches at BU now as well, so Boston University. Terrific fellow. And it's such a pleasure. One of the great things about doing the work we do is actually being able to, not only talk about alumni of the programs, but use these live examples. And this is something great about the programs we put together. It's just terrific to, with LinkedIn, hear stories from you all and see how you're using the tools we teach. And it actually drives a lot of the changes. Bill, for example, the story I'm about to share with you, a lot of the techniques we use in prototyping, that one step Jeremy talked about, have come from the direct work with Bill Pacheco.

So, with that, we'll talk about. So, for those of you that, that the two companies mentioned, Keurig is a coffee company. It has those capsules. You may have, you stayed in a hotel, or been to, you know, an airport, or whatever. Their capsules. And they have this neat technology. He, he was, um, did the product design there for a period of time with the team. And also, um, earlier in his career, when we met him, he was working at a company called Cybex. If you've been on a treadmill machine, if you've been on an elliptical trainer, a stationary bicycle, they're one of the major, major suppliers of equipment like that. And chances are, you've been on something actually Bill's designed, if you've been to a hotel gym and actually used anything, or for a big corporate gym.

So, with that, um, I wanted to go and talk a little bit. So, we're going to dive a little bit deeper on. So, so what we're going to tell is a story of Bill using design thinking as a way to sort of bring life to the steps that, um, Jeremy spoke about, and actually be able to talk to you about what, what this looks like in real life. Okay? And I think that's a big component. We're passionate about this program. Is we cover all aspects of design thinking, how you might use it in teams, and how you might use it in a larger, larger organization, which is what this story's about.

So, here's, um, Cybex. Cybex is part of a group of competitors making a product. So, we're going to talk a little bit about, um, treadmills. So, treadmills, the thing is, you, you hop on top of and you run, and you actually use for, um, a workout. Okay? These are their competitors. So, at the time, we sort of click into this, this was, um, you know, about 10 years ago, probably. Bill was doing this kind of work. And these are the competitors. And they're, you know, like any company, they're sort of duking it out with these people, you know, fighting for market share. And, um, Bill, having had, you know, training in design thinking, you know, went to a gym and actually, um, used some of the techniques of empathy. That first stage is, you sort of open up your brain, you, you observe, you, um, maybe inquire, and actually talk to folks, asking more open-ended questions, but you leave yourself open to inputs. There's many, many different techniques. This is a good example of observation.

So, what Bill did was, he took his notebook, spent a while, and just stayed and watched. And what he noticed, you can tell, he's shared these pictures. You can see these folks. If you just go in close to your screen, you'll see these, these amazing machines that have, you know, all this terrific technology, and these monitors, all stuff people are holding onto, all the screens, and holding onto things for dear life. You got the sense there's something more going on here than, um, I'm aware of. You know, this is, and something we seek to understand in those early stages of design thinking is understanding emotions of the users. Not, he didn't measure, you know, how long are people on the treadmill? How much do they, you know, talk about it? It wasn't data collection. He was really looking at faces. And any, what he noticed was the emotion that was fear. What he knows is people were afraid on these machines. And he thought, "Oh my god, that's, that's super interesting to understand." And use that to launch into design thinking and begin to understand this, this, um, why they might be feeling fear, and take a sort of a very open perspective to that.

So, as he, as he talked to folks and began to understand, he developed, um, some ideas around basically changing the structure around these products. So, keep in mind now, he's part of an organization, Cybex. He has a boss. And this is a category of product that the assumption was, like many products, it's pretty much set. There's a treadmill, you run on. There's a screen. You know, we've got lots of competitors. There's much better things, you know, Bill could be working on. So, he, he sort of did some quick drawings. He sort of said, "I'm gonna, I'm gonna try to make a machine that that deals with this aspect of fear and maybe gives people more places to hold on to." He did some quick prototypes. He did some quick drawings. And like we all do, he went to his boss and he showed it to him. And this is the note he got back.

So, those you can't read it, it says, uh, he did this presentation and showed, there's a picture behind this that's that's hidden, but it's a prototype with these PVC pipes that he sort of built out quickly, which is a technique of rapid prototyping. So, he's got this insight about fear. He's done some work to build something. He's got some ideas. And his boss, Ray, says, "I'm not a fan of anything in this presentation."

So, part of what we see as folks use these tools and techniques in their organization is they're new. And part of what, uh, Jeremy actually does a component with another collaborator from Stanford, Justin Farrell, about how you might think about approaching these organizations. This, this was a typical response. Is, you know, "There's nothing to do with treadmills. Treadmills are a safe business." His boss wanted him to move on and do something else. What he knew was, Bill knew he had a great insight. He knew the end user was afraid. He knew there needed to be changes. He could tell there was an opportunity to sort of pursue this further.

So, what he did was, he went a step further. And he actually, um, decided to take a little bit of extra time. You know, not, not a huge amount of time, but built up some really quick prototypes and began to sort of put these extra railings on, and these, these things that were sort of designed very, very differently to allow people points of connection to the machine that weren't about the electronics, and weren't about things that were not intended for that purpose, which is what he saw before. And he did a really interesting thing. That as you get to the design process, you, he noticed something in empathy, this idea of fear. He framed it up and said, "I'm gonna build a machine that addresses these, these, um, points of stability and these, these fear points." And what drives that fear? He ideated, came up with a bunch of ideas. That was that presentation. He did one step further. He said, "Hey, I'm gonna prototype and test." And that's a great way to validate, to say, "I'm gonna put this out there for just a little bit and see if, see how the user responds to it."

So, his, his idea was to show his, his boss, ultimately, some information from that prototype and test cycle, which is what we espouse. So, he went out, he put these really rough prototypes. They, they look really polished, but he's literally welding little bars onto them and making him look good. He took him to a hotel gym. And he just, he measured how many people picked the machine with these new, you know, rails and new sort of ergonomics. How many people picked the existing machine? They were just side by side. And he got really good data. And something we espouse with our students is, how do you actually put something out in the world and use it to, to make sure you validate it? Not only validated the problem Jeremy talked about. There's sort of two things going on. Definitely validated by people picking one or the other. There's something to the aspect of fear. They look at that machine and they say, "No, no, they want this one." And then he would talk to people after using it and see what their experience was like and get that data. That data allowed him ultimately to put something into market.

So, this is a, was a success. Financially great for the company, great outcome. But more so, what Bill knew was he was solving a real human need. Which is at the core of what we teach with design thinking. Is too often, we sort of walk through like accepting an existing problem statement. You know, a lot of business problem statements might be around, "How do we increase revenue?" or "How do we sell more?" In the reframe that happened with Bill was, he learned, "Hey, for our products, there's this emotion, fear." And I'm gonna actually use that to design and ultimately design a far better product. And it's a great outcome and a terrific product. And if you see it in the marketplace, you'll know all the backstory of where it came from. But I think a good example of running through that entire cycle of design.

It's an amazing story. And there's some amazing, uh, comments happening in the chat too. Someone mentioned, let's see, Ray said, "Wait, you're telling me that he took action and made a prototype even after his boss said he didn't like it?" And what we'd say is, there's really two really important things there that are worth unpacking, just in response to that, um, question, right, or that realization, right? Because a lot of us go, "My boss said he hates it, so it's done." But design thinking is really useful. And it relates to Vivian's point around the pandemic of trust, as well. Design thinking puts us in such close proximity to the people that we're designing for, or we're trying to innovate for. And it could be a, you know, a human being in a gym. It could also be an employee who's the recipient of an HR policy, or an employee who's trying to file their expense reimbursements, or it could be, it could be any one of those things, right? So, we don't mean to only limit this way of thinking to new product introductions.

But the point is, using a designer's mindset, one of the things we advocate is getting close to the people whose lives you're hoping to impact by your work. And what happened for Bill is, he got conviction that people were afraid, people felt unsafe. And as he's watching and interacting with people in gyms, that conviction grew. There's, there's a need for, for a perception of safety here that I feel is a really, a real human need, a real human pain that deserves to be met. And I think, and we've seen that countless times with many individuals inside organizations. The senior management will say, you know, to our friend Doug Deeds, who pioneered an incredible innovation at GE with a pediatric device, that the senior leadership at the time said, "There's very few pediatric wards in the United States. Don't waste your time on this." But just like Bill, Doug had engaged with the people whose lives he was trying to improve with design, and he felt their pain strongly enough to ignore what his bosses said, effectively. And one of the amazing things about design is, all of a sudden, you can quickly become the resident expert in the people's lives who you're hoping to transform with your work efforts.

And so, that's the first thing. The second thing is, and I think it's also related to Ray's question about, "Wait, Bill just pushed through even though his boss said no?" What he realized is, his boss is reacting to an idea, but he has no information. He doesn't understand. There's no way to contextualize the idea other than according to his own past history. And what Bill realized, what's really magical, is part of the design mindset is saying, "Really quickly, I can actually create data." You know, our organizations love data, and we think about looking up data and looking up research reports. But what designers are doing, or what individuals who don't consider themselves creative or designers before, but who are using these tools, that's who we're calling designers. What designers do is they're actually finding clever ways to create new data sets which help them make better decisions. And as Perry mentioned, when Bill put the couple of, you know, prototype units inside of a hotel, he was able to watch people vote with their feet. And so, even though Ray has 65 patents in the space, and even though he thinks it's a bad idea, he can't deny the fact that when 30 people walked into the gym, 28 of them chose this machine. Why did they choose it? That really validated the sense of fear that Bill had picked up on, right?

And so, it's that kind of enlightened trial and error that we're advocating, where you're really deeply connecting with the people whose lives you're hoping to change, and then you're willing, humbly, to be learning whether you've got it right or not. And if Bill had implemented it and it didn't go well, I think he would have given up the hunt, or he would have found a different way to go about trying to convey a sense of safety. But the point is not insubordination. The point is thoughtful care about how do we impact the people whose lives we are trying to impact. And how can we help stimulate our own thinking? As we said at the beginning, with this Linus Pauling quote, "We need a lot of ideas." And there's some research that indicates that the average corporate brainstorm generates two ideas. Just two. And so, what design thinking does is it helps teams overcome that tendency to settle very, very quickly.

But we mentioned before that this, this way that we've been describing the design process is a little bit outdated. And so, we thought it would be fun to do, before we dive into some more of these questions here, and Perry, maybe you can be looking at the questions and seeing if there's anything that we want to start with. But we thought it'd be useful to say, how we think about describing the process now. If it's not these five colorful hexagons, how do we describe it now? And what we'd say is, very simply, design thinking is made in advance on conventional problem-solving. Where conventional problem-solving basically is this: a boss says, "Implement this solution." They hand you a grain of sand, they hand you an ideapost, "Do this." That's it. And what design thinking said, it makes two meaningful advances.

The first advance that we advocate is we say, "Hang on. Before we converge on one solution, let's diverge and let's generate as many possible ideas or ways to solve the problem that's been given as possible." So, the first step is diverge before we converge, right? And that's an enormous advance over, "Implement this solution." The other significant advance that we have made in the d.school is that we've said, "Actually, let's recognize that there's two pieces to any problem-solving endeavor." And we think a lot about problem-solving. But let's stop for a second. Let's talk about problem finding. Because really, implicit to any solution we're trying to implement is a problem that we think we want to solve. And what designers have become very adept at is being as clear about the problem they're trying to solve as they are about the solution that they're advocating. And just like with the solution, it's also an opportunity that we diverge, we generate lots of potential problems and ways of thinking about the problem, or framing, as we might say, before we converge.

And it's useful to think that there's these two discrete outputs to a design effort, because a lot of times people just think about the answer. And what we would say is, the question is every bit as important. John Dewey, the famous American educational reformer, said, "A problem well put is half solved." And so, a lot of the efforts that we spend in the design practice, and that you might spend if you're doing finance, or HR, or product development, or marketing, or content strategy, a lot of your time is actually spent framing a problem worth solving before you ever even undertake the tools to think about how you solve it. The goal, ultimately, is to get this high degree of alignment, where you have a high degree of confidence that the problem that you've identified and the solution you've imagined overlap. And everybody's, you know, goal is that these things would overlap perfectly. It rarely happens that way in the beginning. More often than not, there's kind of a misfit, and there's not a, there's not quite the right way to think about it.

And so, teams that get good at design are constantly assessing both of these things: the problem that they've articulated and the solutions they've imagined. And they're assessing their fit. And the way they assess their fit is by being, uh, by being clear about not only what they're working on, meaning, "Right now, we focus on the problem," or "We focus on the solution," but also how they're working, meaning, "Are we generating options? Are we making decisions?" So, if you think about those, that kind of that two by two, there are four discrete buckets that we could draw from at any time to help us think about how we might advance our thinking. And when we talk about process now, a lot of times we talk in terms of these buckets, because it's a little bit more useful, it's a little bit less prescriptive, it's a little bit less sequential, and it helps us capture. The goal is for any team to be able to be fluent about, "What kind of activity do I need to undertake right now to continue to advance my learning about the problem we're trying to solve, or the way that we're trying to solve it?"

And so, ultimately, we aren't looking for robots or automatons who can perfectly recite chapter and verse on the correct sequence of events, so much as individuals who have a fluency and a confidence and a capability around self-navigating, "What am I working on right now? How should I be working? And what tools would be appropriate for me to draw upon next?" That's how we like to think about process here. With that, I'll stop. And maybe Perry, have you seen a couple questions that we want to dive into?

Absolutely. So, there's, so Rick White, uh, in the middle of the list, made a great comment. And, um, I wanted to go back to it. So, it's number, if yours are numbered, it's number 33. Um, but it's a, it's a great comment, Jeremy, that sort of punctuates something you've been saying. And I think he, he, he wrote it better than you said it. Just gotta call it out there. You got it. I love it. He said, um, "Businesses seem to keep us focused on the product (output). It seems like you are saying that creative process needs more inputs." And I would say that's a, that's, I wish that we had, you know, like, put that at the beginning as like, almost like a tenant for designers, which I very much agree is, you're mindful of inputs.

So, in the story about Bill, he was mindful about inputs. He was mindful about going out and getting more content. He was sort of able to say, you know, "If I think about treadmills, or think about the next project I'm going to work on, have I spent some time in a gym and just observed? Have I spent some time? Do I have some ideas about how people are feeling on some of that?" And he may have gone there on a day when he noticed somebody on the stationary bicycle to be a different story about a stationary bicycle. But he was mindful, "I need, I need some input." And he's, as an individual, I know him to be that way now. He's mindful about his inputs and mindful about, "Am I spending time?" You know, we give one, actually, one of the components of the class is about daily practice and about techniques for you as an individual to build being mindful about inputs into your practice. But designers are seeking inputs to frame up interesting new questions. But Bill found a really interesting problem because he was mindful of inputs. And then later on, when he said, "Hey, you know what? My, what my maybe my boss needs is some other input to this project, which is some data, some some information from testing to see what happens."

And then there was a question I wanted to sort of tie in with this, which that was, um, fascinating. So, Jonathan LaPlante, um, number three. I'm glad you pointed that one out. Hoping for them too. "I've tried the design thinking brainstorming method with a few business partners, and our issue is usually that we end up with a list of hundreds of ideas, which is great work, awesome. Some of them really good. But then we go back to the opportunity we had before the design thinking brainstorming session. Sadly, I find business partners will fall back on whatever seems like it is the easiest path, what they know, and don't want to." So, it goes on. But the idea is, you're, you're selecting when you use this process.

So, Bill sort of, in a way, that story we, we tell the magical story of persevering and making it through that and, you know, getting to a very interesting outcome. What I love, Jonathan, is the honesty. So, thank you for the comment. That one thing that's hard is, you know, so many of the problems, you know, we face, and I'm sure all of you face in your personal life and your professional life, sort of that, the problem, you know, presupposes this path. And, you know, I think we come in, we say, "Oh, design thinking, you know, wander around and look at these things and dream up a new problem." And, you know, the reality is, I love, John, that well, that's super fun, and we did that, and we generally watched your idea. But then you come back in, and it's, "We got to get stuff done here. We're done with the design part." You know, we've got to select something, got to move forward with something that, that for sure solves this problem. And we'd say, the, the one of the things we espouse, and sort of, if you think about design thinking, it's largely, we're finding a problem, and then we're, we're solving that problem. Is this, there's two halves of the diagram, or on the screen right now, the two halves of what's happening there? You know, we would say on the, on the, um, product side, on the, on the production side, we espouse really, really rapid prototyping techniques. So, taking an attitude of, "How can I spend just a little bit longer, or even shorten?" If you're coming up with hundreds of ideas, hundreds of ideas, John, then I would say, shorten your brainstorming time and leave time right then and there to build some of the ideas, to make some really rough prototypes, to keep alive some of the wilder ideas, and say, "We're going to suspend this, this sort of decision-making, and we're just going to build out a couple of these and make them real." And we teach these very, very fast and simple, low-resolution prototyping techniques. And that's a fabulous skill to go through life with, is, "How do I build a quick prototype?" You know, this is something, you know, Robin, who, somebody was asking, what was the name of the person? Robin's been amazing in building the content of the programs. That's been the approach we've taken to building the courses, is, "How do we do something really, really quick?" To Jeremy's point, "Put it up on YouTube, get some feedback, and then do another one that's completely different." And that's the way we approach it. Is the question I would be asking, Jonathan, is, "How do I do, you know, 10 prototypes and do it so quickly and so efficiently that that we can do that in minutes and get some concepts to be real so we can actually have some data to evaluate?" Because I think the thing that's missing is, you can select an idea from that list that's doable for the business, but you, you, if you had a chance to compare it to some of the other ideas, a little bit as you went further, you might have some data to move forward with.

Yeah, the other thing I would say there, just on that question, Jonathan, is if you don't have the opportunity to, um, if you don't have the opportunity to create something in the middle of the interaction, then then another great thing you can do is you can at least schedule time for creating something later. We call that writing a love note to your future self. Because a lot of times, you realize, "We've got potential here, but we, and we're out of time. We're about to rush to other meetings." If, if there's no ownership and there's no sense of, uh, when the follow-up is, then there's not going to be a new conversation unless there's new information. And a lot of times, folks, teams tend to kick these decisions down the road, or like you said, just default to what we already decided we wanted to do. And the only way to change that is if someone, you know, at Amazon, they call them single-threaded ownership or single-threaded leaders. Someone takes responsibility for it. So, a great, a great tactic is, as a leader, say, "Who's going to take this and run with us in the next week? When we meet next week, what are we asking about? Are we asking about, you know, uh, click-through rates, open rates, or like, what, what do we want to know about?" And then commission someone to actually create that data. And then the other thing they'd say is, "What are they going to stop doing?" You can't give somebody something new without also kind of drawing back some level of responsibility. So, which two or three standing meetings do they not need to attend in the next week so that they can create that data? A lot of times, it's actually, it's almost like, you know, I've worked in India for a while, and there's what's known in India as the last mile problem. It's like, it's really difficult to penetrate to the last mile in rural areas, and that's where the majority of the population is. This is a last mile problem when it comes to operationalizing innovation. Ownership. What's the next step? What's the outcome? And a lot of times, with nebulous new ideas, it's kind of nobody's job. And if you allow it to be nobody's job leaving a meeting, you shouldn't be surprised that nobody does anything, right? So, to flip that script, you have to actually assign the work. And use, it's, go with enthusiasm. Who's stoked on it? Who really wants to see? Who really wants to explore? Great, you're going to own it. And we're so excited to see the data next week in our next team meeting.

Yeah, the other one. So, there's a, there's a bunch in here that follow up. So, Ray, a quick, a quick question that I think follows up on that. "What method do you suggest to sort out a lot of ideas?" So, the practical thing we, we actually teach is, is being mindful about selection process. So, as you move from ideation, you're generating lots and lots of ideas, meaning you've, you've found that that emotional insight, as Bill did. He framed up a unique challenge. "How do I make, uh, people not fearful of their experience on exercise equipment?" If you generated a lot of ideas, then you might select. You might, you might come up with more interesting selection criteria. You know, recently, um, another associate of ours, Dr. Catherine Segovia, who we teach with a lot, who's actually in the program here, she runs the practice component. We've been working with this medical company, and we've been, we've been talking to them a lot. They're generating all kinds of new ideas about this, this really interesting, um, medical product. I can't go into details on it because it's all sort of super secret. And we've talked a lot about this topic of how do you select ideas? You know, one selection criteria, if you want to go, you know, back and talk about, um, you know, Rick and Jonathan a little bit, they, you might just default to a selection criteria, "What's within our budget? What can we do?" We've talked about being more mindful of selecting ideas, you know, "What could dazzle, you know, the customer? What, what could make the customer, in Bill's case, what would make the customer feel incredibly safe? What would make the customer feel like they could start, you know, immediately on this exercise device?" Those might be selection criteria to sort through ideas. And there's no exact selection criteria. Meaning, what, what Jeremy and I do a lot in classes is, we might take a group of ideas and select with one selection criteria. We might select with the, the, you know, "What can we, what can we, what do we think we could do on a tight budget?" Great. There are a couple ideas that come to mind. Then we might take, you know, a different color, you know, um, dot, or a different color post-it, and sort of put tabs on other ones. We might select, "Which one would most likely delight the customer? Which one would actually, uh, deliver a unique experience versus our competitors?" But the point is, we're slicing and dicing ideas with multiple selection criteria. And I think too often, we move as these, these folks talked about in those quite early questions, with a singular one, like, "We've got to have a list, you know, 100. This is the best. This is, this is what we're going to start with." And what we espouse is, mix it up. Try different selection criteria. It's almost like you, you get a mosaic. Sometimes it looks like a heat map, where we're selecting with so many different criteria, and you've got all these different colors to be different things on a group of post-its, um, that you can actually sort of see potentially multiple aspects of solutions and come up with a, this is maybe something we can talk about in the, in another question as well, Jeremy, is this idea of building a portfolio. That I think another thing designers do is they think about having a portfolio of solutions, not going to that single solution early on, but saying, "How about I build a group of solutions?" How many select a bunch of different ideas based on different selection criteria? It leaves my options open, and it allows me to have different prototypes out there generating comparative data and helping me see the path forward out of vagueness to clarity. And that's what we always espouse. We have a, we have a class called D.Leadership. And I think at different times, the teams are working on two or three problem statements, each with two or three prototypes, so that it gives them, it's a lot of work, and a lot of confusion sometimes, and it gives them a lot of clarity as to a direction forward, if you will. That this idea of building multiple solutions, and the same thing with having multiple selection criteria.

I wanted to, um, I wanted to go to Ava de Breva's, uh, I hope I'm saying that right, Ava, question or comment. She said, "Customers don't know what they want. You can go ahead and ask them, right? As Henry Ford said, 'If I asked my customers what they wanted, they would have said a faster horse.'" She uses these examples: "Do you need Amazon Prime? Do you need Facebook? Do you need Airbnb?" So, "Leaving them to come up with their needs based on the problems they have doesn't seem like the most efficient approach." And Ava, if whatever you're doing for your employment doesn't work out, please come and join our team at Stanford, because we couldn't agree more. There is, we are not human-centered design is not customer-led design. It's not, it's not taking instructions from the customer. Far from it. And you have to be careful to craft, uh, experiments, really, is what we would say. It's an experimental mindset that give you highly credible data. And in another one of our sessions, you may have seen this if you've seen many of our webinars, but it's worth just repeating very briefly. Just taking as this as a case study. January 2016, the executive team of Westfield Mall in downtown San Francisco is having an emergency meeting because tenants on their fourth floor are moving out of the fourth floor. Rents are falling, and they don't understand what to do. They've got a problem with foot traffic. Tenants keep saying, "Not enough people are coming up here." And despite the beautiful frescoes and panoramic views of the city, it's not enough to drive foot traffic to the fourth floor and actually forestall the plummet of rent. And so, they've got a crisis on their hands. They had a quick brainstorm. One of the ideas that came out of the brainstorm was, "We should put a beer garden on the fourth floor. Wouldn't that be amazing?" You know, same thing about startup founders coming up like Greek gods onto Mount Olympus and drinking ambrosia. It'd be wonderful. So, thankfully, they thought, "We should at least ask people if they like this idea." They went down to the, to the lobby, to the first floor, to the food court. "If we built a beer garden on the fourth floor, gorgeous views, would you come?" Something like 85% of people said yes. And so, Ava, to your chagrin, I'm sure, they spent quite a bit of money to build out this beer garden. And it won't surprise you, I know Ava, to realize that months later, it was a colossal mishap. They hardly attracted any more foot traffic to the fourth floor. Rents continued to fall. Tenants continued to move out. And they were left scratching their heads, saying, "What did we do wrong?" Right? We came up, we brainstormed, we came up with ideas, we asked people what they wanted, and they brought us in to be a part of that post-mortem, so to speak. And one of the things that became clear is they had this great data, right? They talked to a thousand people, 850 of them said yes, "If you build it, will come." And what we challenged them on was, it's, it may be data, but not all data is created equal. And you ask people what they like. You know, is it, I mean, I've been the puppy dog intern before myself, saying, "Mister, would you sign up for a magazine? Put me down for a nickel, buddy." You know? And people say yes, but it's not really an indication of what they'll do. And we worked with the team as they tried to solve the problem in the future, saying, "How do we create environments and experiences and offers that yield more highly credible data?" You know, one of the simplest ideas that came out of this discussion: You can hire an hourly worker, put them at the top of the fourth floor escalator, outside of the, you know, elevator bank, put a bunch of curtains up, right? Not do any of the actual remodeling work or renovation work. Give the intern, you know, a pitcher of beer and a cactus. So, it's a beer garden, technically. And then put signs all over the mall saying, "Visit our beer garden on the fourth floor." It's like, anytime somebody comes up, intern form a beer, you know, "Great, it's free. Where's the, where's the garden?" "While we're still working on it, but we're so glad you're here." Right? Really quickly. You know, if the intern with his third hand, or her third hand, is just kind of clicking, "How many people are coming up?" Really quickly, they realized that that value proposition wasn't driving foot traffic. And the big question is, when people become aware of an opportunity, do they hit the fourth floor button on the elevator? And that's what they should have been measuring. And because they said, "If we did it, would you come?" they gave people an opportunity to lie to them. Customers will lie to you, not because they're malicious, but because one, they can't imagine the truth, and two, "I don't want to tell the poor puppy dog intern with the clipboard no." It just doesn't feel good, right? So, you have to, you have to design, um, interactions that give you more highly credible data than survey information. So, to all that say, just wanted to second what, uh, Dr. Ava de Brova, Professor Emeritus, mentioned: "Don't ask people what they want." We totally agree.

Yeah, and then you, you've also answered, I think, a couple other questions. Jeremy, somebody asked, "Is there, could you give an example of design thinking that doesn't involve, um, engineering?" I think it was Jessica. And which is a great. So, now you get an example that involves beer drinking. And I'd say somebody else, um, asked, I think it was Valerie, one of your questions about, "Hey, is it, do you have to use this for a product? And can you use it for a process?" And absolutely, you can use it for a process. I think that sometimes, as examples, we pick something that's like, "Oh, this is, this is clever." And a product tends to, you know, go and we can sort of tell a quick story and there's an output, there's a thing that it all goes into. Process. We have, we have amazing alumni stories. I remember one that comes to mind was an executive, one of our programs, and design thinking, that, uh, went, uh, back to American Express and redesigned, you know, the entire process for, for helping folks to get stuck in a, in a big weather event. You notice that, hey, one of the things that happens is all of our processes sort of break down in these big events, like the recent one, Hurricane Ida. People are delayed, stuck in airports, we don't have new solutions. And there's tech, different techniques for it. Um, we espouse a lot of, um, improvisational activities. So, if we're thinking about a product, you know, we, you know, Valerie, you and I are thinking about, "Hey, we have a different idea for a process. What if somebody called in, and then they got this, and then this happened?" We might act it out. I might act like the customer, and you might act like the process. Sounds weird, but I come in and say, "Hey, I'm Perry. I'm stuck in the airport." And then you would, you would respond. You'd respond. You know, we run through a scenario together. That would be one prototype. Then we try a different one. And we might even do that with, um, then bringing in an actual outside user and act as if it exists and run somebody through it with the minimum effort to sort of build anything. And a lot of times.

This results in, sort of, multiple flow charts. So, we might have a flow chart of one process, and a flowchart of another, and a flowchart of another. And we, we would sort of be able to compare which ones are faster, which ones, um, you know, result in, um, outcomes that are favorable, which ones create new questions. Yeah, we could, we could again, sort of look at those and evaluate them.

But absolutely, um, process is, is a largely, actually, if I think about so many of the student projects now, we deal with process is becoming much more, actually, what we, we use it for. If I think about, um, many, many of the projects going on in classes at Stanford, I'm just trying to, uh, to answer a bunch of questions as much as I can in the chat here. Looks like one link we shared at one point was broken. I'm trying to go in and tell people that it's fixed. Yeah. And I don't recall any questions. Somebody else was asking a little bit about, um, how to get teams to do this and how do you approach teams. And, um, I would say one of the things I'm scanning for the person's name as I look somewhere else here, but, um, um, anyway, so if you could find Jeremy, it was earlier on. But in terms of application of teams, I think one of the, um, the big ideas with David Kelly and starting the Design School, um, is that students going through our programs have a consistent approach. And I think the biggest thing to, to bringing this into an organization is, we, we see a lot of times teams have trouble when, you know, one person's ideating while the next person's trying to build a prototype, or somebody's trying to make a decision and converge while the other person, to Jeremy's point, is diverging and coming up with new ideas. And I think the teaching a consistent process to teams, if there's any sort of amazing, you know, insight to what the D-School has done at Stanford, is it's given language to students to, to have consistent process. And it's even a few of our, a couple students even commenting here, Chris, I see on there, like on the questions, um, so, but I think they could comment as, as well, if, if you ever talk to them, is like, it's really cool to have a consistent understanding because Chris, for example, is a student on there, is asking a question. He comes to a session on Wednesday mornings for this class we do, and he might be talking to an MBA student or a different student or something, but they have a consistent understanding of an approach and consistent language around it. So they can even comment on each other's work and dive in and help each other. And for teams working, that consistent understanding of a process is amazingly helpful, particularly think about the kind of work we're working on. It's uncertain work. Design is uncertain work. So, so in a way, it, it amplifies a lot of emotion. It amplifies a lot of the, the challenges with working with teams and consistency of understanding. We're doing, we're ideating right now, we're generating ideas. We'll make a decision at the end of that. We'll then prototype and test. We'll then evaluate the data from testing. It gives, um, teams the ability to work effectively with a consistent approach to problem-solving. If there's one sort of tenant with this, is we have seen it really, really effective if a team has a consistent approach to a problem-solving technique.

We have time for more questions, you think, Perry, or should we try to wrap, or what do you, what do you think? I'm going to push these. I just wanted to call it. We had, we had two folks that, um, asked questions that we wanted to definitely cover. Um, Marty, these are people that submitted, um, early questions. Um, Marty, I thought this question was great about a water utilities. So they're dealing, and she's, she's in water utilities, um, and the question was, how could I develop a way for people to use data collaboratively with the goal for them to adopt and embrace a new way to discommune, community, old practice? So she's trying to design. I, I take this and I say, wow, um, Marty is such an interesting problem. And I'm glad because it follows on the heels of that, that answer like, hey, design can be used for process. This is a process. And I think what's, what's interesting is you should approach this as, um, you know, do some of the work that David did. I would say Design Thinking 101 is go out and ask your peers. You know, ask them what kind of challenges they're having getting to, you know, decisions in the organization. What kind of challenges they're having with people's understanding of data? What kind of challenges they're having, how they're feeling about results? You'll gain some insights. And then frame up your effort. I think is to design a new process inside of the company. It's a great example, sort of a more advanced example, which I love. We're covering, um, use the input from emotion, frame up a different challenge, and then actively try, try running a meeting differently. Jeremy had mentioned this, that a lot of times we, some of the output we get is, you know, how do I run this meeting differently? And that meeting is a chance to design. And it's a thing that can be designed, just like, um, you know, the treadmill device. So, um, approach it as, how do I gather more input? You know, I think you're, you're, I can tell a frustration. I want to change this old practice. We'll gather input from employees, understand their emotional needs, understand the challenges they're having, build some problem statements around that, and then try some prototyping.

And then the other one I wanted to cover. Do you want to cover this one, Jeremy? That's such an interesting. Go ahead. Okay. Or Nair from Glendale. This is an interesting product. I could use it for my COVID times. It's a sensorized shoe insole that measures your weight. So Jeremy, at different times of COVID. Wait, let's be honest, Jeremy. You've had some problems with donuts. Both of us at different times. I've had a few excursions. That's true. Yeah. Yeah. Um, so, uh, we want to provide one stress-free metric which will provide happiness and holistic feedback on how to increase activity and improve wellness. Should it be binary? Am I doing good or not? Or should it be a more detailed report, um, with all of the metrics? So the, there, um, I have no idea. And I think you're asking this because it's the end. Seem to have no idea. And the answer is, I would, this would be a fabulous thing. The previous project, as well as fabulous projects for design thinking. It's like, I think it'd be so interesting to understand not about the metric there. That's not, if you focus, focus on what's the metric, what's metric. But I think what's so interesting is what do people want to know about their health? I mean, Perry's joking about donuts, but there's actually something. I, I would love to interview on this and be interviewed about. What are my needs? What, what are my concerns about my health on a daily basis, particularly in this, in the world we're living in now, where I'm standing in the same, you know, square meter year for the whole day? You know, how am I feeling about my health? What, what are, um, some potential, you know, things? Tell me about the lab, man. Ask a question. Tell me about the last time you thought about your health while you're standing in front of the screen, and how do you address it? Tell me that story. You could do all kinds of really fun interviews and get some insights and get some challenges. And then potentially deliver different types of information prototypes. So different types of answers on metrics and information to these individuals and get a sense of how they react to them. And I wouldn't approach this as the one thing. And the question I think is interesting to call out is looking for an answer. I think early on, I would look for, how do I create a portfolio of potential dashboards of information? How do I create dozens that I could show users? That might be a mindset to take on the very beginning. I'm not going to get to that answer. I'm going to get to a, a bunch of different potential creative answers, put them in front of users, and I'm going to continue to learn and eventually get to a subset that we want to put out as product. So that, Jeremy, I think we have just a couple minutes to cover that last bit of content.

Yeah, I would say the one thing that I would mention, just before we've got a couple of slides we wanted to wrap with, but one thing that I wanted to mention is it's, it's very important to realize conventional wisdom is often right, and sometimes wrong. And in many organizations, like you saw it with Ray, right there, is a conventional paradigm. You know, 1905 is known as the miracle year. I don't know if you're aware of this, but it's when Einstein wrote his groundbreaking works on relativity. What's interesting is in 1900, just five years earlier, Lord Kelvin had reported to the British Association for the Advancement of Science, "There is nothing new to be discovered in physics. Now all that remains is more and more precise measurement." And he was the world authority in physics, right? Which is to say, what even the experts, even world-renowned experts, are sometimes wrong. And it takes a little bit of naivete. It takes a little bit of fresh perspective. It takes a big bit of a beginner's mindset to challenge convention. And, and you shouldn't expect to challenge conviction, convention, and not experience resistance. There's a reason it's convention. Conventional wisdom is usually right, but challenging it oftentimes leads to unexpected breakthroughs. We've seen it across industries from arts to science to, uh, to law. Even challenging conventions is a really great way to do it. But don't expect to be your resistance-free path. There will be resistance there. Just as we wrap, one of the things, hopefully, that you identified in all of our answers to these questions is we don't have the answers. We are not answer guys. We are approach guys. And design thinking itself isn't an answer. It's an approach. And what we would say is, be thoughtful about your approach. And we can coach individuals on the approach. But I love, like Nair's question, who knows if it should be binary? Right? But, you know, what she, what what Perry basically advised her is, define the outcome variable. Meaning, what are you hoping somebody does? Check back again tomorrow? Share on social media? Whatever it is, right? Define the outcome variable. And then do both of those things and see which one impacts your outcome variable in the most desirable way. Wow, when I make it binary, all of a sudden people's engagement goes through the roof, right? Or when I give a detailed report, it does, right? But we're advocating an approach. And the approach that we advocate is one where we're mindful of the questions that are driving our action. A lot of people talk about the miracle year. Terry, just, you know, it's all the miracle year. Um, but the, uh, I'm trying to watch chat and talk at the same time. It's, I wouldn't recommend it. I'm like a, a cow that has multiple stomachs, except with my brain, and I'm randomly thinking of metaphors while doing this. My point is, design thinking isn't, isn't only action. A lot of people think about design thinking, they hear bias towards action, and it could just be this frivolous, random, you know, set of active flurry of activity. What we advocate is thoughtful, deliberate action where we just, where we know we're not going to know the answer until we act. So action is a must. But what action we take is informed by thoughtful inquiry. And we call it inquiry-driven design. And I'll just finish by saying, if you think about how, what's the question, how do I know which bucket to draw from? You've got to be able to answer a couple of questions. One is, what's our big unknown? And I've got this here, unfortunately, the, the, uh, on 24, someone mentioned on 24 needs to be redesigned. That's funny. Um, but it's a simple wheel where we can say, okay, what's my big unknown? Do I not know the problem I'm trying to solve? Okay, good. Or do I not know, you know, the answer to the problem I've identified, right? So, what's our big unknown? And then, what kind of thinking is going to help us make progress? Do we need to be so, once I say, okay, I'm on the blue right now, do I need to be, uh, you know, uh, making decisions? Or do I need to be generating options, right? And if I say, I need to be making decisions, great. Then where do I need to be drawing tools from? Well, I should probably be drawing tools from that converge on the solution bucket. Oh, I know these several tools to converge on solutions. Here's what's kind of behind those sliders there. But are these questions basically? But when we talk about the process of design, we're not just talking about action, and we're not just talking about a sequence or a prescription or a recipe. We're talking about a thoughtful, inquiry-led approach to taking action in order to address uncertainty, both on the solutions that we're imagining side, and also on the problems we are attempting to solve aside. So this is how we think about process. Hopefully, this has been a demystifying experience for you. Our goal is to make these tools and these mindsets accessible to somebody in product development, and somebody in HR, and somebody in accounting, wherever it is. We believe that we can bring more rigor, more fun, and better problem-solving to whatever role you might play in your organization, whatever industry your organization might be in. And we hope the tools we've shared today just wet your appetite a little bit. There's no way to go in deeply into the tools, but that's what the online programs are for. There's an amazing set of resources and tools in these programs, and we're excited to see how you use them, not only to impact your work, but also to change your life and to change the world. We wish you all the best of luck. And Jeremy, and your wrap, you didn't lose anybody. 682 of you are still here. So anyway, awesome. And we, when we say we, we are passionate about these tools being out there and you using them. And we love hearing from you with hard questions or, you know, um, these amazing, some people are sharing, if you can see all the questions, sharing how they view some of these tools, and we just find that fascinating, and it keeps us hard at work. So thank you. And thank all of you for the amazing, uh, questions. We love it. We wish we could get to all of them. We have done our best, um, but thank you so much, Perry and Jeremy. That was great. And everyone who's here with us today. The engagement was just so fabulous. It really felt like a personal one-on-one conversation, and I just really love that dynamic. Also, when you guys submit questions or, you know, expand on something, that gives us great insight about where we need to go next, so the content that we can produce and, you know, answer these, um, so that was really helpful. And thanks so much for joining us today. And we're going to sign off from Stanford. Thanks, Perry. Thanks, Jeremy. Thank you. Have a great day, everybody. You.