After sensing the gap, the first step in the design process is to define the problem. I'd like to think of problem definition in two parts. First, I'd like to create a single statement that captures the scope of the gap that you're trying to address. And then I'd like to develop a more detailed set of user needs that relate to the problem. We're going to talk now about that first piece, that is about creating a single statement that characterizes the scope of the problem you're trying to solve. Let's take the example of the ice cream scoop. Now, if we just say, design a better ice cream scoop, that carries with it all kinds of assumptions about the solution that we're, that we're going to develop. We've talked about a scoop, while scoop implies a geometry. It implies, perhaps, a, an action of the user's hand. It even implies that we're gonna be holding something in our hand. And, maybe we don't want to make all those assumptions about the solution. Maybe we want to think more broadly about the problem that we're, we're trying to solve. And so, I recommend that we go through a deliberate process in which we take the initial problem statement, like design a better ice cream scoop, and we systematically consider whether we might generalize that statement or possibly make it more specific. As a first step, I'd like to characterize the, the problem statement, and some, in terms that are more neutral about the form of the solution. So, for instance, we might, instead of saying, design a better ice-cream scoop, we might say, how do we create a better handheld tool for forming balls of ice-cream from a bulk container? And now we are making an assumption when we say that, that the tool would be held in the hand. But we aren't making any assumption about the mechanism by which we might form the ball. We are making an assumption that we're after a ball however, and maybe that's even more specific than we want to be, But at least we've started with a statement that's relatively clear about what the design problem would be. Create a better hand held tool for forming balls of ice cream from a bulk container. That's just a starting point. Then what I'd like to do is use a technique called The Five Why's, and this is a kind of a borrowing of a technique that comes out of the total quality management movement. Let me show you how it works. So we start with that first statement, create a better hand held tool for forming balls of ice cream from a bulk container, and we asked the question. Why would we want to do that? That is, what would be the motive for doing that? And an answer to that might be, well, we want to better dispense single servings of ice cream at home. Really? Why would we want to do that? That's the second why. Well, we want to provide convenient access to tasty deserts at home. We might then ask, well, why would we want to do that? Well, we'd like to enjoy meals at home more often. Hm. Why would you want to do that? Well, because we want to build family togetherness. Alright? Now you see how, by asking a series of whys, or why would you want to do that. By asking that question repeatedly, we go from a very focused problem statement, Can, in what way might we create a better handheld tool for creating balls of ice cream from a bulk container, To a much more general statement, in what way might we build family togetherness? Now we can also go the other direction and we can ask, we could ask how might we. Create a better handheld tool for forming balls of ice cream from a bulk container, and one answer might be that we could improve the ergonomics of the handheld ice cream scoop. And so we could state our design problem more specifically as, in what way might we improve the ergonomics of handheld ice cream scoops. Then we could say, well how would we do that? And we could say well, maybe we could find a better way to transmit axial force from the user's arm to a tool and that would state the design problem even more specifically. In what way might we better transmit axial force from the user's arm to a tool? So you see what we've done, we've started with just a stake in the ground, an initial point of view, a statement of the design problem which is, in what way might we create a better hand-held tool for forming balls of ice cream from a bulk container? And by asking a series of whys to get at the motives for solving that problem, We've been able to create more general statements of the design problem. And by asking a series of hows, we've been able to create more specific statements of the design problem. Put together, Those statements for a hierarchy, From most specific to most general. Now in fact, we could keep. We could just keep asking why. And eventually we'd get to some very basic human needs like, in what way might we all be more happy? Or, in what way might we find food and shelter? And we get to very basic human needs. But in general any particular initial statement of a design problem can be made more general by asking why and could be made more specific by asking how. And so that initial statement is, you can think of as being situated within a hierarchy that goes from very specific to very general. Now lest you think that this technique would only be applied to physical devices. Let me give you an example from a problem taken from healthcare, Which you could think of as a design problem. One of the key challenges in healthcare is to get healthcare providers to wash their hands. It's been known for more than a 100 years that if you wash your hands in a health care setting, you reduce the transmission of disease. And yet, it remains an elusive challenge to get health care providers to, to wash their hands on a consistent basis. So you might form a problem statement that might, might be, in what way might we increase hand washing by physicians and nurses? That's the initial problem statement. Then you could ask, why? Well, because we want to reduce the transmission of germs among patients. Well, why do you want to do that?' Because we want to reduce the incidence of serious infection in hospitals.'Why do you want to do that?' Because we want to improve health outcomes for patients in hospitals.'Why do you want to do that?' Because we want to improve the quality of life for members of our community. So we've taken that initial problem statement and we've made it more general, all the way as general as a statement of, in what way might we improve the quality of life for members of our community?' Similarly, We can, we can make that statement more specific. How might we in. Increase hand washing by physicians and nurses. Well, we might be able to reduce the time and effort required to wash hands. How might we do that? Well, we can locate hand washing stations closer to patients, and so even that initial statement about, in what way might we increase hand washing by physicians and nurses. Using the five whys technique can, can, result in an articulation that's more general or more specific than the initial problem statement. Now the whole point of doing that, the whole point of constructing a hierarchy of different problems statements is to force you to think about what is the right level of abstraction for me to use in tackling this design problem. Now let me give you the, the arguments for making the problem more abstract and for making it more specific. The argument for making the problem, for taking on a problem statement that's more general, or higher level in the hierarchy. A higher level of why is that it gives you as the designer more options, it opens up more possibilities for how you might address the gap. So instead of thinking narrowly about how I'd create a better way to form balls with a handheld tool, I think more generally about how could I give, how could I deliver nicely formed serving units of ice cream in the home. And that might open up the possibility of approaches that don't even involve a hand held tool. For instance, an approach that involves preformed units that are distributed in a package that, that keeps them separate, for instance. That solution wouldn't be accessible to a designer who's focused narrowly on the question of how to create a hand held tool. Now, on the other hand you don't want to go too general. And, the reason for that is, at, at some point in that hierarchy of problem statements, You reach a level of abstraction that's so general that you as a designer, don't possibly have the resources at your disposal in order to make a measurable difference on that problem. So for instance, once it's called building family togetherness, Once the problem statement is framed that way, you as a designer may have very difficult time, making reasonable headway or even having the relevant skills and capabilities to address that challenge. And in fact you can work very hard at that, around issues of dessert and family, and, and eating time and so forth, and make no measurable difference in the outcome. And so, in general, My advice is to make the statement of your design problem slightly more general than you are comfortable with, but not so general that when you look at that statement you say, you know, I have no way of really influencing the outcome, or creating a measurable difference in a problem that's stated that broadly. So, to reiterate, the basic method of using five Y's in order to create the initial statement of the design problem, is to first just state your, your, the challenge as you perceive it. In what way might we create a better X or build a better Y. Just state it the way you've initially conceived of it and then systematically ask the five why's to make that statement more and more general. And ask a few how's as well in order to make that statement more focused and more narrow. And then, look at that hierarchy of problem statements and make a decision as to, what's the right level of abstraction, Such that, I've left open the possibility of a broad range of solutions, and yet I've kept the problem focused enough that I, as a designer, can make a measurable impact on the outcome.
