Heavily used in this course for documentation are Google Slides and Google Docs. G-Slides is used not only for conventional presentation slides, but also here for documents comprised of larger format 11 × 17 inch (ANSI B) sized pages we call a “B-sheet.”
You will be provided with a team-specific template in one or the other (G-Slides or G-Docs) for each document, pre-meeting briefing, tech-memo, and cover letter you will have to produce. While one could download any of those templates as a Microsoft (MS) PowerPoint or Word file to work with in that way, please do not do that. First, that actually introduces far more failure modes in regard to producing the final deliverable PDFs needed; it may not make sense now, but having seen literally over 1,000 docs generated that way, it is a fact here. Second, and more important to you and your benefit, working in G-Slides and G-Docs comes with outstanding collaborative capability, something students have craved for a number of years and you now can benefit from since we have transitioned in 2022 from MS Office to Google Apps. That having been said, MS Excel is used extensively as a tool called DP Manager; perhaps someday time will permit converting it to G-Sheets.
1 Formatting
For MEEM 4901 and 4911, prior to receiving the editable version of your team’s team-specific templates your project title, customer name, team number, team members, etc. will be pre-filled for you in the appropriate and required places of the template. There is no need to alter any information on the cover page or in the headers with the exception of optionally adding a logo on the cover page as indicated in those templates that have a cover page.
For G-Docs templates, any areas where you will be adding content make use of the standard paragraph styles in G-Docs — Title, Subtitle, Heading 2 (Heading 1 not used), Heading 3, Heading 4, and Normal text — already defined as desired including line spacing, indenting, and font types (Arial for headings, Times New Roman for non-heading text) and sizes. Do not change anything about these styles! And while not a matter of formatting, do not change the wording of the section headings; most section headings are tied to a grading rubric.
A bit more on font types… Times New Roman is a “serif” font. That means it has little “thingies” called serifs at the ends of the letters. In contrast, san serif fonts like Arial do not have those “thingies.” Serif fonts are easier for the eye to follow in multi-line, textual format whereas san serif fonts are good for situations where resolution may be limited and/or for short text elements like headings and bullet points of a line or two.
Furthermore,

That was repeated (word for word) so you can see the difference between the two fonts; it adds up by line height, not just line length. In any case, as noted, serif fonts like Times New Roman are easier for the eye to track across more than short phrases like section headings, titles, etc.
To summarize, just stick to the noted styles in G-Docs without changing them, and your formatting will be appropriate and as expected.
2 Graphics Annotations
A graphic (photo, illustration, CAD model, etc.) is generally much more effective if it is annotated to point the reader’s attention to certain aspects of the graphic to which you are referring in the referencing/accompanying text. Annotations are not optional here, they are expected/required by us and will have a strong impact on your audiences well beyond your capstone design year. By the way, Arial (sans serif fonts) is good for figure annotations, which take the form of one to a few words.
3 Executive Summaries
Every document of length greater than about four to five pages should be summarized in an executive summary. In industry, the purpose of an executive summary is to brief the executive, manager, supervisor, etc., who may or may not read the entire document. Those on your Project Continuation Review panel at the end of Term-I may or may not read the full document in detail and often rely on your executive summary for a thorough yet concise summary of the document. Those on the SCD Advising Team will read your documents in their entirety!
As you may be deducing, the executive summary is one of the most important parts of a technical document. It must stand alone and be concise while delivering enough detail to provide an accurate understanding of the status of your project. Stand-alone means it must be understood without having to leaf through the document. Do not refer to the body of the document (e.g., “This report contains objectives and constraints …”). An executive summary is also not a diary. It is not a discussion of “what you did.” It is a summary of the content of the document. Yes, the content mirrors what you did, but it is not to be described as what you did, rather what the content of the document is. For instance, do not write “The team determined the design requirements and divided them into constraints (having limits to which the solution must adhere) and objectives (having desired targets). They include…” Rather, write “Engineering requirements include and constraints (having limits to which the solution must adhere) and objectives (having desired targets). They include…”
This is offered as a basic example and is not actual content we seek to be in your executive summary. You should assume in your executive summary and throughout your documentation that your audience knows generally what the design process is, what the design tools are, and why they are used. You need not explain the “what”, “why” and “how” of the design process steps and tools.
Online doc-prep guidance will provide specifics for each document indicating an expected length and guidance on what content is expected. Guidance will begin with high specificity at the Problem Understanding Document (PUD) stage and taper off in specificity over the course of the project; you are expected to be learning with time and experience to gauge what content to cover in the later stages (and beyond capstone design into your career).
Throughout all your documentation and other communication, you must realize that members of your audience outside the Capstone Design Program do not know what the various acronyms mean, such as PUD, TAD, and PPD. It is okay to use the acronyms, but only after introducing/defining each; for instance, “In the attached Technical Archive Document (TAD)…” and then later you can write it as “The TAD illustrates that…” Though, introducing an acronym early on and then not using it until much later in the document is not very effective either.
4 References
Rather than numbering references sequentially relative to their order of appearance in the document, number them sequentially relative to when they are added into document; this is to avoid the non-value-added busy work of renumbering existing references when new references are added at a later date. Use the FML prefix as described in the doc-prep guidance for the Individual Research Document (IRD) assignment. References that are brought in by more than one member of the team should use the prefix TEAM, i.e., [TEAM##]. This is not a contest! The entirety of this approach, while being contradictory to the norm/standard-practice of (non-prefixed) sequential numbering by order of appearance, is used here to minimize the risk of errors in reference numbering by significantly reducing the burden of reference number management. We break with convention for good reason — to reduce the nonvalue-added burden on you so you can be more efficient in your work with less bookkeeping and error proofing.
Formatting of the reference list is governed by the IEEE Citation style document; this is a great, simple, efficient PDF document that gives many good examples (i.e., it teaches largely by example).
Your reference list will be presented on one or more two-column page(s) in your Technical Archive Document (TAD), which is in the aforementioned B-sized (11 × 17 inch) format. Your team’s initial references list will be compiled by merging references from all team members’ Individual Research Document (IRD) assignment, which is also in the B-sized format and includes a references page for each individual to accumulate their references. Your references list in the TAD will be created at the Problem Understanding Document/Review stage, and expanded from there throughout the course of the project. The references section of the TAD is after the final section of the body and before the Appendices; it is all set up for you in the TAD template you will receive soon.
Doc-prep guidance will be provided throughout, as needed, to help you manage your reference list over the course of the project, correctly and efficiently.
5 Appendices
The number of appendices in your Technical Archive Document (TAD) depends on the needs of the audience. A number of appendices are mandatory and already set up in the TAD template. You may add appendices beyond those if you feel it is warranted; this is rare, but an option if it makes sense. Specifically, Appendices A through E are reserved so you can start with F if needed.
Regarding content, remember that an appendix is for information not required to understand the content of the main body of the document. Appendices are for supplemental information that may be useful for the reader desiring more detail. So, if it is a piece of information or graphic you think is important but not necessary to read or view in the main body of the document (in a textual portion or a B-sized “summary” page), then put it in the appendix and simply reference it in the main body of the document (e.g., “Additional background information on material properties of options considered is presented in Appendix XX”).
Do not just do a data-dump in the appendices. No one needs to see every piece of MATLAB code, for example. Additionally, each appendix must be clearly labeled at the top of the pages; this is already done for you in Appendices A through E in the TAD template to be provided.
6 The Storyline — Saving the Most Important for Last!
It is important to see the entirety of your reporting as telling a story. Not that your writing is story-like (with the exception of the narratives related to current situation and future vision, which are told in a story-like fashion). The “storyline” is a flow of information throughout the documentation; it represents your line of thought as you work through the work you are presenting — your work-product. Remember, the reader is generally someone who is not as close to the project as you are. You will be living and breathing this work on a daily basis. Your reader is living and breathing other things. He/she is busy too. Making the reader’s life easier is always good for your cause. And remember also, most of your readers will be viewing this in a future where you are not available to answer their questions or to provide clarifications. This is important in any forms of your documentation and reporting, in particular the TAD as described below.
One key element of maintaining the storyline is the presence of “inputs” and “outputs” text boxes on many of the TAD pages. The Page Input helps the reader center their mind on the new topic at hand (for that page) and reminds him/her of the information that flowed into the work that generated the information on that page. This is important even if it flows from the immediately previous page; often this is not the case, though, as the design process is not purely serial. It is easy for someone to lose the storyline without some help from the author — you.
The Page Output provides information to “wrap-up” the work presented on that page. It can be conclusions, decisions (which are different than conclusions), or simply “where next.” Where next is generally always an element of a page output textbox. It indicates where this information is next used and for what and/or how it will be used. In a sense, it is the start of a virtual bridge that leads to the input textbox somewhere else in the document.
Hopefully you can see the logic in the following requirement: the Page Input textbox should be at the top left of the page and the Page Output textbox should be at the bottom right of the page (if at all possible; move elsewhere, if necessary, still preferably at the bottom somewhere). How you lay out the other information on a B-sized page is up to you. The examples provided in the templates are simply examples. Depending on the relative sizes of tables, illustrations, etc., rearranging your content relative to the examples may be needed. One exception is the requirement noted in regard to the Page Input and Page Output textboxes.
Google Docs, Google Slides, and Google Sheets are trademarks of Google LLC.
Microsoft and Excel are trademarks or registered trademarks of Microsoft Corporation.
MATLAB is a registered trademark of The MathWorks, Inc.
| © 2017, William J. Endres |
Updated August 28, 2022 |