Guidelines for a Directed Studies Report

report contents
report length



An undergraduate completing a directed studies project with me is expected to complete his/her project by handing in a report following the guidelines outlined here, on a mutually-agreed due date at the end of the term. While specifics of a project with me vary and will have been agreed on individually with me, the general type of projects in my group generally fall into one of three broad categories which I'll refer to below where relevant:

The report's principle purpose is to be of value in documenting the project such that a later researcher can benefit from the work that you did. When composing it, imagine yourself as that researcher reading your report and ask yourself:

A good report will not include any information or material which does not support these goals, since that would make it unnecessarily long and difficult to read.

LENGTH & Format

How long should your report be? It will vary depending on the requirements of the project. However, you should be able to get the message across in about 8-10 pages single spaced, 11pt font, with compact and carefully chosen figures. This does not include appendices which may be as long as they need to be.

For appropriate level of density, look at any conference or journal paper, e.g. those on the SPIN website. You may use a conference paper formatting template if you like (e.g. the ACM conference format); it is fine if you do not, however try to maintain this level of density so that the report will not become overly long.


Your report should have the following sections:

Title Page & Abstract

Include your name, the name of the project, the period during which it was conducted, and a ~50-100 word summary (abstract) of the project's purpose, approach and outcome.


This section should include the following elements.


Outline the solution you are trying for the problem. This has two main components:


Most projects involve building some type of prototype, although the nature and purpose of the prototype varies widely from project to project. E.g. the prototype might be an experiment setup written in Visual Basic, a physical mockup of a new device design, or a functioning engineering prototype of a new application interface or applied technology.

In all cases, explain the purpose the prototype is expected to serve (e.g. data collection in an experiment; communication of a new concept), then thoroughly document the prototype you built.If there were multiple or iterative prototypes, show the progression and explain what you learned from each step and how it related to the final one.

To document your prototype, include as appropriate annotated photographs and diagrams. Detailed drawings and schematics of engineering prototypes should go in the Appendix (below).


Two types of experiments are likely, if you did experiments at all:


Again, the type and form of your results will vary depending on your project type. "Results" are always factual (noncontroversial) reporting; save interpretation for your Discussion section.

If the final deliverable of your project was a

Note on completeness of results section: for space reasons, you might not include every item of data, the outcome of every analysis you perform, or every performance specification achieved; instead it is good form to highlight those which showed interesting as opposed to mundane or obvious results. However, it is obviously highly inappropriate to leave out data or an analysis of which you are aware because it does not support your desired outcome.


What do the results mean? What can you conclude from them? This section is where you include your interpretation. Be careful not to overstate your claims, and make it clear when you feel your results justify a conclusion drawn vs. when you are speculating (e.g. the data "suggests" or "promises" something, but further work would be needed to verify it). It's fine to do the latter as long as you don't give caveats.

Remember: every project if well designed should result in learning.
This is true even when your outcome is not what you were hoping for: it is probably still an original result, and has added to the body of knowledge of what works and doesn't work.

Conclusions & Future Work

Reiterate what you have done and learned. Then reflect on it: is this a useful line of investigation? What can you say now about how your application design should change?

If you recommend continuing this work, what would be your next few steps?


This section is not required, but should be included if you have any.


While the body of your report should stand on its own without appendices, I request that you also submit the following appendices as appropriate in order to document the work accomplished. Examples of material that might be included in such appendices are the following:


On the pre-arranged date, you should submit the following