ENGR 100-600 | University of Michigan

Technical Communication Resources

This document contains resources and templates that we will reference in ENGR 100-600. This document is intended to cover the basics of technical communication. You will receive a lot more guidance and advanced topics through lecture and discussion.

This document is always evolving, and hopefully improving! If you see any typos, please let us know. And if you think of something that would be helpful for us to add, let us know that, too!

 

General Guidelines for Technical Communication

Technical communication is any type of communication whose primary purpose is to convey technical information. Technical communication includes:

Technical communication has some big differences from many other communication forms. It tends to be more “blunt” and “to the point”, meaning everything is focused on explaining the background, methods, results, analysis/commentary, conclusions, and recommendations. It also tends to not be very creative in terms of “creative writing” such as a novel, short story, or poem. Technical communication is not directly persuasive such as an opinion piece on a news website or an ad to get you to buy a new type of soap.

Some people worry that technical communication is hard to learn because it is so different from the types of communication that they have experience with in the past. We find that technical communication is straightforward to do because it is so very structured. Technical communication is clear and concise to limit the possibilities of misunderstandings. This approach means that a lot of the communication almost writes itself!

You will find some good general guidelines for techincal communication below. You can also see examples of technical communication in all of the other documents we post for you on the course website. After all, we’re trying to convey information to you as clearly and concisely as we can!

Technical Writing

Technical writing is basically what it sounds like: writing to convey technical work and/or concepts. The best technical writing is clear, concise, and organized.

Writing Clearly

Writing clear technical text (technical prose) may be different from the types of writing you have done in the past. In general, technical writing isn’t terribly creative; it’s much more formulaic. If you are writing a document about a remotely operated vehicle (ROV), you want to always refer to it as an ROV. If you start to “mix it up” to “keep your audience interested” by also calling the ROV a submersible, robot, underwater robot, submarine, underwater craft, etc., your reader will get very confused and think you are talking about different things. This is not the time to use a thesaurus!

Many technical documents are read by people all over the world. This means that they may not be native speakers of the language that the document is written in. They also may not be from the area where you grew up, so they will not understand the slang or analogies that you use. Be as precise as you can, and use the simplest words you can to convey your work. For example, in the previous sentence, I could have written, “They also might not be from your neck of the woods…“, and I almost did! But I remembered that “your neck of the woods” is a local phrase (probably Midwestern US) that not everyone understands. So, intead I used “the area where you grew up”, which is a phrase that uses simple words and clearly conveys the idea that I needed to convey.

The guideline of use simple words doesn’t apply to industry-specific or project-specific technical words or concepts. If using a technical term is the most precise way to explain what you did, then you should use that term! If you are concerned that your audience might not know that term, you can define it for them.

Writing Concisely

Technical documents are written to convey the work done, and that’s it. There is an organizational flow to your “story” with the work, but it’s not a traditional narrative like a book, poem, blog post, or even how you talk out loud to another person. The sentences tend to be short and “choppy”. There are very few transitional sentences or phrases such as “In addition to…” or “Following this work…“. You just move to the next sentence.

Most paragraphs in technical writing are short because that makes it easier to skim and find information. There is no “traditional five sentence paragraph” structure of a topic sentence, three supporting sentences, and a conclusion sentence. Group together sentences in a paragraph if they are talking about the same thing. When you move to a new thing to talk about, start a new paragraph.

A good general guideline is to write a sentence and then re-read it. If there are any words or phrases that you can remove and the sentence still conveys the information it needs to, then remove those words.

Organizing Your Writing

Good organization is critically important to good technical writing. Your readers will rarely (if ever) sit down and carefully read your document from beginning to end and remember everything that you explained to them. Instead, your reader will likely skim the document first to understand, at a high level, what you’re talking about. Then, they will probably jump to different sections, skimming what you wrote to find either what they need or what is interesting to them. Your document’s organization should help your reader do all this as quickly and clearly as possible.

Well-organized technical writing will have:

The next sections give more detail about how you can create well-organized documents. We also have templates that you can use that already have a lot of this organization built-in for you.

Sections and Section Headings

Organizing your communication into sections and subsections is critically important to your memo’s readability, meaning “this document should be easy for people to understand and read”. The sections and subsections are organized in a logical way and not necessarily chronologically. Each section and subsection (and subsubsection, etc.) should have its own section heading. The section heading is like a little signpost that helps your reader to know what that section is about.

Sections in Presentations

Presentations may or may not have formal sections. It depends on how long the presentation is and the style of the presentation. An informal presentation may just have a bunch of slides that contain diagrams and pictures to help explain what you are talking about. A formal presentation may have sections and “section heading slides” as a visual clue to your audience that you are changing topics.

Sections in Written Documents

The section headings in written documents serve as an outline of the entire document, helping readers to quickly skim the document to find the information they need. For example, this document uses sections and section headings to organize all this communication content. The program that turns the original Markdown file into this .html webpage also takes all the section headings and subsection headings and turns them into an outline / navigation bar on the left hand side (Fig and also the actual left hand sidebar).

TODO
Section headings can be used to create an outline like this. The outline helps readers quickly find the information that they need. Even if the document doesn't have clickable links like this document, the section headings allow a reader to quickly scan a whole document to find what they need.

Your memo won’t have an outline / navigation bar like this in its final “printed” form, but most modern programs for written communication will have an outline built-in to help you navigate the document while you are creating it. So, the section headings are important for both your reader and for yourself!

Figures

Figures are a critically important part of technical communication. Figures can include:

Figures should be clear and easy to read and understand. Some guidelines for creating good visuals:

Figures in Presentations

Figures in presentations are generally placed directly on the slide with no caption or numbering. You might have a short phrase explaining the signficance or takeaways from the figure, or you might just be saying that verbally.

Make sure that your figure is big enough to be seen from across the room. You might be able to see it clearly on your computer screen, but what about from 50 feet away?

Take the time to thoughtfully arrange figures on the slide. Inconsistent spacing between figures, weird spacing between figures and text, figures that are too big or too small… all of these will be distractions to your audience. You don’t want your audience to be distracted; you want them paying attention to what you’re presenting!

Figures in Reports

Your figures should be numbered sequentially with Arabic (1 2 3) numerals. Each figure should have a caption below the figure that describes what the reader needs to know about the visual in the figure. Captions are generally center-justified. Figures should also be referenced in the text before they appear, such as the example shown in Fig.

Three pictures of a submarine. Each picture has an arrow pointing up for the buoyant force and an arrow pointing down for the weight of the submarine. The top picture has a bigger arrow for the weight; this submarine is too heavy. The middle picture has a bigger arrow for the buoyant force; this submarine is too light. The bottom picture has equal sized arrows for the buoyant force and the weight; this submarine is just right.
Illustration of buoyancy vs. weight for a submarine.

The block of text after the figure usually talks about the visual a little more. Then, you move on to the next thing you’re talking about.

To our knowledge, the only word processing program that provides a built-in way to easily caption and reference figures is LaTeX. Overleaf is an online, collaborative platform for creating documents using the LaTeX typesetting program. The templates provided in this document include templates for Overleaf that include an example of how to do figures in LaTeX.

Other programs, such as Google Docs and Microsoft Word, have pretty good ways to create figures, but they have varying levels of ability to caption and reference figures. You can usually figure out how to make the figures themselves fairly well, but all of the numbering and referencing usually has to be done by hand. The templates provided in this document include examples of how to do figures and captioning in Google Docs, but we recommend searching online for the latest, most-up-to-date recommendations on how to do figures and captioning in Google Docs, Microsoft Word, or whatever program you are using.

Tables

Technical communications, by definition, conveys a lot of technical information. Many times, a table is useful way to communicate a lot of numbers that are all related in some way. So, technical documents often have a lot of tables!

Tables should be clear and easy to understand. Unfortunately, most programs for creating presentations and documents have terrible default settings for tables. There are so many lines, colors, and background shades of color that it is difficult to actually see the information in the table.

Here are some general guidelines for creating clear and easy to understand tables:

Tables in Presentations

Tables in presentations are generally placed directly on the slide with no caption or numbering. You might have a short phrase explaining the signficance or takeaways from the table, or you might just be saying that verbally.

Make sure that your table is big enough to be seen from across the room. You might be able to see it clearly on your computer screen, but what about from 50 feet away?

Take the time to thoughtfully arrange tables on the slide. Inconsistent spacing between tables, weird spacing between tables and text, tables that are too big or too small… all of these will be distractions to your audience. You don’t want your audience to be distracted; you want them paying attention to what you’re presenting!

Tables in Reports

Your tables should be numbered sequentially with Arabic (1 2 3) numerals. Each table should have a caption above the table that describes what the reader needs to know about the information in the table. Captions are generally center-justified. Tables should also be referenced in the text before they appear, such as the example shown in Table.

An example of a simplified bill of materials for an ROV. Values are for instructional purposes only!
Category Cost
Power & Thrust $225.00
Frame $42.15
Control $32.86
Ballast $5.22
Miscellaneous $2.90
Total Cost $308.13

The block of text after the table usually talks about the information a little more. Then, you move on to the next thing you’re talking about.

To our knowledge, the only word processing program that provides a built-in way to easily caption and reference tables is LaTeX. Overleaf is an online, collaborative platform for creating documents using the LaTeX typesetting program. The templates provided in this document include templates for Overleaf that include an example of how to do tables in LaTeX.

Other programs, such as Google Docs and Microsoft Word, have pretty good ways to create tables, but they have varying levels of ability to caption and reference tables. You can usually figure out how to make the tables themselves fairly well, but all of the numbering and referencing usually has to be done by hand. The templates provided in this document include examples of how to do tables and captioning in Google Docs, but we recommend searching online for the latest, most-up-to-date recommendations on how to do tables and captioning in Google Docs, Microsoft Word, or whatever program you are using.

Equations

Equations are a very necessary part of engineering, and reporting them is equally necessary. Presentations will typically have limited use of equations because the presentation is usually focused on the results of the calculations, rather than the equations. The details of the calculations are included in written reports, which have more room to describe the calculations than a slide!

In written documents for this course, all equations will be centered and numbered on the right hand side. Equations must be typeset using an equation editor/toolbar so they are rendered correctly. Equations must be introduced in the preceding sentence with all variables defined afterwards. For example, the equation for the buoyant force, \(F_b\), of an object is:

\begin{equation} F_b = \rho g \nabla \label{eq:buoyantforce} \end{equation}

where \(\rho\) is the density of water, $g$ is gravitational acceleration, and \(\nabla\) is the volume of the object. Variables in text are typically italicized so that they are visually different from the surrounding text. Equations can then be referenced by their equation number. So, you can refer your reader to an equations, such as Eq. \ref{eq:buoyantforce}, when that equation is pertinent to your explanation.

To our knowledge, the only word processing program that provides a built-in way to easily format equations, number equations, and reference equations is LaTeX. Overleaf is an online, collaborative platform for creating documents using the LaTeX typesetting program. The templates provided in this document include templates for Overleaf that include an example of how to do equations in LaTeX.

Other programs, such as Google Docs and Microsoft Word, have varying levels of ability to create equations, number equations, and reference equations. You can usually figure out how to make the equations themselves fairly well, but all of the numbering and referencing usually has to be done by hand. The templates provided in this document include examples of how to do equations in Google Docs, but we recommend searching online for the latest, most-up-to-date recommendations on how to do equations in Google Docs, Microsoft Word, or whatever program you are using.

Citations

You might find yourself referencing a literature research to justify design decisions or explain the background or context of your project. If so, you can cite using whatever consistent style your team wants to implement. APA, MLA, IEEE, or any other citation style is perfectly acceptable as long as you are consistent!

Any style should include in-text citation. In APA, that will look like a parenthetical citation at the end of the sentence, specifying the author(s) and year of publication (Dym, Agogino, Eris, Frey, & Leifer, 2005). In IEEE, that will look like a number in square brackets[1]. You’d do this for each piece of information that is cited.

Page Breaks and Other Formatting

The real goal of formatting in a technical document is to use visual clues to help your reader find information. You are free to use page breaks, section breaks (to change part of the report to landscape orientation, for example), and other things to make your document as easy to read as possible. For example, you can (and should!) use page breaks so that a section heading isn’t hanging by itself at the end of a page while the text that follows it is on the next page. Similarly, you can use spacing and formatting to make sure your figure and table captions don’t get separated from the figure or table they go with. Just be consistent in whatever you do!

General Grading Rubric

In general, we don’t really like the idea of assigning points (or worse, half-points) to each and every tiny thing in a technical writing assignment. That’s not how it works in the real-world. In the real-world, your work is either “yup, this is good” or “nope, you need to go back and fix this stuff before we can send it to our client/boss/whatever”. But, we do have to assign points/grades to your work. So, this is roughly how grades translate to real-world scenarios.

(A+) 100.0% of points possible. Work earning this score is ready to be passed on to a real client. In every way, it meets audience needs. Major points are clear and well supported with evidence; technical content is correct. Document/presentation is formatted and organized to guide to major points. Clear and interesting visuals and prose contribute to professional-level quality.

(A/A-) 93.5% of points possible. Work earning this score is strong and all technical content is correct. If we were your supervisors on an internship, we’d suggest minor changes before sending it on to a real client. Those changes might include slight changes to prose, visuals, or formatting to increase clarity and readability. The suggestions are truly minor, and if the document were sent on without the requested changes, we wouldn’t be too concerned. None of the errors are so large that they would affect our company’s or your relationship with the client. See your document, as instructors will have made suggestions directly on the text.

(B+/B) 86.5% of points possible. Work earning this score is good. If we were your supervisors on an internship, we’d consider this a strong draft but suggest changes before sending it on to a real client. Either because of the severity of a single issue (perhaps errors or missing evidence for technical content), or significant issues with prose, we would be concerned if this document went to a client without those changes made. See your document, as instructors will have made suggestions directly on the text.

(B-/C+) 80.0% of points possible. Work earning this score shows some promise, but it lacks much-needed polish and/or includes technical errors. If we were your supervisors on an internship, we would require substantive revision to the majority of the document before it could be passed on to a client. Though evidence of good ideas and/or solid engineering work is present, we am certain that a client would be too distracted by the many problems and/or technical errors to form a positive impression of you or our company. See your document, as instructors will have made suggestions directly on the text.

(C/C-) 73.5% of points possible. Work earning this score requires significant revision before it can be passed on to a real client. These changes include improvements in clarity and readability as well as in major content (perhaps content is missing, unclear, or wrong). We would panic if this document were sent directly to a client without significant revision, as we believe it could affect our company’s relationship with the client. See your document, as instructors will have made suggestions directly on the text.

Lower scores than this are possible but uncommon (and usually the result of incomplete work).

 

Choosing What Program to Use: Collaborative Communication

You will produce communication deliverables in this course that you create by yourself (individual work). However, pretty much all engineering work is done in teams, which means you will need to produce communication deliverables that you create collaboratively with the people on your team. So you should keep this in mind when choosing what program to use to make presentations and write reports.

Collaborative communication used to be pretty hard. Someone would draft up a section and save it as a file. Then they would email that file to the people on their team. Team members would make changes and email the files back to the original person. That person would then have to carefully reconcile all the proposed changes and lots of mistakes would happen. And imagine what it was like creating something when everyone was writing things out on pieces of paper and then trying to put them all together into a cohesive document!

Fortunately, we have much better tools now for collaborative communication, including some great online platforms that let everyone work on the same document simultaneously. Your team will need to choose which tool/platform you want to use for your presentations and reports. We encourage you and your team to find a good balance between I feel comfortable using this, I want to learn something new, and When/where should we deal with frustration.

We strongly encourage teams to use a platform that allows for multiple people to work on the document at the same time and that has the ability to leave comments. Any platform that does this will have the added bonus of automatically saving your work as you go along, so you won’t accidentally lose your work!

Collaborative Presentations

Currently, Google Slides is our recommended program for collaboratively creating a presentation. Google Slides doesn’t have nearly as many formatting options as Microsoft Powerpoint, but you don’t want anything elaborate for a technical presentation anyways. We feel that the ability to simultaneously edit a presentation, comment on items, and “tag” people using @email_address far out-weighs having more options in formatting.

Other programs, such as Keynote (MacOS) and Beamer (LaTeX typesetting), are not nearly as widely used, so they are not a good choice unless everyone on your team is already very comfortable with those programs.

Currently, U-M officially supports the Google office suite (Docs, Slides, Sheets, etc). The combined ENGR 100-600 staff can help with just about anything in Google Slides or Powerpoint for sure. We don’t have as much experience with other programs.

Collaborative Reports

We have two recommended programs/platforms for collaboratively creating written reports: Google Docs and Overleaf.

We’re guessing you’re pretty familiar with Google Docs. This program lets you quickly, and fairly easily, create basic documents. You can write text, include figures and tables, write equations, and use section headings to organize your document. You and your teammates can simultaneously edit the report, comment on items, and “tag” people using @email_address to assign TODO items or ask for feedback.

However, Google Docs isn’t really designed for technical documents that have a lot of figures, tables, equations, sections, etc. It does not have any built-in support for things that we need, such as captions, numbering, and references. It is also really easy to accidentally get your formatting messed up and then have to spend a lot of time fixing everything.

Google Docs Pros: Easy to get started. What you see is what you get: easy to check if everything looks correct. Can tag people in comments and they get an email.

Google Docs Cons: No support for automatically numbering and referencing figures and tables. Hard to manage longer reports with lots of figures/tables. Formatting can get off and be hard to fix.

Overleaf is an online tool that allows for collaborative writing using the LaTeX typesetting protocol. LaTeX (usually just written as LaTeX if you’re not writing a formal document about LaTeX) takes your “plain text” plus “commands” to set the formatting and creates truly gorgeous documents. LaTeX is popular in the science, engineering, and math communities because it has built-in support for numbering figures/tables, writing and numbering equations, captions, references, and automatically adusting whitespace to just “make everything work.”

However, LaTeX is kind of like “code”, as in “programming a computer”. Instead of just bolding a phrase and seeing that change in font, you have to type \textbf{bolding a phrase} and “recompile” your document to see what that looks like. It takes a bit of time to learn what LaTeX is all about and how to use it. It’s also a bit overwhelming at first because it’s a different way of going about writing reports.

Overleaf Pros: Tons of built-in support for hard to do things like numbering figures/tables, keeping captions with figures/tables, writing equations. Impossible for formatting to get out-of-whack.

Overleaf Cons: Hard to get started; looks weird at first. Can’t see changes as you type. Can leave comments for people to do stuff, but can’t send them an email linked to the comment.

The ENGR 100-600 staff will happily support you and your team in whatever program you choose to learn. The IAs note that writing reports in Overleaf, especially for upper level classes, is much less frustrating than Google Docs or Microsoft Word simply because LaTeX was designed for the type of technical communication that is done in engineering.

The IAs really encourage you to learn more about Overleaf as part of your decision-making process for choosing what program in which to write your technical reports. We have put together an Overleaf Tutorial (.pdf version and Overleaf version) that goes over all the basics of what you would need for ENGR 100-600. We’re happy to talk more in office hours!

 

Presentations

Coming soon!

Title Slide

Coming soon!

Slide Design

Coming soon!

Font Choice and Size

Coming soon!

Effective Visuals

Coming soon!

Backup Slides

Coming soon!

Presentation Templates

Coming soon!

 

Informal Reports (Memos)

Most companies will have some form of informal report to document initial findings, quick responses, or to summarize a meeting. There are many formats that can be used for informal reports. We will use the memo format in this course.

Memos consist of several sections, some which are required/expected and some which are more like suggestions that you can adapt to whatever it is you are trying to document. In general, memos consist of:

The next sections explain more about these different sections of a memo. There is also an annotated sample memo that demonstrates what a memo actually looks like.

Frontmatter

The frontmatter consists of three sections:

The term frontmatter might not be used outside of this course (we might have made it up), but whatever your organization calls it, this information is generally limited to one page.

The header contains all the information about to who and when the memo was sent. In general, you’ll have these sets of information:

To:

From:

Subject:

Date:

Distr: 		People (and their titles) who you are sending the memo to

You and your title (and any team members and their titles)

Short description of what the memo is about

The date the memo was sent

People (and their titles) who are also getting a copy of this memo
   

The “To” field generally comes first, but the order of the rest of the fields can vary from organization to organization. Follow the convention of whatever organization you’re working for.

You should always make sure that your date is unambiguous by spelling out the month. For example “9/6/2024” could mean “September, 6, 2024” or “June 9th, 2024” depending on where you are in the world.

The order that you list names should make some kind of sense. In academia, names are usually listed by how involved they were in the project. In industry, names might just be alphabetical by last name, or by the importance of their role in the company. For your ROV project, everyone presumably contributed equal amounts of effort, so you can list people alphabeticallly. Note that the honor code prohibits you from listing a teammate who did not contribute to the project.

Foreword

A foreword (note the spelling, and remember it as “WORDs that come beFORE”) has as its goal to let the reader know what this document is. It contains three pieces, in a specific order:

The foreword is generally ~3-5 sentences. Sometimes the task is written as a set of bullets, if it’s complicated but not overly so.

Summary

You’ll need to keep the summary short: Some audiences for a memo will only read this first page. Most organizations will force the “memo frontmatter” to end on page 1.

Your goal here is to explain your findings as well as any recommendations/ implications that follow from them. If it would help, you can add a single sentence of over-arching methodology at the beginning (“Based on …, we believe that…”). Then have 1-2 sentences describing what was found for each task listed in the foreword. Make sure each “task” as described in the foreword is responded to here in the summary, in the same order (it’s easier for the audience).

If recommendations are requested or are ethically obligated (let’s say you learned something might blow up and kill the user), you must include them. Otherwise, they are optional.

Discussion (Main Body of Memo)

The discussion section is the main body of the memo. The discussion can be anywhere from a few pages to 20 pages or more; it just depends on what is going in the memo. The discussion always starts on page 2 of a memo.

The discussion section starts with a short intro paragraph that concisely restates the reason(s) that the work was done and any background/context for the work that the audience should know about. The paragraph usually ends with a sentence that explains the organization of the rest of the discussion section

Discussion Sections for a Traditional Memo

A traditional memo discussion consists of:

Each of these sections would get its own section heading, and then you often will have some subsections within each of the sections. This set of traditional discussion sections works very well for something like a lab report, or report of an analysis you did at an internship. The next sections here in this document give a little more detail on the general methods, results, and analysis sections of a memo.

Methods

This section documents what you did. Not the results of what you did (that comes in the next section), just what you did. You’ll often see some background research in this section as context for what experiments, testing, research, work, etc. was done. You would then clearly and concisely describe what you did. The idea of this section is that someone could follow your description here and re-create your work if they wanted to help validate what you did.

Results

Put your results here. JUST the results, no commentary on what the results mean. Put the results down in the same order that they are listed in the Summary, so that it is easy to find them. Again, you may find it nice to subdivide this section according to the tasks you were set. It is NOT necessary to always subdivide sections, though. Only subdivide sections if it will help your reader find information.

Results will often take the form of figures and tables. Figures and tables should be formatted and referenced according to the general guidelines for technical communication above. You can look at the templates below for examples, too.

Analysis

THIS is where your commentary on the results go. Your audience needs your interpretation of the results to understand the importance of what you did and why they should care about the results.

Conclusions and Recommendations

The Conclusions section summarizes the methods, results, and analysis presented in the memo. It will look similar to the summary but with more detail. The conclusions section should NOT introduce new ideas, though; it just highlights important things for an audience who may have skimmed earlier information.

This section is particularly critical if you are reporting any type of failure or less-than-desirable outcomes. To be clear, this happens all the time in engineering, and we often learn our most important things through failure. This section gives you a chance to emphasize the lessons learned and what can be done differently in the future.

If requested, or if it makes sense, you can also include a Recommendations section. This section is particularly useful in summing up actions or action items that you want to emphasize to your reader, especially a reader who might not have been paying attention to the rest of your memo!

Conclude the report with an invitation for contact—if the client wants to do something different? Has questions or concerns? Would like a modified design? they can contact you at fakeemail@umich.edu or whatever (don’t worry, we won’t really email you at this address).

References

Your References section lists your references according to the citation style. That will likely be either alphabetical by the first author’s last name or numerically by the order in which the citations are made in the report.

Appendix

An appendix may be used to include lengthy graphs or calculations that support the results or analysis you include in the main body of your memo. If there are multiple appendices, they should be clearly labeled and each topic should be a separate appendix. The appendices should appear in the order they are referenced in the text. All appendices should be referenced in the text. No reader just flips through appendices for fun; you need to say in the text what sort of supplemental information can be found where if you expect anyone to make use of it. (And if you don’t expect anyone to make use of it, then don’t include it.)

Example Memo Frontmatter with Annotations

Here is an example of what the frontmatter looks like in a memo:

 

Here is an annotated version of that frontmatter that gives you some more details about how to write the frontmatter:

Memo Templates

We have created some templates for you to use in this class. You may, hopefully, find them useful in future classes and/or jobs as well! You are free to use these templates for anything you need them for.

It’s very important to use the memo templates correctly. Each template has style formatting set up for:

Section Headings
Subsection Headings
Subsubsection Headings
      captions      
normal text

Make sure you assign the styles correctly so that you can take advantage of these settings and not have to go back and fix a bunch of stuff. If you’ve never worked with style formatting before, don’t worry! We’ll do some practice in class.

Generic Memo Template

Click one of the links below to go to the template you want to use:

Make a copy of the template for your own use, then adapt/re-use the examples for what you need to write up.

Template for Individual Design Proposal

The Individual Design Proposal is an informal report, but the general “Methods, Results, Analysis” sections don’t really make a whole lot of sense for this proposal. That’s okay! We can just adapt the general format of a memo (frontmatter, body of memo with good sections and section headings, conclusions, appendix) to have a “discussion” section with headings that make sense for the IDP.

Click one of the links below to go to the template you want to use:

Make a copy of the template for your own use, then fill in the sections!

Template for Critical Design Review Report

The Critical Design Review Report is an informal report, but the super general “Methods, Results, Analysis” sections don’t really make a whole lot of sense for this report. That’s okay! We can just adapt the general format of a memo (frontmatter, body of memo with good sections and section headings, conclusions, appendix) to have a “discussion” section with headings that make sense for the CDR report.

Click one of the links below to go to the template you want to use:

Make a copy of the template for your own use, then fill in/expand on what’s there for what you need to write up.

 

Formal Reports

Formal reports are often used at the end of a project to signal that this is the final documentation of everything that was done. A formal report format might also be used for intermediate reporting that has a lot of information to convey and therefore is many pages long. In general, a formal report will include:

Most of this is analogous to the informal report, just with a bit different formatting and/or organization to help your reader understand and navigate the larger amount of information you are conveying. The next sections explain the sections of the formal report in more detail.

Title Page

The header contains all the information about to who and when the memo was sent. In general, you’ll have these sets of information:

The title page is often “fancy”, with company logos and color schemes. Always make sure that the decorations and branding don’t obscure the critical information listed above.

Table of Contents

Formal reports are typically a lot longer than informal reports and thus need some type of formal outline to help with navigating the document. A formal technical document will have a table of contents at the beginning of the report. The table of contents serves as both an overview of the entire report and also as a way for readers to quickly find the information they need, especially if they have already read the report and need to review something contained in the report.

Most modern programs for creating written documents can automatically create a table of contents for you based on the heading styles you use in the document. Make sure you use the templates we provide so that you can automatically create the table of contents and save yourself a lot of time and irritation!

Executive Summary

The executive summary is a series of paragraphs describing high-level content for the following report. For this class, it should not exceed one page in length. Your goal is to capture the major ideas from the report, for readers who won’t read the whole thing. Some readers won’t even read the executive summary, so just because you refer to something here, don’t omit it from the rest of the report. Similarly, some readers will ONLY read the executive summary, so your goal is to capture all the important stuff here.

You’d typically start with a paragraph that describes the context and problem you were called on to solve (i.e. the project objective), and summarize your approach, major findings, and recommendations. This first paragraph should also state the tasks you were assigned, the status of those tasks, and the purpose of the document (it’s basically a foreword, though it doesn’t include the purpose statement.)

In a report presenting a design, there would be a section outlining the design goals and the design itself, usually with a reference to a visual (often located elsewhere in the document: e.g., tell me to see Figure X on page Y).

The next paragraphs should follow the major points of the document, in the order they appear in the document. In a progress report, the emphasis would be on the design and on the progress. In a design proposal, the emphasis would be on the design and its characterization (including things like performance, full-scale implementation plan). Highlight those things you want your audience to notice– your goal is to make sure the audience understands particular things, and you can use this space to draw attention to important aspects of your report. A “rule of thumb” that’s often broken: Consider having one paragraph per main section heading in the report.

The executive summary should start on a new page after the table of contents.

Body of Report

The body of the report generally starts with an Introduction section and any other sections/subsections for background, motivation, previous research, etc. Then, you would include all the documentation for the report itself. As in the informal report (memo format), you’re generally talking about your methods, results, and analysis. The body of a formal report is typically many pages, anywhere from 10 pages to hundreds of pages; hence the need for a table of contents!

The body of the report should start on a new page after the executive summary.

Introduction

This section gives a good amount of detail about why the work was requested. Formal reports are often documenting large projects that were completed over a long period of time and were intended to help solve complex problems. You want to include the context for the project here so that your reader understands and appreciates why so much time, money, and effort went into this work. Introduction sections may have subsections for background or motivation for the project, research done by the team, references to existing products or projects, and anything else that is needed to provide a thorough context for the project.

Sections and Subsections

Sections and subsections are important to the organization of your formal report, just as it is important to the organization for informal reports. The main difference between section organization in informal reports and formal reports is that formal reports have a lot more “main sections” than informal reports. Informal reports, because they are typically much shorter, tend to have one main section heading for the body of the informal report, with lots of subsections and subsubsections under that main section heading. Formal reports will typically have many “main sections”, each with their own sets of subsections and subsubsections. It’s important to follow the general guidelines for sections and subsections to choose section headings that make sense for your reader to help guide them through your documentation.

Conclusions and Recommendations

The Conclusions section summarizes the methods, results, and analysis presented in the memo. It will look similar to the summary but with more detail. The conclusions section should NOT introduce new ideas, though; it just highlights important things for an audience who may have skimmed earlier information.

This section is particularly critical if you are reporting any type of failure or less-than-desirable outcomes. To be clear, this happens all the time in engineering, and we often learn our most important things through failure. This section gives you a chance to emphasize the lessons learned and what can be done differently in the future.

If requested, or if it makes sense, you can also include a Recommendations section. This section is particularly useful in summing up actions or action items that you want to emphasize to your reader, especially a reader who might not have been paying attention to the rest of your memo!

Conclude the report with an invitation for contact—if the client wants to do something different? Has questions or concerns? Would like a modified design? they can contact you at fakeemail@umich.edu or whatever (don’t worry, we won’t really email you at this address).

References

Your References section lists your references according to the citation style. That will likely be either alphabetical by the first author’s last name or numerically by the order in which the citations are made in the report.

Appendices

An appendix may be used to include lengthy graphs or calculations that support the results or analysis you include in the main body of your memo. If there are multiple appendices, they should be clearly labeled and each topic should be a separate appendix. The appendices should appear in the order they are referenced in the text. All appendices should be referenced in the text. No reader just flips through appendices for fun; you need to say in the text what sort of supplemental information can be found where if you expect anyone to make use of it. (And if you don’t expect anyone to make use of it, then don’t include it.)

Example Formal Reports

Coming soon!

Templates for Formal Report

We have created some templates for you to use in this class. You may, hopefully, find them useful in future classes and/or jobs as well! You are free to use these templates for anything you need them for.

It’s very important to use the template correctly. Each template has style formatting set up for:

Section Headings
Subsection Headings
Subsubsection Headings
      captions      
normal text

Make sure you assign the styles correctly so that you can take advantage of these settings and not have to go back and fix a bunch of stuff. If you’ve never worked with style formatting before, don’t worry! We’ll do some practice in class.

Generic Formal Report Template

Click one of the links below to go to the template you want to use: