Home | Design Overview | Problem Definition | Solution Exploration | Prototyping | Solution Refinement | Case Studies
Solution Exploration: How can we solve the problem?
|
With a clearly defined problem that includes our fundamental requirements we can now start creating possible solutions. This part of the process is often the least formal, because generally when exploring the possible solutions nothing is off the table. However, there are two main steps. The first is to generate lots of ideas. The second is to evaluate the ideas, AFTER we have completed the idea generation, not before or during.
Verbs that are often used to describe these two steps are "diverge" and "converge." The picture below is our best attempt to represent this idea, but basically we start with a couple of ideas for what the solution should look like (the points on the left) and then we want to have those ideas diverge or fill in the space between ideas. This gets us to a ton of different ideas, and at this point we don't want to reject or think too hard on the feasibility of any of them. "There are no bad ideas" is a common mantra when brainstorming about anything, and it applies here. Once we've filled in that space however, we need to choose which among the possible solutions shows the most promise, and converge on the solutions that we think are worth pursuing further.
In this section we'll share a couple of methods that can be useful for diverging and converging. These aren't the only methods to come up with potential solutions, but they've proved useful in the past (both to us and to many, many practicing engineers).
Verbs that are often used to describe these two steps are "diverge" and "converge." The picture below is our best attempt to represent this idea, but basically we start with a couple of ideas for what the solution should look like (the points on the left) and then we want to have those ideas diverge or fill in the space between ideas. This gets us to a ton of different ideas, and at this point we don't want to reject or think too hard on the feasibility of any of them. "There are no bad ideas" is a common mantra when brainstorming about anything, and it applies here. Once we've filled in that space however, we need to choose which among the possible solutions shows the most promise, and converge on the solutions that we think are worth pursuing further.
In this section we'll share a couple of methods that can be useful for diverging and converging. These aren't the only methods to come up with potential solutions, but they've proved useful in the past (both to us and to many, many practicing engineers).
This figure represents the solution exploration step. We'll start with a few ideas (represented by the three dots on the left side) and from those ideas we generate a whole bunch of ideas. Then we converge, taking ideas that we've generated and combining/picking the best ones to get to the ideas we will continue the design process with (purple and green dot on the right)
|
Solution Generation: Method 635
Method 635 is a creativity technique that helps to get groups thinking individually and together. Its better then just traditional brainstorming because it requires input from everyone, not just the most vocal participants.
Its called 635 because the model has 6 individuals working to generate ideas. First everyone creates 3 potential solutions. This could include just a list of ideas, or often it's better if it includes sketches and any other info that is helpful to understanding the potential solution. Then everyone passes their ideas to another member of the team. Those team members must take the ideas handed to them, and add something to it. It could be a completely new idea that is inspired by what they've seen. Or it could just be a minor modification of the existing idea. This continues until everyone has had a chance to build on each other's ideas. This is where the name 635 actually comes from, 6 people in the group, starting with 3 ideas each, then iterating 5 times. With a larger or smaller group the same process can be followed, often resulting in a diverse potential solution set. |
Solution Generation: Recombination Table
Recombination tables are used to take sub-ideas and combine them in new ways to generate new overall solution ideas. A recombination table is organized with necessary requirements (e.g. "the solution should") listed on the left side, and ideas for how to fill those requirements in the body of the table. Then by combining each of those sub-ideas lots of different solutions can be developed. This could be done as a follow-on to 635 method, or by itself.
The picture on the left shows a recombination table for a vehicle that works similarly to a bike. (One of the generated solutions is a bike, the other is a battery assisted 3 wheel.) |
Solution Generation: Brainstorming
Most people understand the idea of brainstorming, however there are a few important principles that are usually emphasized when talking about brainstorming during the solution exploration phase (these come from a paper written by a man named Osborn in 1963):
|
Solution Evaluation: idea Potential
Now that we've developed a ton of potential solutions we need to find a good way to know which ideas we're going to pursue and develop into actual solutions. There are many ways to make this decision but we will propose only one. This method is simple, but effective. We start by creating a table with requirements (e.g. "solution should") on the left side, and potential ideas along the top. Then based on intuition or any basic models that you may have, you make a decision and mark whether its good (1), bad (-1), or neutral (0). Once the table is filled out we can sum each column and the sum will show which ideas merit developing, and which don't.
A simple addition that makes this method a little more powerful is to include the importance of each requirement in the calculation of the evaluation. This can be done before summing the column by multiplying the value (1,0,-1) by the importance of the requirement (often ranked 5-1 where 5 is the most important and 1 is the least). This results in a weighted sum so if the idea is good for all of the least important requirements, but bad for the most important one, it won't score as highly as one that is neutral for the least important requirements and good for the most important one. An example is included below.
The following table shows a set of ideas that we came up with for our example of playing fetch with our dog. We added a requirement that our solution be inexpensive because as of the creation of this module, the author is a broke college student. The total is the sum of the columns weighted by the requirements ranking (where the value for ranking is shown on the far left and is assigned by the designer).
The highest scoring ideas were to use a ball on a string and to bring a bunch of balls, with amateur dog training coming up a close 2nd. It should be noted that at this stage we haven't made a complete idea yet. We've created a general idea that we can fill out once we decide its worth it to investigate. We don't know what a 'bunch' of balls is, and we don't know what a 'string' is, they are just general ideas. In the next stage of the design process we'll develop some tests and prototypes to see which of these 3 solutions is the best.
Finally, it's OK if at this point your intuition disagrees with any of the rankings. This can either mean that you should add additional requirements that you didn't understand before. Or simply that you should keep some ideas around, even if they scored poorly. This may especially be true if you are an expert in the problem-domain, but are having a hard time initially quantifying what matters in terms of requirements. Although this is a structured process, the result will always require some subjectivity, and some creativity. Don't be afraid to adapt concepts and update requirements. This is not to suggest that we should deceive ourselves by making unrealistic or unimportant requirements, simply that as we understand the problem more, we may add or remove requirements, or even change their importance ranking.
A simple addition that makes this method a little more powerful is to include the importance of each requirement in the calculation of the evaluation. This can be done before summing the column by multiplying the value (1,0,-1) by the importance of the requirement (often ranked 5-1 where 5 is the most important and 1 is the least). This results in a weighted sum so if the idea is good for all of the least important requirements, but bad for the most important one, it won't score as highly as one that is neutral for the least important requirements and good for the most important one. An example is included below.
The following table shows a set of ideas that we came up with for our example of playing fetch with our dog. We added a requirement that our solution be inexpensive because as of the creation of this module, the author is a broke college student. The total is the sum of the columns weighted by the requirements ranking (where the value for ranking is shown on the far left and is assigned by the designer).
The highest scoring ideas were to use a ball on a string and to bring a bunch of balls, with amateur dog training coming up a close 2nd. It should be noted that at this stage we haven't made a complete idea yet. We've created a general idea that we can fill out once we decide its worth it to investigate. We don't know what a 'bunch' of balls is, and we don't know what a 'string' is, they are just general ideas. In the next stage of the design process we'll develop some tests and prototypes to see which of these 3 solutions is the best.
Finally, it's OK if at this point your intuition disagrees with any of the rankings. This can either mean that you should add additional requirements that you didn't understand before. Or simply that you should keep some ideas around, even if they scored poorly. This may especially be true if you are an expert in the problem-domain, but are having a hard time initially quantifying what matters in terms of requirements. Although this is a structured process, the result will always require some subjectivity, and some creativity. Don't be afraid to adapt concepts and update requirements. This is not to suggest that we should deceive ourselves by making unrealistic or unimportant requirements, simply that as we understand the problem more, we may add or remove requirements, or even change their importance ranking.