Introduction: Outline the project

• Project intro. The usual contextual information to get a reader oriented: The whole background on the Thirstbuster concept, why this is a viable and saleable idea, the target end-users of your particular app (bullet out demographic stats). Close with a brief paragraph explaining the purpose/nature of this document, i.e., it's the final usability report for the project and has such and such goals.
• Team intro: Quick overview of your team, with focus on the skills that each member brings.
• Solution Overview: Give the nutshell overview of your solution. Something like "In addressing the challenges outlined above, we have created a fully-functional web application for use as a point-of-sale application by the drink vendor employees . The central features of the application include: <itemized bullets on coolest features>. Might also put a small screen snapshot in here, to give readers a visual idea of what we're talking about. Put in a brief section on architecture describing your technology piece....just an overview, we care mostly about usability, not geek stuff!

Usability Testing

Intro: Give an intro to usability testing. Some words about your User-Centered Design philosophy and how user-testing fits into this would be appropriate. This leads into a detailed overview of your Testing Regime, ie, a timelines showing all your tests, followed by brief description/intro to each of the different kinds of test that you did. In this case, it will obviously be limited to the Expert Reviews done. To introduce the Expert Reviews, you'll want to:

• Intro -- Give an overview of what an expert review is and what you hoped (as specifically as possible!) to learn from it.
• Method -- Describe how you went about your review. Relevant issues include what version/flavor of expert review you did, how/who you selected expert, what materials the expert were given, what you asked them to produce including timeframe, and what (in general, i.e. a 2 page report) the expert gave you as feedback.
• End the methods section by introducing your experts: Give the name of each, and several detailed sentences on their qualifications. Should leave us saying "Sounds like they picked strong experts...I think the results they're about to show me will be valid".
• Important: At the end of the methods section, I would like brief critiques of each expert reviewer. This is a short paragraph for each expert where you start with some overall statements on the quality of the review, focusing on completeness and how useful it was to the team. Then bullet out (a) positive aspects of that review/reviewer and (b) negative aspects of that review/reviewer. End with a statement of score your would give that reviewer out of 100, and whether you would ever hire that reviewer again. You wouldn't necessarily share this in a real usability report (though it makes sense for this class)...but you would certainly note it in your project notes. No way you're going to re-hire experts that are lame!
• Results -- Then get to the meat: how you went about analyzing/distilling the expert review results, and (!!!) the key insights you gained. Start with a few sentences about overall results: were there any comments, how many, what did they show overall, what was the overlap/concurrence between experts, etc. A nice graphic or table helping us digest all this would be helpful. Then go through and just itemize the specific insights that you were able to distill from the expert comments. I emphasize the word "distill"; you don't just data dump a list of *every* comment from *every* exper. Try to digest them or distill them into useful broader points, e.g., "Several expert comments centered around our implementation of <feature area>. Two experts noted that <whatever>, while another pointed out the <feature> was also quite inconstent with other dialog boxes". You get the picture: thoughtful digestions of the expert feedback.
• Outcomes -- For each of the insights that point to a problem, describe what solutions (if any) the expert(s) recommended, what your team thought about those solutions, and the modifications that were made to the system. In some cases, perhaps the evidence to make a change was subtle or not compelling, and the team's conclusion might be "No action taken at this time. Not convinced there is a problem here, and will focus on this in upcoming end-user testing.".

Summary Discussion and Future Work

This just provides a closing discussion of the design process and usability testing. Go over the big picture again, e.g., "we carefully designed this system with such-and-such user input and did such-and-such testing, and this is what we think of the outcome". Itemize the strengths and weaknesses of the final system and/or your design process. For weaknesses, a discussion of what you might do differently next time is appropriate.

Finally, discuss "future work", i.e., things left to be done. This could be problems exposed by your usability analysis that were too serious to fix in a day or two, or features/functionality that you think, based on the usability results, might be useful and should be included in the next version.

End with a positive statement about your project and its impact on your education, the society, the world, etc.

Appendices: This is where you put materials related to the study. Make sure there's a table of contents indicating whats in here. Things that should appear here include:

• The packet you gave to experts as the basis for their reviews.
• The expert review you received from your expert, plus annotations/comments you may have made indicating your analysis of his/her findings.

The presentations should briefly describe your project, your usability testing process, with special focus on the expert reviews and improvements you made. Overall constraints are:

• Presentations should be 7-8 minutes in length. Rapid fire, so you'll need to move through it efficiently! Practice ahead of time! (Math: We have two hours for the final exam period = 120 minutes for 12 teams = 10minutes per team. Minus context switch= 7-8/team. Let's get it done!)
• All team members must take part in the presentation. Presentation skills are a key part of the CS curriculum!

Basically, the presentation should be a verbal summary of the final report. Here is a rough outline for your presentation:

1. Intro: Intro the project, and team. (10 secs)
2. Problem Statement: Briefly review Thirstbuster, what part you're doing, who your target end-users are (brief summary of demographic stats). (1 min)
3. Solution Overview: Intro your solution, i.e., the prototype you designed. This is a good place for a screen shot or two plus a bullet list of the hottest features of your app. Don't waste too much time here, we've already seen your prototype. Just show a few keys views by way of highlighting the main features. The focus of this presentation MUST be on the usability analysis process. (1 minute).
4. Intro to Usability Analysis. Talk about user-centered design, and how you applied it within your design process, i.e., how and where you got user input and how (in general) it was useful in guiding your design. (1 minute)
5. Expert Review: Talk first about the kind of reviews you commissioned: framework (e.g. Golden Rules), what instructions/materials you gave experts. Then briefly intro your experts: who and what qualifications. (1 minute)
6. Results: Overview the results you got back (table: #comments for each expert, main areas of violation or concern). Then outline how you digested the combined feedback, e.g., prioritized list of things to fix or not fix, etc. (1 minute)
7. For the top few problem areas, talk briefly about how you improved you UI to address it. (1 minute)
8. Conclusions regarding this design experience: Close with a discussion of the value (if any) that you saw in usability testing, user-centered design as whole. Focus on what you would do differently based on what you've learned next time you do a project like this. (1 minute)

Remember: time is limited! Make your presentation a tight story that flows easily from start to end. This means consistently appropriate level of detail (rather than almost nothing in some places, excruciating and meaningless detail in others), and proper focus (on the MEAT, the usability tests and results). Here is a link to a sample presentation grading sheet to get an idea of what I'll be looking for.