Home | Design Overview | Problem Definition | Solution Exploration | Prototyping | Solution Refinement | Case Studies
Prototyping: Simple, representative, Models
|
Now that we've selected a few potential solutions, we need a way to help us decide which one will be our final solution. The difference between this step of the design process and our previous solution exploration step is that now we are going to develop more detailed ideas. To this end we're going to need to be able to test each of our potential solutions. The problem with this however is that often each solution represents a good amount of work, so to actually test them each extensively would take too long. This is one reason why prototypes are a critical piece of the design process.
Prototypes are simple-to-implement versions of the solution that allow us to test aspects of the potential solution, so we can better understand and see potential problems. Prototypes should be relatively easy to make, simple to test, and focused on a few aspects of the overall solution. For example in the picture below (which is a stock photo and we're not even sure of the purpose of the prototype) its clear that the prototype isn't meant to test the final way the components (e.g. pencil, eraser, and circuit board) will attach to each other. Instead it seems to be testing the overall idea of having the circuit board mounted to the pencil and eraser. The prototypers didn't worry about all of the details, because they needed to evaluate the general function. Quick-and-dirty prototypes are completely acceptable if they teach you what you want to know.
Along with our prototypes we need to develop tests to measure the performance of our solutions. This may at first seem difficult, but in fact we've already come up with our requirements and thought of ways to measure how our solution fulfills those requirements in the problem definition stage of the design process. This means that our prototype evaluation can reflect exactly those requirements. In the following section we'll show prototypes for the problem of playing fetch with our dog, and show how by using our initial requirements we can test each idea and decide which one to go ahead with.
Prototypes are simple-to-implement versions of the solution that allow us to test aspects of the potential solution, so we can better understand and see potential problems. Prototypes should be relatively easy to make, simple to test, and focused on a few aspects of the overall solution. For example in the picture below (which is a stock photo and we're not even sure of the purpose of the prototype) its clear that the prototype isn't meant to test the final way the components (e.g. pencil, eraser, and circuit board) will attach to each other. Instead it seems to be testing the overall idea of having the circuit board mounted to the pencil and eraser. The prototypers didn't worry about all of the details, because they needed to evaluate the general function. Quick-and-dirty prototypes are completely acceptable if they teach you what you want to know.
Along with our prototypes we need to develop tests to measure the performance of our solutions. This may at first seem difficult, but in fact we've already come up with our requirements and thought of ways to measure how our solution fulfills those requirements in the problem definition stage of the design process. This means that our prototype evaluation can reflect exactly those requirements. In the following section we'll show prototypes for the problem of playing fetch with our dog, and show how by using our initial requirements we can test each idea and decide which one to go ahead with.
Prototype 1: A bag of Balls
|
The first of our three selected potential solutions was to bring a bunch of balls with us to the park so we could throw multiple times before we went to pick them up. The prototype of this solution is pretty easy, we just need to get a couple of balls and throw them. After we do that we just need to evaluate based on our requirements. Did having multiple balls allow us to play for longer with our dog without getting tired? Did it help our dog have fun? How hard was it to add to our routine? And how much did it cost? It is important to be able to assign actual numbers to these questions. If turning the requirement into a question is too vague, we can break the requirement into multiple ideas of how to measure/estimate that requirement. Examples of this process are included in the case studies.
Because this is a pretty straightforward solution to the problem it might be possible to test/measure each aspect of the solution, which can happen. However, at this point we haven't perfected the solution, e.g. we don't know what the right number of balls is, or what the best way to carry them is, or if there's a way that throwing multiple balls could be more fun for our dog. This first prototyping phase just lets us have some measure of how good the solution is. |
|
Prototype 2: Ball on a string
|
The second solution is to put a ball on a string, so that when we throw it, and our dog drops it away from us we can pull it back the rest of the way without having to get up to get it. In the solution exploration phase of the design this solution seemed to be great. It scored a 7 which was good enough to tie with the "bag of balls" for the best idea. To prototype it, we tie a string around the ball and throw it. And, it turns out tying a string to a ball makes it much harder to throw. And, it makes it so we can only throw it as far as the string is long. On top of that the ball doesn't bounce like it did before which makes it much less interesting for our dog to get.
This often happens with prototypes. When we were exploring solutions, we didn't have a real idea of the implementation of a ball on a string, we just liked the idea that the ball would come back to us, without any external intervention. However, the realities of the solution presented themselves in the prototype and help us to see the weaknesses in this design. This isn't to say that this design is immediately bad. Maybe our prototype isn't an accurate representation of the imagined final solution, maybe there's changes that we make to this solution and test again, but by creating a simple quick model we can tease out some of the difficulties that we didn't see before we had something "real" that we could evaluate |
Prototype 3: Amateur Instruction
|
Our third potential solution that we came up with was to put our dog through an amateur dog training program. This solution was apparently the worst, with a score of only 6. This solution also is the most difficult to prototype, how do we make a prototype of amateur dog training? This is one of the difficulties with process solutions, especially ones that require extended lengths of time to show results. This is one of the places in the design process that its important for the designer to use their discretion wisely. Its good to make quick easy prototypes because they give us ideas of how a solution may perform, but sometimes a quick prototype can misrepresent a solution's performance.
For this potential solution we decide that we'll go through a weeks worth of YouTube tutorials to teach our dog to bring the ball back to us, and decide from there if we'd continue. To make it effective we have to replace some of the time that we'd normally play fetch with our dog with training time, and our dog definitely doesn't have as much fun as before. Its also more tiring for us to train our dog then to just play fetch. In the short term, it may seem that this solution isn't going to pan out, but this is where the designer has to make an important decision. Do the expected long-term results outweigh the measured short-term results? Is it worth it to press forward with this potential solution even if it underperforms right now? |
|
Decision and Moving forward
After a series of tests and prototypes its important to make a decision on how we are going to move forward. Sometimes it can be tempting to stay in the prototyping and testing stage for a long time, trying to tease out all of the differences between our potential solutions. However, in the absence of an obvious difference, the progress made by selecting a design often outweighs the value of extensively testing each solution to try to understand exactly how it performs. Especially because until you move forward with fully implementing one solution, its almost impossible to understand its performance exactly.
Once a solution has been selected, then its time to develop that solution and get it ready for deployment. This means breaking it up into small parts that can be evaluated individually and improved.
For the problem we're working on, we decide that even though bringing lots of balls seemed to be the best in the short term that we think amateur dog training holds the most promise as a long-term solution, and so we are going to move forward with it. This means that we now need to break it up into different parts that we can work on. This could look like doing research into which training programs are the most effective, how much time we need to dedicate each day, and what kinds of rewards work best for our dog. If the decisions aren't obvious we can use a miniaturized design process on each of these sub-problems, to create the best solution we can in the time we have.
Once a solution has been selected, then its time to develop that solution and get it ready for deployment. This means breaking it up into small parts that can be evaluated individually and improved.
For the problem we're working on, we decide that even though bringing lots of balls seemed to be the best in the short term that we think amateur dog training holds the most promise as a long-term solution, and so we are going to move forward with it. This means that we now need to break it up into different parts that we can work on. This could look like doing research into which training programs are the most effective, how much time we need to dedicate each day, and what kinds of rewards work best for our dog. If the decisions aren't obvious we can use a miniaturized design process on each of these sub-problems, to create the best solution we can in the time we have.
Other types of Models (besides prototypes)
It's important to realize that the prototype has stood in the place of an actual solution in order to help us evaluate that potential solution. Hopefully, calling this a "model" of our real solution isn't too much of a stretch of the imagination, and makes some sense. However, there are other ways to get models that can tell us if our potential solution is good or not. Can you think of some ways?
Many other methods to make a model require additional geometric, analytical, mathematical, or physics-based models. If the system is simple, these may not be necessary and prototypes may provide all of the information we need. If the system is complex, then it is more likely that we will be able to save time, effort, and have greater success by using these additional models to help us evaluate potential solutions. This is one of the main reasons for students to continue on in their education (undergraduate or even graduate degrees) and pursue careers in the STEM fields where specific knowledge and skills will only improve their ability to come up with better solutions to real-world problems.
Many other methods to make a model require additional geometric, analytical, mathematical, or physics-based models. If the system is simple, these may not be necessary and prototypes may provide all of the information we need. If the system is complex, then it is more likely that we will be able to save time, effort, and have greater success by using these additional models to help us evaluate potential solutions. This is one of the main reasons for students to continue on in their education (undergraduate or even graduate degrees) and pursue careers in the STEM fields where specific knowledge and skills will only improve their ability to come up with better solutions to real-world problems.
