Final Project Presentation and

Report
We are at the end of the semester and it is time to present what you have
accomplished. You should be proud of what you have done and we want you
to tell us why. You will do both a written report and a presentation. (We also
want copies of your working code.)

GRADING:
The final presentation is 10% and the final implementation is 25% of
the team project grade. This is a bit confusing since we are including the
demonstration of your system in the final presentation.
We will be grading your presentation on how well you communicate
what the project is and how you accomplished it.
We will be grading the final implementation based on its performance in
the presentation and your final report. It is here that we will try to reconcile
the wide variation in scope between projects. So if you took on a rather
simple challenge with easy-to-meet requirements, you will need to
demonstrate the thoroughness of your problem finding, robustness of your
working final project, and convince us that your user testing shows the
superiority of your idea. On the other hand, if you took on a very complex
challenge with lots of details for which the implementation is equally
complicated, we want to know why that was the right thing to do. (But we
might cut you a little slack if the implementation is 95% perfect instead of
100%.)

Project Presentation
SEQUENCE:
By now you should know which day you will be presenting on.

FORMAT:
Each team should have 11 minutes.

Day 1 (Mon 4/26 / Tue 4/27): Guaranteed 11 minutes plus class

feedback.
Day 2 (Wed 4/28 / Thu 4/29): Guaranteed 11 minutes; feedback is not
guaranteed.
Day 3 (Mon 5/3 Tue 5/4): Maximum time 11 minutes, plan and practice
for even less. No time for feedback.

While we have some things we want you to cover in your presentation

(see next item), the actual form is up to you. This is a chance to be creative
(such as performing your scenario as a skit with props, showing a video of
your user’s actual environment, re-creating your empirical user testing, etc.);
risk-taking will be rewarded, particularly on day 1 (since you can repair any
mis-communication that results in your written presentation).

The best way to deliver your materials is to have the running demo
and presentation on a laptop. If your team does NOT have access to a
laptop, please let you GTA know ASAP; they particularly need to know if your
demo does not run under C#.
We will strictly enforce the time limit and the requirement that all
PowerPoint slides and demos MUST be delivered to your section GTA 3 hours
before class time.

CONTENT:
The presentation must include:
- a working demonstration of your project. This should include a
scenario and claims analysis.
- your user requirements and how well your project met those
requirements
- the most significant factors and events that shaped your design
- any factors that altered or refined user requirements along the way.

Since everyone in the audience has done more or less the same
process, please avoid presentations that are of the form “first we did this,
then we did that, and then we did this next thing”. Tell us only the most
important things that shaped the final result. Reflections on what were
mistakes that you would do differently are especially valuable.

OFF-LINE DEMONSTRATIONS:
Your team may be asked for an additional demo after the presentation
so that we see close up for ourselves what it does. Do not be alarmed, if we
do. This is because we either want to verify something we did not understand
when sitting in the audience or it was so cool, we just want to play with it.
Your classmates may also want to try out what you have created and
we would encourage you to accommodate them if you can.

GRADING:
The final presentation is 10% of the team project grade. This is your
project’s big moment in the sun, so we will be grading on how well you
communicate. Remember, “commodity, firmness and delight” are three
elements of a good design and you are designing a presentation.
FINAL PROJECT REPORT:
DUE:
Last presentation day: Mon 5/3 (section 2)1
Tue 5/4 (section 1)

FORMAT:
1. Three to six typed pages. Each members’ name and number at the
top.
2. In addition, attach the feedback reports you received and notes you
took during your mid term presentation. (You were asked to save them.)
3. A “ZIP” of all relevant files (source code, libraries, executable, etc.)
and attach as a CD or e-mail to the GTA.

CONTENT:
The report must include:
- an illustrated guide to your interface. This should include a scenario
and claims analysis (which you will have created for the presentation
anyway). Illustrate with screen shots, annotate with captions,
arrows, boxes, etc – whatever graphical device that will make it clear
how it is used.
- your user requirements and how well your project met those
requirements. (Your previous team report came up with use testing
issues – how did you respond to them?)
- the most significant factors and events that shaped your design.
- any factors that altered or refined user requirements along the way.
- Reflections on what were mistakes that you would do differently if
you could do the project again
- A list of credits describing which team member did what.2

This report will be more thorough than your presentation and should
hang together as a narrative. That means you may end up having to do a bit
of “first we did this, then we did that.”
Where appropriate, report on any methods you used and reflect on how
well they worked.

GRADING:
Superior reports will be those that show the growth of the team as well
as the design of the interface. Some ways of doing that will be by referring to
design methods, to working in a team, to what “design” has come to mean to

1
Section 2 has one more class (on Wednesday 5/5) than section 1.
2
WARNING: This is sometimes very contentious. We are interested in your
understanding of the strengths and weaknesses of each team member. We are NOT
using it to distribute the team grade. If you believe team members deserve very
different grades for the project, see “TEAM GRADE ISSUES” for how to let us know.
each member of the team, and any good questions that led your team to
further investigations.

TEAM GRADE ISSUES:

Some teams have had their ups and downs during the semester. If
you feel very strongly that the team grade should NOT be given equally to all
members of your team, please contact us NOW. If you have come to us
about this issue during the semester, please let us know how things have
worked out.

PORTFOLIO:
You should take great pride in this project and save it for your
portfolio. The portfolio can be useful for job and graduate school applications
– or for reminding yourself of the elements of HCI.
As I mentioned in class, the easiest way to create a record of this
project is to start with the illustration of the system that you include in your
final report. Imagine that you would be sending it to your family to explain
what you did in this class; so tell the shortest and simplest story about who
the users are and what it does. If your family can understand it, then it
probably is just about right.
We are available to help you with this if you have questions.