Ideation is a creative process of finding ways to provide a function in a given situation.
Ideation, as the term implies, is about forming ideas. Ideation is generally a cognitive task – it's something you do with your brain. Some people ideate best alone, others work better in teams.
Within the scope of engineering design, ideation is about looking at small groups requirements of a problem and coming up with a short description of the general class of product that can satisfy the requirements - in other words, finding embodiments for specific functions. Fortunately, by the time we're ready to execute concept design, we have already partitioned our requirements into groups in the system design, so we can use systems as the foundation for ideation.
Coming up with design concepts that address all the requirements of a design problem is hard, because you have to think of so many different requirements at once. The human brain isn't very good at dealing with more than 7 things at once. There's usually far more than 7 requirements in a given design problem1).
There's a few things you can do to manage this cognitive “shortcoming.” One we've already seen in system design is to use nested systems and limit the requirements at any given hierarchical level to only those that impact the (sub)system as a whole.
System hierarchies don't help much, however, when you have to execute concept design, because in concept design you have to map requirements (ends) to the means to achieve those ends.
Fortunately, you can use ideation - coming up with possible embodiments for individual systems - then trying to combine those ideas together to form concepts. The advantage of ideating before identifying actual concepts is that you are focusing your brain on tasks it's good at, and then using straightforward - in fact, rather boring - methods to assemble all the possible concepts. What's more, using ideation tends to produce many, many more concepts than just conceptualizing alone.
On the one hand, we need to come up with tentative design interventions that completely cover all the requirements; on the other hand, however, the human mind simply cannot keep that much information in active memory at once.
Ideation is a method primarily for handling creative problems that include 7 requirements (that's PCs, FRs, and constraints - total), because that's the limit of the number of “items” that the average human brain can keep in mind at once. This means that all but the most trivial design problems can benefit from ideation.
Ideation is the first step of the concept design task, and so depends on:
Ideation is more than just coming up with ideas. Because of the complexity of most design problems and the importance of teamwork to get things done effectively and efficiently, some structure to the process is necessary.
In a nutshell, the process runs like this:
Details of the process are given below.
Every team member should try to ideate embodiments for every system. However, to keep things organized, one person should be in charge of synthesizing and documenting the embodiments for each system.
The first task, then, is to decide as a team who will be in charge synthesizing embodiments for each system.
Divide up systems among your team. Ideally, one system should be the sole responsibility of one person. However, depending on how many systems there are, one person may have to be responsible for more than one system.
If there are fewer systems than team members, then assign the more complex2) systems to two or three team members. If there are more systems than team members, then assign two or more of the simpler systems to single team members.
Also, remember to balance project work dynamically within your team.
Some notes are warranted regarding the non-functional requirements.
Beware coupled requirements. Rarely do requirements form a perfect hierarchy (from PCs, to FRs, to constraints). They are often coupled together. For instance, the weight of a vehicle is coupled to the power it can generate, because as a general rule, the more powerful the power plant, the heavier it is, which will increase the weight of the vehicle. This coupling shows up in your requirement diagram as links between requirements that span different subtrees within the requirement hierarchy. As you perform system design, make sure you're checking for those coupled requirements, and including those that connect to the FRs that fall within the system.
Every team member is responsible for all PCs. A product characteristic usually applies to every element of a design, but in different ways. Consider producibility: every part of a product must be producible, but some may have to be more producible than others. Auto transmissions, for instance, generally last longer than taillights, so one must be able to produce more taillights than transmissions for the same sized fleet of vehicles. This means that, as a rule, every team member is responsible for every PC; but it's up to each team member to determine how the PC will manifest in the system, assembly, or part for which they are responsible.
PCs without FRs have “universal” constraints. A product characteristic that has no corresponding FRs will still have constraints. Those constraints may well apply, at least to some degree, to every system in your design intervention - that is, they are essentially “universal” constraints that apply throughout your design. So be careful to check for those constraints, and make sure they're accounted for in all systems. Say, for example, your product has an external requirement (driven by human factor capabilities) that it cannot weight more than 10kg. Every part of the product contributes to the overall weight, so the weight of every part must be constrained and coupled to the weight of every other part so that the total weight satisfies the constraint.
Responsibility requires collaboration. You cannot just design your system without also considering the impact that your design will have on other systems. In real life settings, different systems are the responsibility of different designers or even teams of designers. If you're in charge of engine design, the way you treat “producibility,” for instance, within the engine system cannot incidentally render the passenger system unproducible. To help ensure you're doing your job well without interfering with your teammates' jobs, you have to collaborate, to keep one another informed of the choices you have and the decisions you make. And you have to be willing to seek the solution that results in the best overall design intervention, even if that means choosing a sub-optimal option for your own system, assembly, or part.
Now every team member individually uses various creativity methods to come up with as many embodiments as possible for as many systems as possible. You may find it necessary to do research to find different principles and technologies you can use for your embodiments. Make sure you include that research as part of your ever-growing situation scan.
Details for doing this, what embodiments are, and different creativity methods that can help you ideate are given in the page on embodiments.
Remember to avoid thinking about structure; instead, focus on the functions that each system serves in your intervention.
Say you're designing “a way to lift people and cargo inside a building”.
There will probably be a “lifting system”. How many different principles and technologies can you think of that can do that?
Set a deadline for completing this step. Make sure every team member has time to devote sufficient time to the activity.
Once everyone has developed embodiments, get back together in your team to create a single morphological chart.
Exchange embodiments so that the person in charge of System A has all the embodiments for that system, the person in charge of System B has all the embodiments for that system, and so on.
Each team member now reviews all the embodiments for their system, and integrates them into a single list. Eliminate duplicates, and any outrageous or entirely unfeasible embodiments. Try to get the broadest possible range of embodiments that are, to the best of your knowledge, feasible and possible given the scope of your project as defined by the design brief and your situation scan.
Also consider all the Personas. Embodiments that cannot accommodate your Personas will lead to poor designs. However, also remember that multiple embodiments may be used to cover broader ranges of Personas. For instance, a blinking light may not be a good embodiment for a Persona with weak vision; but a blinking light that beeps also may work. Update embodiments as necessary to provide the greatest possible coverage for all Personas.
Now, arrange a meeting with the entire team. Review all the embodiments and put them together into a morphological chart. Discuss the advantages and disadvantages of each and reach agreement on which embodiments should go into the morphological chart.
Try not to criticize embodiments but rather try to extend and enhance them to make them better.
Add new ideas to the morphological chart whenever you think of one that the team largely thinks is feasible within the strategy of your project.
The deliverables of the ideation task include the following.
Design a highly innovative urban vehicle that could be brought into production within the five years.
Some possible ideas include:
Notice that none of the ideas address all the requirements (you can easily imagine which requirements are not treated here). However, it's easy to identify which key systems are being dealt with.
In none of the cases above is a sketch suitable – or more precisely, each idea can be captured by an infinite number of different sketches. To sketch a solution at this point defeats the purpose of ideation because a sketch is limited to the features on the sketch. The ideas presented here are so abstract that there is no real way to capture their essence visually without making too many other commitments about form. And we don't want to commit to form just yet.
What an idea does capture are the key principles (physical or otherwise) of the proposed design. (That's what an embodiment is.) One can look through the ideas given above for the urban vehicle problem and immediately imagine all kinds of possible differences (and similarities!)
The ideas listed above might have been developed as follows:
It should be evident by now that there are only two key systems that are addressed by these ideas: power system, and passenger compartment system. Nothing is said about brakes, or steering, or safety, or any other kind of system that might appear in a complete concept for an urban vehicle, not to mention issues of manufacturability, cost, quality, aesthetics, and so on. Therefore, none of the four ideas listed above constitute a proper design concept.
Design problem: You have to design a joint for a detachable robotic arm. It's basic systems are:
Exercise for the reader: Quick! How many different joint full design concepts can you come up with?
Just enumerate the different ways of embodying each system.
The end effector connection of the Canadarm has teeth around the outer edge mate with corresponding teeth on the end effector or payload. Once pulled tightly together, the teeth stop any movement at all. You can see the SRMS in action here and the SSRMS in action here. You can also make your own working model of the Canadarm end effector.
Just based on these ideas, one can generate 6 * 3 * 3 * 5 = 270 concepts.
Did you come up with that many concepts?