Research Project Report Guidelines

Guidelines for a Directed Studies Report

overview
report contents
report length
submission

OVERVIEW

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:

experimental: you built an experiment setup and conducted human-subject experiments to answer some psychological question.
conceptual design: you analyzed an interface application and then performed the conceptual design for a physical interface for that application. You did a combination of prototyping which involved some level of form studies, paper prototypes and interactive computer-based simulation; and you obtained some form of potential-user feedback based on these prototypes.
engineering design and/or prototyping: you designed and built an engineering prototype of some kind of physical interface; possibly based on someone else's conceptual model, or possibly out of your own ideas.

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:

Do I understand why the work was undertaken in the first place? What is the point of it?
Can I understand what was done, exactly? Is the language clear and are the figures and photographs supportive?
Is there sufficient detail so I can critique the work and decide whether I agree with the conclusions, and even the approach?
Can I in all essential details reproduce the experiment / concept / hardware solely from the supplied documentation?

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.

CONTENTS

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.

Introduction

This section should include the following elements.

Describe the problem
Tell your "story": the larger goal to which your project is the first step. The more compelling your story, the more intriguing your actual work. Include a description of the overall problem you are solving. For example the overall problem might be "making GUI's accessible to blind people" - you are unlikely to solve this entire problem with your project, but you will be biting off a piece of it.
Justify the approach you will be describing below: persuasively set up a case for why your approach is an interesting one by your presentation of the problems with existing methods and the features of the technology you are using.
Overview the rest of the paper: in a sentence or two, outline what you will be covering in the rest of the paper.

Approach

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

State what your specific problem goal is: describe briefly the question your project addresses and what it will accomplish. This is very likely to be much narrower than the overall problem area above: e.g. following the above example, your own immediate goal might be "prototyping and analyzing a method for a vision-impaired user to read and respond to email using haptic feedback signals and notifications".
Describe how you have met this goal: e.g. the prototype you will build, the application analysis you will conduct, and/or the type of experiments you will run.

Prototype(s)

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).

Experiments

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

Formal (controlled) user studies in a laboatory setting. In this case, outline and justify the experiment design and analysis used. Document the working setup in the experiment room. Augment with diagrams, photos, etc as needed (ideally at least one photo of a user in action).
Informal user feedback from a prototype: indicate the methods you used to get this feedback, e.g. interviews, observation, etc.

Results

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

Formal user study: describe the subjects you tested, then show results graphically & statistically. Include both performance, subjective and anecdotal data as appropriate. Point out and explain any unusual features.
Conceptual design: your results are your prototypes themselves (which have already been described) and the feedback you received from potential users. Describe the latter in this section.
Engineering prototype: your results is the prototype(s) and the feedback your received from potential users. Describe an quantitative / qualitative features of the performance achieved with your performance (e.g. this is what it could do in the end, the bandwidth / throughput achieved, etc; and also describe the user feedback you obtained.

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.

Discussion

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?

References

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

Appendices

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:

Supporting detail of hardware setup: as relevant,
- source & description of components
- mechanical drawings
- electronic schematics
Source and a descriptive "readme" for any computer code you used; also include an executable in the electronic submission of your project
Extra analyses, or more complete documentation and graphical view of the analyses which you completed but did not include in the paper for space reasons
All steps & values in analysis
Any other relevant documentation

SUBMISSION

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

a paper copy of your report (don't need to include appendices)
Post or email zip file containing the following. Preferred method is for you to post on a webpage and email a link; I'll let you know when I've got it. If necessary, email me the zip file.
- electronic copy of document, including appendices. pdf format preferred, else postscript or MS Word
- computer code: (source)+ (executable) + (readme.txt) briefly describing function of each module
- all photos and diagrams used (jpg or gif)for "highlights" on website
  .please name files descriptively!