Home | Design Overview | Problem Definition | Solution Exploration | Prototyping | Solution Refinement | Case Studies
Problem Definition: What needs solving?
|
The first step in the design process is defining the problem we want to solve. This step is critical because without a clear definition of the problem, competing solutions can't be successfully evaluated. So what does a clear definition even mean? Well to answer that question we'll start with our first example of the design process.
We'll imagine that we're at the park with our dog after a long day of work. We're tired, but we love your dog and we want to play with it. It loves playing fetch, but when it brings the ball back to us, it drops it 10-20 feet away from where we are, then looks at us waiting for us to get the ball and throw it. This means that every time we want to throw the ball for our dog, we have to go get it.
The next few sections will go through the Problem Definition process to help us have a clear structure to describe the problem that we're trying to solve.
We'll imagine that we're at the park with our dog after a long day of work. We're tired, but we love your dog and we want to play with it. It loves playing fetch, but when it brings the ball back to us, it drops it 10-20 feet away from where we are, then looks at us waiting for us to get the ball and throw it. This means that every time we want to throw the ball for our dog, we have to go get it.
The next few sections will go through the Problem Definition process to help us have a clear structure to describe the problem that we're trying to solve.
What is the Problem?
So we have a situation, but the problem we're trying to solve is still ill-defined. Different people approaching this situation will see different problems. In a design process applied to a personal problem, its up to the individual to decide what the real problem is. When designing solutions for others its important to understand what the needs of the people who will participate or use the solution are.
For the situation described above, perhaps the problem could be identified as a not having taught the dog well enough how to play the game of fetch. Another possible problem could be that we're tired when we're playing fetch with our dog. A third problem could be that we have to go get the ball every time. Its clear that each of these problems have a different set of needs and solutions for each case will be completely different. If the problem is that the dog needs to learn to play fetch better, then the solution might entail some form of training. If the problem is that we're too tired, the solution might involve changing our schedule or getting in shape. If the problem is that the ball doesn't come back to you when you throw it, maybe the solution involves looking into how you're playing fetch. Some of the solutions to solve these problems may overlap (e.g. the ball needing to return every time could be solved by training the dog to bring it back) and some might not (no amount of schedule changing will make it so the ball comes back to you). In order to ensure that the solution addresses the real problem, its important that the problem definition is chosen very carefully. For the purpose of this example we decided that the real problem isn't how tired we are, or how well trained the dog is, instead the real problem is the fact that we don't get the ball back when we play fetch, so we can't throw it again. |
Solution Requirements
Once the core problem has been identified, the next step is to define what the solution needs to accomplish. Its important that these needs don't have solutions baked into them. They should represent a solved problem, but not what was done to solve the problem.
Often its helpful to use the phrase "the solution should ... " and just fill in the blank. By describing the solution in this way we can create requirements that aren't specific to any one particular solution. This is important because designers likely think of one solution when they first hear the problem, but at this point of the process its not wise to narrow the possible field of solutions. Most of the time, the first instinct is only partially correct, and the best designs are born from a combination of many ideas. The following are some of the requirements we used for the fetch problem defined in our last section. For the readers benefit we included a brief description about why we chose each requirement.
Lastly, sometimes at some later point in the design process, we realize that there are requirements that we did not clearly specify, but that are important. That's OK! It's totally acceptable to come back to this stage, add requirements that make more sense now that we've thought about the problem more, and then proceed through the next steps again. |
When coming up with solution requirements its important that they are general to the actual needs of the problem (the solution shouldn't be baked into the requirement), but specific enough that they can be measured in one way or another. Its also important to pay attention to how important each requirement is in relation to other requirements. This is because often different requirements will compete with each other and therefore favor one solution over another. For example a solution to our problem that involves bringing more balls to the park might be less expensive, but harder to add to the routine when compared to getting professional coaching to teach our dog to bring the ball all the way back to us. Understanding the importance of each requirement helps us to figure out which design might be better when we have competing requirements. In the next step of the design process we'll talk about how we go from this well-defined problem to a set of solutions that we can start to evaluate.
Some specific tools (e.g. worksheets to help with problem definition) are included in the "Case Studies" at the end of this module and can help you to even more clearly define your problem before you begin working on how to solve the problem.
Some specific tools (e.g. worksheets to help with problem definition) are included in the "Case Studies" at the end of this module and can help you to even more clearly define your problem before you begin working on how to solve the problem.