How to write a Design Report (0)

How to Write a Design  Report  
Summary 
A design report is the written record  of the  project  and generally is the only record that lives  once  the 
design  team  disbands at the end of the project. The report has three sections. The  first   section  describes 
the problem that was being solved and provides the background to the design. The second section 
describes the design and the third section evaluates how well the design worked by comparing its 
performance to the design  requirements . The report starts with a short  executive  summary that 
contains a synopsis of the three sections. The  body  of the report is relatively short. Appendices to the 
report  contain  supporting information with the details  needed by a reader who wishes to fully 
understand  the design. While  this document describes the general content and organization of a design 
report, some of the specifics (section headings, length , and  format ) may be determined by your project 
client .  
Before  You Begin 
Some basics that you need to understand before starting to write the report.  
 
  Definition :  A design report documents the  solution  to a unique problem. 
 
Purpose : To communicate the solution to a problem. 
 
Audience: Anyone who has to implement your design, understand your design, or reference  
your design to solve their own problem. Typically, this is the project client. While the client may 
be familiar with the project, the report is still written as though the client is new to the project 
because that is the best  way to tell the whole story.  
 
A design report is different  than  a lab report that you might be familiar with. A lab report describes an 
experiment  and its conclusions and has four main parts:  Introduction , Methods, Results and Discussion.    
The major difference between design and lab reports is that design reports do not  include  a methods 
section (other than when describing the evaluation plan.)  When performing an experiment, the  method  
that you use to obtain an answer must be presented for someone else to validate the results.  For 
example, when testing  the emissivity of a material, the difference between using a thermopile and using 
an energy balance will affect the results. The absence of a methods section in your design report may be 
disconcerting because you might have spent up to half the semester considering different concepts 
before choosing one, but ultimately you won’t write about that  process .  The audience only cares about 
what you came up with and not how you got  there . A design report is not a history (“first we tried this 
and that did not  work  so then we tried this and finally we got to this”), but instead is results oriented.  If 
you  find  you are writing about your  concept selection process in the main body of your design report, 
you are writing too much. 
Organizing a Design Report 
Page 1 of 9 
 
A friend  comes to you with a problem.  “I haven’t been sleeping at  night ,” he says.  You decide to help 
out.  Upon further study you find that he hasn’t slept on a box spring for three months, has a persistent 
backache and has been on a 90-ounces-of-coffee-a-day diet since his last heat transfer midterm. 
 
Committed to your friend’s well-being, you take the appropriate  action .  You find a box-spring on 
Craigslist for free.  You suggest the use of caffeine-free tea after 6 pm and recommend that he play Bach 
softly as he falls asleep to drown out the sound of late-night buses.  Your friend thanks you for the best 
night’s  sleep he’s had in a while.   
 
Word spreads and it isn’t long before someone comes to you and says, “A friend of mine is having 
trouble sleeping at night.” 
 
What do you tell them?  Do you say, “Easy, get a box spring and play Bach!?”  If you did that, they would 
be confused.  This is how you would answer. 
 
“My friend Tim was having problems sleeping at night.  He had three problems.  He had an 
unsupportive mattress, he was drinking WAY too much coffee, and there are noisy buses passing 
by his window every night.” 
 
The person would then ask you, “what was the solution?” and you would say 
 
“I got him a new mattress, got him hooked on caffeine-free tea, and had him play music to block 
out the background noise.” 
 
If you stopped there, you would most certainly be asked one more question, “did it work?”  Therefore, 
you would continue 
 
“After we made those changes, Tim slept great for almost three weeks.  He told me everything 
was  back  to normal, and what’s better, he’s become a huge classical music fan.  The only 
drawback was getting the mattress for free off of craigslist.  Next time I’d pay a little money for 
one that was less dirty.” 
 
This problem is not an engineering  design problem, but the way in which it is documented is identical.  
Proper documentation includes three parts: problem definition, design  description , and evaluation.  All 
three are required to communicate your solution.  
 
The  figure  below shows the basic organization of any design report and should be the model for any 
report that you write. The  following  sections  provide  more detail about the content for each  part .  
 
 
 
 
Page 2 of 9 
 
Problem Definition 
In this part you  describe  the problem you set out to solve.  You provide sufficient detail so someone can 
both understand why the problem is significant and how it has been solved in the past.  Your problem is 
further detailed by providing key design requirements that the solution must meet. 
 
The problem definition section should have the following subsections using the suggested labels for 
each subsection: 
 
Problem Scope   A short paragraph explicitly stating the problem to be solved.  
 
Technical Review   This section describes why the problem is  important .  It is a long section 
providing background information of the problem.  It contains a state-of-the-art technical 
review that brings the reader up to speed to the current state of the  field  which you are working 
in.  Chances are that the reader is not an expert in the field, as you are. Even if the reader is an 
expert, he or she will appreciate a comprehensive review of the field.  
 
The review has two parts. The first part is a more detailed background to the field. For example, 
if you are developing a medical device, the background would be a tutorial on the medical 
condition being treated by the device.  The second part describes the prior art relevant to the 
problem, which  means all of the existing technology and methods relevant to the problem, 
including the ways the problem is dealt with now. The review  can include commercial products, 
academic journal articles and theses, and patents.  
 
The technical review will likely have many citations to the source of the information with 
citations listed in the Reference section. Citations and references should  follow  ASME, IEEE or 
APA style.  
 
Design Requirements    Here , you describe the most important, measureable design 
requirements that drove your solution to the problem. Generally, there are about five 
requirements that are at the core of the design. Additional requirements are  described in an 
appendix . At the beginning of this section, describe the source of the requirements. Typically 
requirements  come   through  researching customer needs or in some cases the detailed 
requirements are provided to the designer from the client. 
 
The design requirements are a central element to the design report and must be concrete, 
measurable criteria which can be tested.  They should be based on a customer need.  For 
example, “supports 80 lbs” and “has an emissivity greater than 0.8” are concrete, testable 
requirements.  “Looks nice, ” “comfortable, ” and “low cost” are  user  needs and not design 
requirements.  Refine them to measurable criteria, like “aesthetically rated above average on a 
5 point Likert scale” or “can be held for 5 minutes without fatiguing the average user’s  hand ,” Or 
“parts cost less than $20 in lots of 100.” Provide numeric values for all requirements.  Numeric 
values can be binary for requirements that are best expressed in true/false form. The reason for 
having numeric values is that then it is easy to determine whether the design meets the 
requirements when the design is evaluated.   
 
Often it is helpful to  present  the key requirements, typically no more than six, in a table. The 
table would include the design requirement, importance, units, marginal  value  and ideal value.  
Page 3 of 9 
 
For each entry, text describing the requirement, its source and why it is important should be in 
report body.   
 
One last thing to consider when setting design requirements is that they must be tested by you.  
If you do not (or cannot) test a requirement using a virtual prototype (computer model) or 
physical  prototype, then that requirement cannot be on your list of core design requirements.  
For example, do not use the design requirement, “can withstand a half-mile drop test,” unless 
you are going to either make an analytical model or empirically test out of a C-130. 
 
For examples of problem definition sections, read a U.S.  patent . A well written patent generally has an 
excellent description of the problem to be solved, the prior art and why the prior art does no adequately 
solve the problem.