This is an old revision of the document!
A design concept is a collection of embodiments that completely cover all the requirements of a design situation.
By definition, concepts are quite vague.
Design concepts are often described graphically with a sketch. Here are some sample design concept sketches.
Notice how different they are from one another.
Just because many design concepts are rendered as having shape doesn't mean the final intervention's shape must be the same. Even at this stage, the structure of the design must submit to the needs of behaviour and function, and will change to ensure behaviours and functions are available in the best possible ways.
Design of complex interventions is a process of gradually seeking out the best of very many possible design interventions.
A morphological chart implies a large number of overall concepts. We call the set of all these concepts a design space.
Our job at this point in the design roadmap is to try to find the best concept in the whole space. This is usually an intractable task.
There are many ways to manage the complexity of exploring a design space. To keep things simple in this course, we will follow only one process, described below.
The goal of this step is to identify a few concepts from the morphological chart (MC) that a team believes are likely to be reasonable places to begin developing a full intervention.
Each team member will:
Refining you concept involves two tasks: identifying interaction errors, and updating the concept to correct the interaction errors.
This step must be performed at least twice. That is, each team member with identify some interaction errors, then update their concept, then search for more interaction errors, then update their concept again.
Given a concept per team member (from Step 1, above), then next step is to refine that concept by thinking about how the product will be used by a given Persona in a given SUC, and looking for interaction errors (IEs) between the concept and the users.
This step is done individually, each team member working on their own concept.
Think of watching a movie in which your Persona is using your concept in your SUC. Don't forget to consider the setup and put-away stages that precede and follow the actual use of the concept.
The mismatches you identify are IEs. Document each one. Identify at least two or three distinct IEs throughout the “movie” of your concept's usage. Read more about interaction errors.
Now, given the interaction errors, modify your concept to address those errors. Remember, an IE is always an error on the product's side of an HMIL.
IEs will arise from mismatches between what one or more of your embodiments can do, and what users expect.
This can be done in two ways.
You can change position, orientation, general size, general shape, weight, texture, or any other attribute of the embodiment.
Example 1: Designing a way to dispense food and drink, including coffee, on aircraft.
What else might you have done to improve the concept?
Example 2: Designing a food blending system.
What else might you have done to improve the concept?
You may not find any way to alter an embodiment to correct for an IE. In that case, go back to your team's morphological chart and look through the alternative embodiments for the system in question. Select another embodiment and reconstruct your concept to include the new embodiment that you believe will address the IE in question.
You may conceive of a new embodiment that had eluded you during the ideation step. If this happens:
For this step, all students are expected to study a 22-minute video of a "Deep Dive" design by IDEO. In particular, pay attention the part of the video about how the individual concepts were combined.
Once all team members have performed two iterations of refinement on their individual concepts, the team will work together to create a single concept embodying the best features of all the individual ones.
The goal is to create a single concept that can satisfy the needs of all the Personas in all the SUCs.
If you've executed all the steps properly, then all the concepts will satisfy the requirements of your project. In that case, combining the concepts should be relatively easy.
Here's how to execute this step:
There will thus be as many usage scenarios as there are members in a team.
This step is similar to Step 2, except that now you all work collaboratively in your teams to refine the final concept.
Remember to document the interaction errors you identify in this step just as you did in Step 2.
In this step of our design process, we want to identify at least some of the most likely suitable concepts that are implied by the morphological chart. (Or, conversely, we want to eliminate the least likely concepts, some of which have already been identified when we searched for inconsistent embodiments.)
Assuming you have executed ideation properly and generated an appropriate morphological chart, then a design concept is just one embodiment chosen from each row of the morphological chart. Each row of the morphological chart gives embodiments for a given system. If you have implemented every system, then you have covered every requirement. Thus, a design concept selected in this way will cover all the requirements for your design.
That is, assuming ideation is used, generating design concepts is not a creative task, but rather an analytic search task.
In the end, out of the hundreds or thousands of concepts implied by a morphological chart, we want no fewer than five, and preferably around 10, design concepts, the suitability about which we are quite confident. These 5-10 concepts will be evaluated more closely in concept evaluation stage - but for now we can use a far more qualitative approach. We can use a qualitative (i.e., “quick and dirty”) approach because the differences between the suitable and unsuitable designs will be so stark and obvious that we don't need a detailed and labour-intensive method to separate them.
There are two such broad methods for searching a morphological chart for suitable design concepts: the “brute force” method, and the “hill climbing” method. Each is described below.
A third, semi-automated method is also described, which provides Google-Sheet-supported automation for some steps of the brute force method.
The brute force method exhaustively checks every concept represented in a morphological chart. While this method guarantees that you will consider every concept in the morphological chart, it is only feasible if the morphological chart is relatively small. If it takes about two minutes to identify and qualitatively evaluate a given concept1) from a morphological chart, then applying this method to a morphological chart that captures 200 concepts will take just under 8 hours (roughly one “business day”).
NOTE FOR STUDENTS. If your morphological chart has more than 200 concepts, you should probably use the Hill Climbing method described in the next section.
Here is how you would execute the brute force search.
When we “identify” a concept, we mean that you write down the embodiments, by their ID (see the example below) that constitute it. Furthermore, spend a little time considering how the embodiments would fit together into a single design intervention. This is best done by producing a very rough sketch that shows how the embodiments would likely fit together.
Also, we can create a linear list of all concepts by beginning with the concept that includes the “first” embodiment for each system, then iteratively changing each of the embodiments in turn.
When we “compare” two concepts, we are considering them as potential designs to satisfy the requirements. That is, you must answer this question: given the requirements, which of the two concepts being compared is more likely to do so well? Remember that you must be able to justify your selection of one concept over the other; clearly everyone on the team must agree on these justifications.
If your morphological chart represents tens of thousands of millions of concepts, it simply isn't tractable to use the brute force method. Even if you have an extensive list of inconsistent embodiments, you'll still have thousands of concepts to evaluate.
Since you cannot review the entire “space” of design concepts the best you can do is to sample it. That is, you could generate a random selection of all of the concepts2) - say 200 of them - and then apply the brute force method to those 200.
There's a problem with this approach, however. The random sampling process may well select unsuitable concepts that are quite close (in the “space” of concepts) to a very good one - and you'd never know it. Random sampling of a design space is, therefore, not a good way to find suitable design concepts.
Another approach could be to pick one concept at random, then iteratively improve it by comparing it to other concepts that are not very different from it (i.e., comparing two concepts that are different with respect to only one or two embodiments and choosing the better of the two). If you keep doing this, you should eventually reach the best concept in the whole space without having to check every concept. This is the essence of so-called hill-climbing searches.
The problem with this approach, however, is that there may be “local maxima” - concepts that are quite good but are separated from even better concepts by areas of bad concepts. Since hill-climbing only seeks better solutions, it will get stuck at the local maximum and not be able to proceed to the other, better solutions. (See the Wikipedia entry on hill-climbing for more information about local versus global maxima.)3)
We need to trade-off the amount of work you have to do to search the design “space” (which we want to minimize) against the likelihood of finding the “best” concepts (which we want to maximize).
A good compromise approach in this case is to select 10-15 concepts at random, and then apply a hill-climbing search to each of them. While there is no guarantee that this approach will find the best concepts in the space, it is likely that they will all be above average. And this approach will also be very time-efficient, compared to other methods.
Here's how you run this method:
You should execute Step 2 at least 5 and preferably 10 or more times for each of the initial randomly identified concepts.
Coming up with the first batch of 10-15 concepts is best done in your teams, so that everyone agrees that the batch is a representative random sample of the entire concept space.
The rest of the hill-climbing process can be done individually. That is, each team member can take 2 or 3 concepts and perform the hill-climbing process on their own. This can parallelize (and thus speed up) the overall process.
The result of this process will be 10-15 concepts, each of which has been refined by successively looking for and addressing problems in them. The documentation for each of these concepts should include:
This method depends on a tool written as a Google Sheet to help manage the search. It can be used to implement a brute force search, or to help seed the hill-climbing search.
A complete tutorial on the tool is available at mec325_rdcg_tutorial.pdf.
SPECIAL NOTE 1: When you load the spreadsheet for use, look for the
MEC325 menu in the menu-bar. If you do not see it, try reloading the spreadsheet.
SPECIAL NOTE 2: The “brute force” method will not run if there are more than 200 concepts total - this is just to keep the sheet from taking up too many resources in your browser.
The deliverables from this part of the process are as follows.
It is vitally important to be able to justify every decision you make in this stage of the process.
If you find you have a difficult time evaluating concepts as described above, seek the assistance of your instructor. You are expected to perform these evaluations reasonably well. It is up to you to make the time to approach your instructor for help.
This step of the process is best done in one, long sitting. It may be difficult to organize the time, but you will likely work faster and better if you can do the entire exercise in one (preferably) or two sessions. Do not work on this in short bursts punctuated by distractions or other tasks - it is likely to lead to terrible results.
Consider the example discussed in the ideation page and reproduced below. We will consider the brute force search in this case. This is not a full example, but it is intended to show some aspects of the method.
Example problem Design problem: You have to design a joint for a detachable robotic arm. It's basic systems are:
Here are some ways to embody these systems. (This can be thought of as a textual version of a morphological chart. However, do not think that you can just list embodiments this way. You have to create a proper morphological chart.)
A. Structural system
B. Connection/disconnection system
C. Power system
D. Data system
This set of embodiments represents 270 total concepts. So we could use the Brute Force method in this case.
We start by taking the first 10 concepts that do not have inconsistent embodiments. Normally, this would include concepts A1-B1-C1-D1 through A1-B1-C2-D5.
However, say we have decided that C2-D2 would be an inconsistent embodiment because of the RF noise between the magnetic connector in the power system and the RF receiver in the data system. So we remove concept A1-B1-C2-D2 and replace it with the next concept, A1-B1-C3-D1.
Now we consider the next concept, A1-B1-C3-D2, but we have C3-D2 also listed as an inconsistent embodiment, so we discard it and go on to A1-B1-C3-D3.
We then compare A1-B1-C3-D3 to each of the 10 concepts currently in our list and look for a concept that we believe will be less suitable than it, with respect to the requirements.
Since all the concepts so far have A1 and B1 in common, we can start by focusing on C3 and D3. While induction transmission of power and IR data communications both have disadvantages in space application5), they pose a distinct advantage together. In conjunction, they remove all need for direct, fixed connections between the robot elements. This will significantly reduce the physical complexity of the connector that we are designing because with C3-D3. Reduced complexity (i.e., increased simplicity) will generally reduce cost and increase reliability. So concept A1-B1-C3-D3 has certain merits.
In this example, we cannot really judge which concept in our list is the worst compared to A1-B1-C3-D3 because we do not have a precise set of requirements. (This underscores how important it is to have a crisp and complete set of requirements during this stage of the design process.) Still, we may argue that concept A1-B1-C1-D1 is significantly worse than A1-B1-C3-D3 because the former will require higher precision connection (especially during the connection and disconnection operations) than the latter.
So we (a) discard A1-B1-C1-D1 for A1-B1-C3-D3, and (b) note why the latter is preferred to the former.
NOTE TO STUDENTS. You will have a usable set of requirements, so you will be expected to judge much more precisely why a given concept is better or worse than some other concept.
We continue in this fashion until we have checked every possible concept.