Documenting the Design Process

A page from Thomas Edison’s designer notebook.

In addition, lawsuits against a designer or company for injuries caused by a product can be worn or lost depending on whether there are records showing show best design practices were used to develop the product. Design notebooks also serve as references to the history of the designer’s work, which can be an aid to the designer. Even in cases of simple designs it is common for designers and engineers to be unable to recall why specific decisions were made.

• The design notebook is a diary of the design. It does not have to be neat, but it should contain all sketches, notes, and calculations that concern the design. So, before even starting a design problem:
• Have a bound notebook ready, preferably one with lined paper on one side and graph paper on the other.
• The first entry in the notebook should be your name, your company’s name, and the title of the problem.
• The second entry should be the problem statement, as well as it is known.
• Each following page should be numbered, dated, and signed.
• If test records, computer readouts, and other information are too bulky to cut and paste into the notebook, enter a note stating what the document is and where it is filed.

Design Reviews

Design reviews formalize decision making at important milestones and points in the process. If the project does not pass the reviews outright or with conditions (and the conditions are itemized), the project goes no further. In most organizations, design reviews are named to indicate their purpose. For example:

System Requirement Reviews (SRRs). These are scheduled at the end of the product definition phase. They ensure the functional and performance requirements are defined and will satisfy the product need.

Preliminary Design Reviews (PDRs). These demonstrate the design meets all requirements with acceptable risk, and within cost and schedule constraints. They generally take place before all details are developed. They establish the basis for proceeding with detailed design. They show that the best design alternatives have been selected, interfaces identified, and verification methods described.

System Definition Reviews (SDRs). These take place at the end of conceptual design and are used to examine the proposed system architecture and the functional elements that define the concept.

Critical Design Reviews (CDRs). These demonstrate the technical effort is on track to complete the product and meet requirements within the identified cost and schedule constraints. Detailed hardware specifications are audited by manufacturing, assembly, operations, and other downstream organizations important to the product’s life cycle. Finally, they verify the final product will fulfill any needs identified in earlier design reviews.
Any of these can focus on the entire product, systems, subsystems, assemblies, or components. And a design report will be needed for each of these.

Design Reports

Engineers make several presentations to managers, customers, and other team members during the design process. Although there might be no set form for design reviews, they usually require both written and oral communications. Whatever the form, here are some guidelines for preparing material for design reviews:

Make it understandable to the audience. It’s up to presenters to ensure their communications are clear to the group they are addressing. It is essential in explaining a concept to others that you are aware of what they know and, just as importantly, what they don’t know about the concept and technologies you are talking about.

Carefully consider the order of the presentation. How should a bicycle be described to someone who has never seen one? Would you describe the wheels first, then the frame, the handle bars, the gears and, finally, the whole assembly? Probably not, as the audience would understand little about how all these parts fit together and function. A preferable three-step approach is:

1. Present the entire concept or assembly and explain its overall function.
2. Describe the major parts and how they relate to the whole and its function.
3. Tie the parts together into the whole.

This same approach works when describing progress on a project: Give the big picture; mention all important tasks and milestones completed; then give the big picture again. There is a corollary to this advice: New ideas must be phased in gradually. Always start with what the audience knows and work toward the unknown. Above all, avoid jargon or terms the audience does not know. If in doubt about the audience’s knowledge of a concept or TLA (three-letter acronym), define it.

Be prepared with quality material (i.e., Bring your best game). The best way to make a point, and to have the meeting end well, is to be prepared. This means having good visual aids and written documentation, following an agenda, and being ready for questions beyond the material being presented.

Good visual aids include diagrams and sketches specifically prepared to communicate a well-defined point. In cases where the audience in the review is familiar with the design, mechanical drawings might do. But if the audience is composed of non-engineers unfamiliar with the product, such drawings might confuse more than communicate. It’s always best to have a written agenda for a meeting. Without one, meetings tend to lose focus. If there are specific points to be made or questions to be answered, an agenda ensures these items are addressed.

The following is a good outline for engineers to follow when preparing for a design review. It can obviously be modified depending on what phase the project is in and the audience that will be in attendance.

Title page

Date

Team leader

Team members

Executive summary

1. The executive summary should provide key information up front so that while reading the report, the reader’s expectations are fulfilled on a continuous basis. The key to a good summary is the first sentence, which should contain the most essential information you wish to convey.
   The summary should be written as if the audience is totally uninformed about the project and is not necessarily going to read the entire report.
2. It must concisely describe the project, the process, and the results.
3. The summary should be no more than one page and have no more than one figure.

Table of contents: Include section titles and page numbers

Design problem and objectives: Give a clear and concise definition of the problem and the intended objectives. Outline the design constraints and cost implications.

1. Include appropriate background on the project so the readers can put the information in context.
2. Present the project objectives in the form of a set of engineering specifications.

Detailed design documentation: Show all elements of the design, including explanations of:

1. Assumptions made, making sure to justify the design decisions.
2. Function of the system.
3. Ability to meet engineering specifications.
4. Prototypes developed their testing and results relative to engineering specifications.
5. Cost analysis.
6. Manufacturing processes used.
7. DFX results.
8. Human factors considered.
9. All diagrams, tables, and figures should be accurately and clearly labeled with meaningful names and/or titles.

Laboratory test plans and results for all portions of the system being built and tested. Include a narrative description of the test plan(s). Use tables, graphs, and whatever else possible to show results. Describe how you plan to test the final system and any features that will be included in the design to facilitate this testing. This section forms the written record of the performance of the design against specifications.

Bills of materials: Parts’ costs include only those items included in the final design. A detailed bill of materials includes (if possible) the manufacturer, part number and description, supplier, quantity, and cost.

Project plan: Show a complete listing major tasks that must done performed, a schedule for completing them, and which team member(s) has primary responsibility (and who will be held accountable) for each task.

Ethical considerations: Provide information on any ethical considerations that govern product specification developed or that need to be taken into account in potentially marketing the product.

Safety: State the relevant safety considerations in the proposed design.

Conclusions: Provide a reasoned list of the most significant results.

Acknowledgements: List individuals and/or companies that provided support in the way of equipment, advice, money, samples, and the like.

References: Include books, technical journals, and patents.

Appendices: As needed for the following information:

1. Detailed computations and computer-generated data.
2. Manufacturers’ specifications.
3. Original laboratory data.

This article is based on an excerpt from The Mechanical Design Process (6th ed.) by David Ullman, 2018 (www.mechdesignprocess.com).