GUI Design Review Packet

This "Design Review" provides an intermediate step in the design process where you describe your design process: user studies and resulting design.

Complete Design Results. After you complete your user studies, you will analyze the results to come up a complete design packet. This has the following main parts:

1. Introduction (1pg): An overview of the project: the application you are doing, what the overall goals are, functional highlights, and outline of what you'll discuss in rest of the packet. The usual "intro and sales pitch" so that an outsider can pick up the packet, know what is going on, understand your solution concept, and instantly see where you're going with the rest of the document.
2. Your "Methods" section. This is where you describe very carefully how you collected your data. What kinds of user studies did you engage in? How exactly did you select your study/survey subjects? Randomly? From you immediate friends only (red flag!), etc. How many of each person for each type of study were done? How did the surveys/interviews/user studies go down? Basically, this information on how you went about collecting the data for your study is critical to help the readers interpret the significance of the results/stats that you'll be walking us through in the next sections. Since the data collected here is the basis for the following parts, your score on this piece will be driven by how much/thoroughly you collect data. See scoring table below.
3. User and task profiles (2-4pg). Provide a discussion of your user/task profiling results. There is no particular recipe for this discussion, so long as you are thorough and thoughtful: profile target users (age, skills, distinct subgroups, etc.); profile desired functionality and priority ranking, profile the user domain and environment of use (how, where, how often/intensively) that your investigation revealed. Nice graphs, charts, and other summaries of your stats in support are nice here.
   The point here is NOT not to merely dump out random stats and graphs! What is ultimately value is the ANALYSIS, that is, how particular observations you made in your user studies will shape your design. So after you introduce some of the data you found out, give a thoughtful discussion: show interesting statistical patterns you found... and then comment on how these findings might shape your design. For instance, maybe your interview data shows that 90% of your users never change a drink order after they submit it. So you point that out in your discussion...and then comment on how this made you change the priority of supporting this user task in your upcoming design. See what I mean? Raw data --> interesting stats/patterns revealed --> influence on design. In short, you SHOW how your design is being shaped by your deep knowledge of users and tasks resulting from your user studies.
4. Functional Specification (2-4pg). The functional spec should provide a fairly detailed description of the specific functionalities that your application will provide. Make sure to clearly connect all functionalities you're planning to have in your product to the user task profile that you've come up with! This is how you (a) avoid missing key functionalities and (b) avoid adding useless clutter and functionality just because "it's cool". Both the functional and performance specs will serve to guide and (later) evaluate the implemented prototype.
5. Appendices. If you used any surveys, interview outlines, or other "materials" in gathering info on your users, attach a blank copy of each here on the back, for reference.
   
   With respect to the functional spec. section, start with a short intro (place maybe graphic) in which you introduce the main functional modules/areas and discuss briefly how they interact to produce the overall system behavior. Then go into each of these modules in a subsequent subsection, enumerating and briefly describing each functional feature provided. Remember: each functionality should be backed by your user analysis; indicate how detailed functions contribute to user tasks from the task profile. Also remember that a functional specification discusses what your application will be able to do, not how. So don't describe the interface you envision --- just describe the functionality you will support. Finally, for each specific functionality, provide a performance specification that outlines your goal for how fast/efficiently/error-free the users will be able to perform this specific task. So for example: "Delete appointment: after having done it one time, users should be able to accomplish this task in an average of 2 seconds with zero errors across all subsequent tries". This is very important: it forces you to think about the usability of your application and sets specific, testable performance goals that your application will attain.

Here is a sample from a 2012 team that nicely illustrates what I mean by "don't just dump stats and graphs us; provide its implications for your design". See how they repeatedly (a) give a graphical summary of some statistic if their users, (b) then discuss some of the interesting highlights in the stats in the text, (c) then speculate on what that observation means for their design. Nice.

If you have questions on or want some additional guidance on how to create any of these documents, you should come to see me in office hours as needed.

Scoring Details:
My main goal will be to see that you've done a thorough job finding out about your user community and translating this into a solid design. Therefore, communicating clearly what you've accomplished is critical. Here is a matrix roughly outlining my expectations for this deliverable: