IS 4300 – Human-Computer Interaction

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

Project Assignments

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

P1	Project Assignment #1 – Find a Project (2.5 weeks, due 9/26) 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 is4300f16@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 displays static information or administers a form is not enough. (A very rough guideline: your finished project should have at least 3 major screens with at least a dozen UI widgets total.) • The user interface must be interactive (a "GUI"). 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, although it can be a substantial re-design of an existing interface. • Ideally, you should have 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.  If you want to develop for another platform (a smartphone, for example) it is OK to mock up the interface on the desktop using Netbeans. If you want to develop using something other than Java or Netbeans, please talk to the instructor first. What to Post Your proposal should be 2-4 pages 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. Solutions. Each team member should provide 5-10 rough sketches describing possible designs (or partial designs) to solve the problem. Team members should work separately on these. Each design should consist of a very rough sketch (like this) and a few sentences of description. Crazy ideas are welcome at this point. You are not committed to these solutions at all, since you may find after building and evaluating some prototypes that entirely different solutions will work better. It is strongly recommended that each team member get a project sketchbook and start carrying it to jot down ideas and inspirations for their project. P1a. First draft. This can just be a few sentences describing your idea emailed to is4300f16@ccs.neu.edu. The instructor will respond with an 'OK-to-proceed' or suggestions for changing the scope of your project, to ensure it meets course objectives and is do-able in a semester. P1b. Second and final draft.
P2	Project Assignment #2 – Requirements Analysis (1 week, due 10/3) In this 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 a brief persona for each type of primary stakeholder. 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 3 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 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. Problem scenario analysis. For each task, write a paragraph-length problem scenario: a concrete, realistic example of the task, following the examples in Rosson & Carroll Ch 2 (Fig 2.13) covered in class. Usability requirements. Think about what usability metrics make sense for your project and specify at least two measurable usability criteria for your final system (e.g., "Users will score satisfaction at least 4.0 on a 1-7 scale following performance of two standardized tasks."). What to Post. Your report should be around 3 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. Tasks. Describe 3 (or more) tasks you have identified. Provide a Hierarchical Task Analysis diagram for each task. Problem Scenarios. For each task, write a paragraph-length problem scenario: a concrete, realistic example of the task, following the examples in Rosson & Carroll Ch 2 (Fig 2.13) covered in class. Usability requirements. Describe at least two measurable usability requirements for your system.
P3	Project Assignment #3 – Conceptual Design (1.5 weeks, due 10/12) In this team assignment, you will continue the design of your term project by exploring possible interaction metaphors. Metaphors Make a list of possible interaction metaphors for your interface, following the examples covered in class. For each of your problem scenarios list at least two options for interaction metaphors, along with pros and cons of each. Activity Design Scenarios Transform each of your problem scenarios into an activity design scenario, following the examples in Rosson & Carroll Ch 3, Figures 3.4 and 3.5. You may need to update your Task Analyses in the process. At this stage you should still be focused on the abstract steps of each task, including user input and system output actions. Inspiration Collection Team members should also be individually collecting ideas and inspirations for their project. These can be screen shots or sketches of related interfaces, design motifs that you think are appropriate for your tasks or users, or sketched designs for parts of your interface. What to Post. Your report should include three detailed activity scenarios and a list of the metaphors you are using. If you have updated your task models during this exercise please provide them as well.
P4	Project Assignment #4 – Design Sketches (1 week, due 10/19) In this assignment, you will continue the design of your term project by exploring possible design options, and sketching what your interface will look like. Interaction Scenarios Expand each of your activity design scenarios into full interaction scenarios, thinking aboutwhat the user perceives and the actions he/she performs at each major step in the scenario, following the methods outlined in Rosson & Carroll Ch 4 & 5 (examples). Preliminary interface design. Refine your interaction scenarios into a preliminary design. A preliminary design consists of one or more sketched windows or dialog boxes, along with the menus and controls that the user manipulates. You should meet as a team and share all of your sketches and design inspirations and downselect to one design. Each team member should then generate at least five rough variants of the design and downselect again. 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 on the next design iteration.  Storyboards. For each of your tasks/scenarios, 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. What to Post. Include the following parts in your report: Interaction Scenarios for each of your three tasks. Design Options. Show all design options you considered for your most important window or dialog box, and provide a brief rationale for why you selected it. Overall design. Describe your preliminary design by presenting sketches of all important windows and dialog boxes, and briefly explaining the function of each item. Scenario storyboards. Present each of your scenarios in storyboard form, including sketches to illustrate how your interface would look at important points in the task.
P5	Project Assignment #5 – Paper Prototyping (1.5 weeks) In this 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 the tasks/scenarios you have been working with. These use cases may be the scenarios you described in P4; 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. Note: If you are in a singleton team, you will be paired with another student: you should play computer for your own interface and the other student act as observer. P5a. due 10/24. 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. 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. P5b. due 10/31. 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.
P6	Project Assignment #6 – Computer Prototyping (2 weeks, due 11/14) In this 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. IMPORTANT: Your system must actually run and support your 3+ tasks to some level of fidelity. Other students in the class must be able to download your software and walk through the 3 tasks with little or nor help from you. Here are some issues you should not worry about in this prototype: Window resizing. Platform independence. Printing. You might pop up a window showing a mock up of what might be printed in a given situation. Playing video or audio. 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 application. In any case you must be able to have other students in the course be able to rapidly install and run your system. If you must develop for a unique device (e.g. iPhone) you must be prepared to loan 3-5 other students a device for a day each so they can do heuristic evaluation. 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). Your prototype must run and support your three tasks. Startup instructions. Specify the platform requirements for your prototype. Give any special instructions for installing and starting it up. Briefing (from P5). The briefing you gave to users of your paper prototype describing the purpose of your application and background information about the domain. Description of your 3 tasks you gave users in P5. Email the URL of this page to is4300f16@ccs.neu.edu. Hint: You might think about getting a start on the project report at this point, see P9 below.
P7	Project Assignment #7 – Heuristic Evaluation & Prototype Revision #1 (2 weeks, due 11/28) 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.
P8	Project Assignment #8 – User Testing & Prototype Revision #2 (1.5 weeks, due 12/7) In this final project 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 P7 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. Please use the usability.gov report format covered in class.
P9	Final Presentation and Report (last class meeting 12/7) P9a. On 12/7 (regular class meeting time) you will give a 7 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 please keep to your alloted time. There is no time to recover from technical difficulties, so if your demo is not working you will have to skip it. P9b. 12/12. Your final project report is reflective, covering all semester's project activities, including the following: Problem. What user problem were you trying to solve? Who are the users? What are their tasks? Design. Briefly 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. Summarize what you learned from the various rounds of testing. 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 considered at each point in the process, and rationale for your design decisions. Your report should be at least 6 pages long and must be posted by end of the day on 12/12.