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.
Since systems encapsulate behaviour, different systems can be developed in parallel and independent of other systems - so long as there is agreement on the system interfaces between systems and any requirements that are shared among and between systems.
Divide up systems among your team. One system should be the sole responsibility of one person. 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 team members. If there are more systems than team members, then assign two or more of the simpler systems to individual 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; the 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 safety: both the engine of a car and the passenger compartment of the car must be “safe.” The question is not whether they are both safe, but how each system will ensure safety of the overall design intervention. 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.
Responsibility requires collaboration. You cannot just design your system without also considering the impact that your design will have on other systems, each of which will likely be the responsibility of another team member. If you're in charge of engine design, the way you treat “safety,” for instance, within the engine system cannot incidentally render the passenger system unsafe. 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.
Once you are given responsibility for a system, you can start being creative. Specifically, you need to think of as many different embodiments for your system as possible.
Details for doing this, what embodiments are, and different creativity methods that can help you ideate are given in the page on embodiment.
Set a deadline for completing this step. Make sure every team member has time to devote sufficient time to the activity.
Collaboration is well-known to increase creativity in team-based problem solving. So before moving on with the process, it's important to let the team as a whole review the morphological chart.
Arrange a team meeting. Have the entire morphological chart available. Set aside 5-15 minutes for all team members to study the morphological chart and become familiar with all of the ideas it contains. Then hold an open discussion not to criticize any of the ideas in the morphological chart, but rather to extend and enhance them. 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?