IS 4300 – Human-Computer Interaction

[Syllabus] [Schedule] [Homework] [Projects] [Resources] [Directory]

Project (Team Assignments)

The following assignments are to be completed by teams and posted to your team web page by the start of class on the week due.

T1	Team Project Assignment #1 – Find a Team, Find a Project (2.5 weeks) The heart of this course is a semester-long project, in which you will design, implement, and evaluate a user interface. User interface design is an iterative process, so you will build your UI not just once, but four times, as successively higher-fidelity and more complete prototypes. In order to have time for these iterations, we need to get started on the project as early as possible. Project teams may consist of 2-4 people. Teams will primarily be formed based on the results on the first brainstorming exercise and in-class discussion. You can also use the Directory or informal networking to find teammates. Ensure that at least one person on your team has solid programming skills, preferably in Java. One member of the team should set up a team web page on which you will post the results of team assignments. Ensure the names and email addresses of the team members are at the top of the page and post it to a server. Organize the page so the instructors can quickly find your assignments each week. Email the names of the team members, a name for your team and a URL to the team web page to is4300f12@ccs.neu.edu. Here are some guidelines to help you develop your project proposal. • Your project must have a substantial user interface. A system that simply static information or administers a form is not enough. • The user interface must be interactive (a "GUI", per Stone Ch 16). A system that simply displays a page of text or sequences through a series of pages would not be acceptable, nor would a static page web site. • The user interface should not exist already as a commercial product (you should design something novel). • Ideally, you should have access to access to three people who are reprepresentative of the end users of your system. Your project should be fully implementable by the end of the semester, although we will consider larger projects in which you primarily develop the interface and leave some implementation details for later. Your interface should be implemented as a Java application or applet. What to Post Your proposal should be about a page long, and include the following parts: 1. Problem. Describe the problem you chose and how the system will help users. 2. Target users. Characterize the user population. 3. Solution. Describe a possible solution to the problem --- i.e., the interface that you envision, and how it will address the problem. You aren't absolutely committed to your solution, since you may find after building and evaluating some prototypes that a wholly different solution will work better. T1a. First draft. The instructor will respond with an 'A-OK' or suggestions for changing the scope of your project, to ensure it meets course objectives and is do-able in a semester. . T1b. Second and final draft.
T2	Team Project Assignment #2 – Task Analysis (1 week) In this team assignment, you will start the design of your term project by doing the following: User analysis. Identify the characteristics of your user population, as we discussed in lecture. If you have multiple user classes (types of stakeholders), identify each one. Create one or more personas for your primary stakeholders. Task analysis. Determine the tasks of the problem you've chosen, analyze their characteristics, and answer the general questions about tasks we asked in lecture. Think about other questions you should ask that might be relevant to your particular domain. You should find and analyze at least 6 tasks. If you can't find that many tasks in your problem, try drilling down to more specific tasks, and consider exceptional and emergency tasks. Write "Task Scenarios" (for different representative users and contexts) (Stone Box 4.3 pg 68) and a Hierarchical Task Analysis (as done in class) for each task. At this stage you should be focused on the abstract steps of each task, and should not be thinking about what your interface will look like yet. Usability requirements. Draft usability requirements that make sense for your application (a meaningful subset of those in Stone Table 6.1, pp. 105-106), using your Essential Use Cases as standardized tasks. What to Post. Your report should be around 4 pages long. Include the following parts: Title. Give your project a title, if you haven't already. Problem. Briefly restate your problem. Users. Describe each of your classes of stakeholders, and persona(s) for your primary stakeholders. Task scenarios. Write a 1-paragraph task scenario for each of the 6 (or more) tasks you have identified. Tasks. Describe the 6 (or more) tasks you have identified. Every task should have a goal, preconditions, subtasks (if any), and exceptions (what can go wrong). Include a paragraph describing other relevant features of the task, such as time constraints or frequency of use. Provide a Hierarchical Task Analysis diagram for each task. Usability requirements.
T3	Team Project Assignment #3 – Conceptual Design (1 week) In this team assignment, you will continue the design of your term project, by converting your task scenarios and essential use cases into a conceptual design. Concrete Use Cases. Expand each of your Hierarchical Task Analyses from T2 into a Concrete Use Case (per Stone Fig. 8.18 pg. 163), including functions, links, objects, and constraints. Abstract these into a Content Diagram (per Stone Fig. 8.19 pg. 163). Metaphors.  Make a list of possible interaction metaphors for your interface. For each of your task scenarios list at least two options for interaction metaphors that encompass some or all of the task, why you think they are appropriate, and some of the implications of your choice. At this stage you should still be focused on the abstract steps of each task, including user input and system output actions, and should not be thinking about the details of your interface's appearance yet. What to Post. Your report should include your list of possible interaction metaphors (at least 2x6), Concrete Use Cases and a Container Diagram.
T4	Team Project Assignment #4 – Design Sketches (1 week) In this team assignment, you will continue the design of your term project by exploring possible design options, and sketching what your interface will look like. Preliminary interface design. A preliminary design consists of one or more sketched windows or dialog boxes, along with the menus and controls that the user manipulates. Storyboards. For each of your Concrete Use Cases, describe how your preliminary interface would be used to perform the task. Use rough sketches to illustrate how the interface would look at important points in the task. Take a little time now to brainstorm a variety of different interface designs, taking into account your interaction metaphors from T3, and sketch them by hand on paper or a whiteboard. Then choose one that seems the most promising to focus on. When you draw your sketches, don't get bogged down in details like wording, icon appearance, or layout. Keep things simple. Focus on the model you're trying to communicate to the user, and think about your task analysis: what the user needs to do and how they can do it. Putting too much time into low-level details is pointless if big things have to change in the next design iteration. Hand-drawn sketches are encouraged. What to Post. Include the following parts in your report: Design alternatives. Provide at least 3 rough sketches of design alternatives you considered, and describe how you settled on your final design. Overall design. Describe your preliminary design by presenting sketches of important windows, dialog boxes, and menu trees, and briefly explaining the function of each item. Scenario storyboards. Present each of your Concrete Use Cases in storyboard form, including sketches to illustrate how your interface would look at important points in the task.
T5	Team Project Assignment #5 – Paper Prototyping (1.5 weeks) In this team assignment, you will do your first implementation of your term project, which will be a paper prototype. Your paper prototype should be able to handle at least 3 of your Concrete Use Cases. These use casesmay be the scenarios you described in T4; alternatively, you may want to choose different use cases that explore the riskiest parts of your interface, which are the ones that will provide the most payoff from prototyping. You will test your paper prototypes on at least 3 users. T5a. Before the next class, prepare your prototype and test cases, and practice "playing computer". We will review these in class. Build your prototype. Draw the static background, menus, dialog boxes, and other windows. Decide how to implement the dynamic parts of your interface. Hand-sketching is preferred. Write your 3 test tasks on separate index cards. Just write the concrete goal of the task (e.g. "buy milk, tomatoes, and bread"). Don't write the specific steps to follow, since that's for your users to figure out. The tasks should be brief, roughly 5 minutes to run. You will also read these to your test users. Choose roles for your team members. One person must play the computer and one should play the faciliatator. The other team members (if any) will be observers (although they may ask questions during the test if necessary). It may be useful for you to swap roles after every user, so that each of you gets a chance to try each role, but decide how you'll do it in advance. Practice running your paper prototype. Every team member should practice playing the computer, learning the steps involved in making the prototype functional, such as rearranging pieces and writing responses. It isn't important to be fast, just competent and confident. A few trials are enough. Make sure your prototype can handle the 3 test tasks you chose. T5b. You will then have one week to do field testing with users and write your report. Prepare a briefing for test users. This should be at most a page of information about the purpose of your application and any background information about the domain that may be needed by your test users to understand it. These are your notes for the briefing, so make them short, simple and clear, not dense wordy paragraphs. This is not a manual or quick-reference card. It should not describe how to use the interface. You will read this to your test users. [sample] Recruit 3-5 users who are as close as possible to your target demographic. Be sure to record demographic information (age, gender, education, occupation, etc.) for your report. Testing Users When you run your prototype on a user, you should do the following things: Obtain verbal consent for participation. Brief the user. Use the briefing you wrote up to describe orally the purpose of the application and background information about the domain. Don't waste too much time on this: 1 minute should be enough. Present one task. Hand the index card to the user, read it, and let them read it. Make sure they understand the task. Watch the user do the task. Take notes of your observations. Repeat with the other tasks. Run as many tasks on the user as you have time for. Bring extra materials. Having extra blank Post-it notes, correction tape, and index cards on hand will help you improvise if a user does something unexpected, or help you make small fixes to your prototype between users. Interview users, take any measures you think are important. What to Post You should post a report with the following parts: Prototype photos. Digital photos of the pieces of your prototype. Try to show the prototype in an interesting state, not just a blank window. Briefing. The briefing you gave to users. Scenario tasks. The tasks you gave to users, exactly as you wrote them on the cards. Demographics of your test users, and description of the test scenario (time, place, equipment, etc). Observations. Usability problems you discovered from the testing, and possible solutions. Describe what users did. You must test at least 3 users. Results from interviews & other measures.
T6	Team Project Assignment #6 – Computer Prototyping (2 weeks) In this group assignment, you will do the first computer-based implementation of your term project. Your computer prototype should be: High fidelity in look. Use this prototype to explore the graphic design of your final implementation. Lay out screens as you want them to appear in your final implementation. Make choices about colors, fonts, alignment, icons, and white space. Your prototype need not be pixel-for-pixel identical to your final implementation, however. Medium fidelity in feel. This prototype will run on a desktop computer with a mouse and a keyboard. Also, your prototype may not support some advanced interactions with high fidelity, such as drag & drop. That's OK. You can simulate these interactions with a little animation, or at least with a popup that describes in English what would happen. Medium fidelity in breadth. Your prototype should be able to handle at least the 3 scenarios you described in your task analysis. In addition, your prototype should include every major screen or dialog you expect to have in your final implementation. Low fidelity in depth. Don't implement any backend. Where system responses are needed, make them canned (i.e., always the same) or random. Write minimal code. Here are some issues you should not worry about in this prototype: Window resizing. Platform independence. Focus on Windoze for now. Printing. You might pop up a window showing a mock up of what might be printed in a given situation. After you hand in your prototype, it will be distributed to at least two of your classmates, who will do heuristic evaluations of it for individual homework I7 and give their reports back to you. Since your evaluators must be able to view and interact with your prototype, this puts some constraints on how you implement your prototype. If at all possible, implement your prototype as a Java applet that can be deployed off of your project web page. You can require evaluators to use a particular web browser and platform to ensure the correct appearance and operation of your prototype, as long as the browser is commonly available in one of the CCIS labs. If your prototype is unable to work under these constraints, talk to the instructor. What to Post You should create a separate web page for your evaluators (linked to your project web page, of course) with the following information on it: A link to your prototype (your prototype must remain frozen and accessible at this location for two weeks after the due date). Startup instructions. Specify the platform and browser requirements for your prototype. Give any special instructions for starting it up. Briefing (from T5). The briefing you gave to users of your paper prototype describing the purpose of your application and background information about the domain. User analysis, task analysis, and scenarios (from T2). Hint: You might think about getting a start on the project report at this point, see T9 below.
T7	Team Project Assignment #7 – Heuristic Evaluation & Prototype Revision #1 (1.5 weeks) At this point you will have a few days before you receive heuristic evaluations from your classmates. During this time you can continue implementing the “back end” of your system, but should not make any major changes to the UI. After you receive the heuristic evaluations you should assign each of these problems a severity rating (cosmetic, minor, major, catastrophic), and brainstorm possible solutions for it. Modify your system to correct as many of the problems found as possible (in priority order), documenting how you do this. What to Post A link to your updated prototype and a report describing how you responded to the heuristic evaluations.
T8	Team Project Assignment #8 – User Testing & Prototype Revision #2 (1.5 weeks) In this final group assignment, you will complete enough of the implementation to support user testing, conduct a user test of your interface, and write up the final results of the project. User Testing You will conduct user testing of your system. Prepare a briefing and three tasks. These may be the same ones that you used in paper prototyping, but you may want to improve them based on feedback from the paper prototyping. You may, if you wish, also prepare a short demo of your interface that you can use to show your users the purpose of the system. The demo should be scripted, so that you do and say the same things for each user. It should use a concrete example task, but the example task should be sufficiently different from the test tasks to avoid bias. The demo option is offered because some interfaces are learned primarily by watching someone else use the interface. Think carefully about whether your interface is in this category before you decide to use a demo, because the demo will cost you information. Once you've demonstrated how to use a feature, you forfeit the chance to observe how the user would have used it otherwise. Pilot test your briefing, demo, and tasks, before the user test session. Use another group member or another member of the class for your pilot testing. Conduct a formative evaluation with each user: Provide your briefing and (optionally) demo. Then provide the tasks one at a time, observe, and take notes. One member of your group should be the facilitator of the test, and the rest should be observers. Redesign Collect the usability problems found by your user tests into a list. Assign each problem a severity rating (as in T7 above), and brainstorm possible solutions for the problems. Then, fix your implementation to solve as many problems as you can in the time available, giving priority to severe problems. What to Post A link to your updated prototype and a brief usability test report.
T9	Final Report and Presentation (12/3) On 12/3 (regular class meeting time) your team will give a 10 minute (max) presentation of your project. This talk should include the following: Problem. (1 min) What user problem are you trying to solve? Who are the users? What are their tasks? Demonstration. (2 min) Demonstrate your design and implementation via a live demo of your system, working through one sample task. Discuss major design decisions. Run on YOUR computer to minimize compatibility issues. You should test with the projector before class starts. Evaluation. (4 min) Discuss the major findings from all three of your user evaluations (paper prototyping, heuristic evaluation, and user testing). This will be followed by a few minutes of Q&A during which time the next team will set up their computer. We are on a very tight schedule, so if you are still talking at 10 minutes you will be cut off. There is no time to recover from technical difficulties, so if your demo is not working you will have to skip it. What to Post Your final project report should contain the following: Problem. What user problem are you trying to solve? Who are the users? What are their tasks? Design. Describe the final design of your interface, including any redesign you did after user testing. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing). Implementation. Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface. Evaluation. Describe how you conducted your user test. Describe how you found your users and how representative they are of your target user population. Describe how users were briefed and what tasks they performed. Discuss the critical incidents you observed. Discuss any remaining usability problems that you didn't solve in your final design, and suggest solutions. Reflection. Discuss what you learned over the course of the iterative design process. If you did it again, what would you have done differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: what features to prototype, what prototype techniques to use, and how to evaluate the results. Important: Your grade is based as much on process as product. Provide evidence of the design alternatives you consdered at each point in the process, and rationale for your design decisions. Your report should be 8 pages long, following the CHI long paper format. Post a PDF if possible.