Concept Generation & Selection¶
Template Instructions¶
The goal is to develop a broad range of concepts and to clearly document those for review and evaluation and later, for concept selection. The documentation needs to be complete enough to support this review cycle. Be sure to document variations of a concept as well as the main idea.
Sketches may be hand drawn at this stage of the design process. In general we favor more hand drawn sketches than fewer sketches made in a CAD tool.
As with Needs and Requirements, there is no "magic" number of concepts that must be generated. The team needs enough concepts so as to have a reasonable space to down-select from. Thus, while there is no specific number requires, practically speaking, it should be more than 2-3. The goal is to be creative in this process, look for opportunities to combine elements of multiple concepts and to help create the opportunity to develop further concepts.
The criteria used for Concept Selection should be the Requirements from your Needs and Requirements spreadsheet - so keep updating that as you learn more about the project.
For many teams, the initially selected concept may not prove to be adequate, requiring a return to the concept generation and selection phases. Having many concepts to choose from facilitates this iteration.
For more information on the process itself, please see Concept Generation & Selection elsewhere in this wiki. That page also includes links to other resources, such as the materials used in IED and a helpful video refresher.
Resources¶
- Please download and use the template found at Templates and Forms.
- Note that instructions for each slide are currently in the template file!
- Instructional video about Concept Generation (9 min)
- Materials from Introduction to Engineering Design course
Concept Generation¶
Use both an internal and external search to generate MANY concepts. At the beginning of the process, there are no 'bad ideas'. Crazy suggestions might inspire other concepts and thoughts among the team members.
- Internal source
- your head (self reflection)
- personal experience and memories
- External source
- Internet search
- Library, catalog
- client interview
- published research paper
- industry solutions
- news
- benchmarking
Concepts should represent solutions to a problem.
In general, names of technologies are not generally acceptable as concepts. For example, Python may be a powerful programming language but it is not a solution concept. That language may be used to implement a specific vision processing algorithm that can improve contrast, detect edges, crop the image to remove unwanted areas and from there detect an object in the image. All of THAT would be a concept!
It is strongly recommended to create a mind map to gather and document your team's concepts. This can be done in PowerPoint using the SmartArt feature. For more complicated mind maps, a powerful standalone tool called Freeplane ( https://docs.freeplane.org/ ) can be used. From there, one can export an image to be inserted into the PowerPoint slide deck
Concept Selection¶
It is often useful to compare the performance specs of 3+ concepts against each other AND the requirements.
As an example concept A would weigh 14 lbs, B would weigh 25 lbs, and C would weigh 35 lbs. If the requirement is "less than 50 lbs", all concepts are acceptable. If the requirements was at "least 30 lbs" then only concept C is acceptable.
| metric | requirement | concept A | concept B | concept C | concept D |
| weight | <50 lbs | 14 lbs | 25 kg | 34.8 lbs | 53.7 lbs |
| HDMI inputs | >=2 | 3 | 4 | 2 | 3 |
| range | >100 miles | 250+ miles | 189 kilometers | 204 miles | 95 miles |
Table above has adequate metrics to eliminate D from the choice, but additional metrics should be identified and used to make a recommendation between A, B, and C as these 3 satisfy the requirements.
Always compare 'full concepts' meaning if concept H would meet all requirements except portability, and team has a concept T to provides a handle, then compare concepts H+T together against the other concepts.
NOTE that the "1's and 0's" approach used for IED Decision Matrices is NOT sufficient nor acceptable for Capstone projects! You must have meaningful criteria based directly on your project Needs and Requirements AND you should use meaningful quantifiable metrics to evaluate how well your concepts solve the problem. Do NOT use the "1's and 0's" or "pluses and minuses" as you did in IED!