Group Project Design Document

Overview

In the second phase of the group capstone project, your group will develop a detailed design specification for your proposed technology, and test out a low-fidelity prototype of your design. In order to help you identify the requirements for your proposed technology, you will begin by applying at least two of the empirical data-gathering techniques discussed in Chapter 7 of the Preece text: questionnaires, interviews, focus groups, observation, and contextual inqury. Based on your preliminary empirical data, you will identify your stakeholders, and establish the functional, usability, and user experience requirements for your technology. At this point, you will be in a position to begin fleshing out the detailed design of your technology. You will conclude this phase of the project by constructing and evaluating a low-fidelity prototype. In addition to testing out your prototype with prospective users, you will be required to prepare for an in-class prototype walkthrough, which will provide you with additional valuable feedback on your emerging design.

Steps

1. Gather empirical data. The purpose of this step is to help you to formulate the requirements for your proposed technology. Using at least two of the techniques discussed in section 7.4 of the Preece text (questionnaires, interviews, focus groups, observation, documentation study), gather initial empirical data for your design. If multiple stakeholders are impacted by your proposed technology, it would be a good idea to involve representatives from each stakeholder group in your data-gathering efforts.

2. Generate scenarios. Scenarios are an excellent way to communicate the insights gained from early design data. Based on your data, describe at least five key scenarios to be supported by your technology. Note that, as discussed in the Preece text, capturing scenarios may lead to the discovery of new scenarios to be explored. Thus, the data-gathering and scenario-generation steps may inform each other.

3. Formulate requirements. The purpose of this step is to derive functional and usability requirements from the empirical data you have gathered, and the scenarios you have generated. Functional requirements state the specific functionality that your technology needs to support. They typically begin with "Users should be able to...". For example, "Users should be able to add a calendar entry." Usability requirements state how efficiently and effectively users can perform their tasks. It is important to state these requirements in terms of observable, measurable quantities. For example, "Users should be able to add a calendar entry in 10 seconds." Be as specific as you can; you will be marked down for vague usability requirements. Wherever possible, justify each requirement by grounding it in your empirical data.
   
   To ensure that each requirement is justified and can be tracked, fill in the following table to specify each functional and usability requirement:
   

   Functional Requirement	Empirical Source/Justification (Be as specific as possible)	Usability Performance and User Experience Targets

   
   Note that, in the "Usability Performance Target" column, you should specify at least one usability requirement (performance target) in observable, measurable terms, although you may find it appropriate to associate multiple usability requirements with each functional requirement. In addition, you are required to specify user experience requirements in this column. For example, suppose that you list the following functional requirement in column 1: "Users should be able to create a new calendar entry." In column 3, you might list "User should be able to create a new calendar entry in 10 seconds" as a usability requirement, and "Users should rate calendar entry as a 9 on a scale of 1 to 10 in terms of ease of use" as a user experience requirement. Note that you will be evaluating your progress toward these targets in the usability study that you ultimately conduct.
   
   
4. Create detailed design. The purpose of this step is to create a detailed description that can be used to communicate your design to others. Your description should be divided into two parts:
• Written part: This section should briefly describe the conceptual model upon which your design is based, along with the set of tasks that users of your technology will be able to perform. Communicate these tasks as a hierarchical tree structure that organizes the tasks logically into categories, just as the menus in an application do so.
• Digital low fidelity prototype and demo video: Use the WOZ Pro software to create a low fidelity prototype of your software. Your prototype will consist of (a) screen sketches that illustrate the key states of your interface for each task, and (b) transitions between screens for each task. Your prototype should be capable of simulating how a user would interact with your interface to perform each task. Using the free Camtasia Studio software, record a demo video (in .wmv format) that illustrates how a user would use your prototype to complete each task. Use narration and title screens to make it clear, for each task sequence, (a) what task the user is performing, and (b) how the user is performing the task.

 

5. Evaluate a low-fidelity prototype with real users. The purpose of this step is to get early feedback on your preliminary design. You'll do this by testing the WOZ Pro prototype you created in the previous step with real users in "Wizard-of-Oz" fashion: Present users with screens. Based on their interactions, present the next screen. Users can interact with the WOZ Pro prototype as though it were real. For example, to select a button, they can tap on it; to fill in a field, they can use a pen to actually write in the field.
   
   Formulate a realistic sequence of tasks that users will complete in this study. It would be best if the task sequence were based on one or more of the scenarios you generated in step 2. Recruit at least three people to perform the tasks as one of your group members simulates the interface in "wizard-of-oz" fashion. (Note: Participants in your in-class prototype walkthrough do not count toward the required total of three participants.) As participants work through the tasks, have them "think aloud"; that is, have them talk about what they're doing and thinking about as they work, and have them mention any questions that come to mind, or any confusion that arises. I highly recommend that you videotape each participant session and analyze it afterwards; however, in a pinch, it is OK if one of your group members takes detailed notes instead.
   
   When they're done with the tasks, conduct an informal interview with your participants. Ask them about their impressions of your interface. What did they like? What didn't they like? What other functionality would be helpful? Can they imagine using your technology in their day-to-day lives? How? Answers to questions like these can provide valuable data for your next design iteration.
   
   
6. Formulate a list of design problems and possible solutions. Based on your prototype study, identify any design problems, and propose possible solutions. Provide a screen sketch to illustrate each solution.

Deliverables

Write up and hand in a comprehensive report that describes what you have done. Your instructor will use the following assessment form to evaluate your report, which must include the following sections:

1. Introduction — Briefly introduces your proposed technology, and sets the stage for the report that follows. What is its purpose? Who are the stakeholders? Where and when will it be used? The last paragraph of the introduction should preview the rest of your report. The first sentence states what, in general, the purpose of your report is. (For example, "In this report, we present a detailed design of System X, which we derived from preliminary empirical data-gathering study, and which we evaluated through a preliminary paper-prototype study." The rest of the paragraph describes each step you took. (For example, "In section 2, we present a preliminary empirical study that helped us to establish functional and usability requirements for System X.")

2. Preliminary Data Gathering and Scenarios — Describes the preliminary empirical work you performed to help you establish requirements for your technology, along with the scenarios that evolved out of this work.

3. Requirements — Enumerates each functional and usability requirement using the three-column table shown above.

4. Detailed Design (Written part). Presents the written part of the detailed design, as described in step 4: (a) conceptual model, and (b) functionality.

5. Detailed Design (Prototype and demo part). This part consists of (a) your low fidelity prototype (a .woz file), and (b) your demo video (a .wmv file).

6. Low Fidelity Prototype Evaluation — Describes your prototype evaluation study. How many participants did you recruit? What problems arose? What solutions can you propose? To what extent does your preliminary design meet your usability requirements? (Include the tasks that participants performed as an appendix to your report.)

7. Conclusions — Summarizes what you did, and what you learned from this stage of the project. Conclude by describing your implementation plan. What is the target hardware and implementation environment? What parts of the interface do you anticipate you'll be able to implement on the computer?

8. Prototype Walkthrough — Three percent of your design doc grade will be based on whether your group performs a prototype walkthrough in class on March 18 or 20 (all or nothing).

One of your group members should hand in a CD consisting of (a) your written design document (a .doc or .pdf file; please, no .docx files!), (b) your low fidelity prototype (a .woz file), (c) your demo video (a .wmv file), and (d) your group's original project proposal document (a .doc or .pdf file; include the grading sheet in digital form if you can). Be sure that all group members' names clearly appear on the CD itself, and in all materials that the CD contains.

Remember, a key goal of this course is to help you develop your written communication skills. Make sure that your document is easy to read, and is in proper English. If English is not your first language, be sure to enlist an editor (who is a native speaker) before you hand in your report. This will give you a chance to improve your English, and will improve the general readability of your report for me and others who read the document on-line. I will mark you down if your document contains inordinate amounts of grammatical errors or incorrect sentence structures.