IS 4300: Human-Computer Interaction
home | schedule | readings | homework | team project | resources | students
Team Projects
Team Project Websites |
|
Name |
Who |
| Ben L., Isaac B., David C., Jake A. | |
| Louis C., William J., Nicolas M. | |
| Mark D. & Matthew M. | |
| Reed L., Jeff B. | |
| Mitchell D, Richard V., Dennis W. | |
| Chris S., William M., Lennon A., Niko S. | |
| Kevin C., James O., Matthew K. | |
| Jon M., Arash Y., Carly M., Matthew C., Liam F. | |
| Emily M., Esther M., Conor O. | |
| Katie S., Catherine P., Josh C., Brian K. | |
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.
Project teams may consist of 2-4 people. Teams will primarily be formed based on the results on the first homework, in-class discussion, class member course web sites or informal networking. One member of the team should set up a team web site on which you will post the results of team assignments. Ensure the names and email addresses are prominently displayed and that the page is well-organized. Post it to a server and dmail the names of the team members, your team name, and a URL to the team web site to is4300sp13@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 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.
What to Post
For every team project assignment you will post to you team project page. The contents of the post will change depending on the assignment. Your proposal should be about 500 words long, and include the following parts:
1. Problem: describe the problem you chose
2. Target users: who will use this application?
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.
4. Roles and Tasks.
For every assignment at the bottom of the post you should indicate the roles each team member played on the project. The roles are project manager, business analyst, architect, designer, web designer (person who posts to the web site), software engineer, and test engineer. For more detail about what each role entails, please read this. Multiple team members may play the same role and you will not need every role for every assignment. For each team member, please include not only the title of the role, but also the tasks they accomplished. If you need to add roles to reflect the work you are doing, that's fine.
I 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. Then you will update your web site accordingly.
Team Project 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). 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, using your Essential Use Cases as standardized tasks.
What to Post. Your report should be around 2000 words long and include:
1. Title: Give your project a title, if you haven't already.
2. Problem: Briefly restate your problem.
3. Users: Describe each of your classes of stakeholders, and persona(s) for your primary stakeholders.
4. Task scenarios: Write a 1-paragraph task scenario for each of the 6 (or more) tasks you have identified.
5. 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.
6. Team roles and tasks. (described in first assignment)
Team Project 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.
Use Cases. Expand each of your Task Scenariosinto a Use Case, including functions, links, objects, and constraints. Abstract these into a Content Diagram.
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), Use Cases, a Container Diagram, and team roles and tasks.
Team Project 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.
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.
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 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.
What to Post. Include the following parts in your report:
1. Design alternatives: Provide at least 3 rough sketches of design alternatives you considered, and describe how you settled on your final design.
2. 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.
3. 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.
4. Team roles and tasks.
Team Project 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.
1. 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.
2. 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.
3. 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.
4. 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 and/or videotape the sessions.
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. Ask the questions that you want answered. These might include: What was easy? What was difficult? What would the reasons be why/when they would use system? What would the reasons by why/when they wouldn't? How well would the system fit into their lives?What didn't they system do that they might want? .....
What to Post You should post a report with the following parts:
1. Prototype photos or videos of their use: Digital photos of the pieces of your prototype. Try to show the prototype in an interesting state, not just a blank window.
2. Briefing: The briefing you gave to users.
3. Scenario tasks: The tasks you gave to users, exactly as you wrote them on the cards.
4. Demographics of your test users, and description of the test scenario (time, place, equipment, etc).
5. Observations: Usability problems you discovered from the testing, and possible solutions. Describe what users did. You must test at least 3 users.
6. Results from interviews & other measures.
7. Team roles and tasks.
Team Project 6 – Computer Prototyping (1.5 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 Windows 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 homework 5 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:
1. A link to your prototype (your prototype must remain frozen and accessible at this location for two weeks after the due date).
2. Startup instructions. Specify the platform and browser requirements for your prototype. Give any special instructions for starting it up.
3. 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.
4. User analysis, task analysis, and scenarios (from T2).
5. Team roles and tasks.
Hint: You might think about getting a start on the project report at this point, see T9 below.
Team Project 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. Team roles and tasks.
Team Project 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
T9A
This week your team will give a 15 minute (max) presentation of your project. This talk should include the following:
1. Problem. (2 min) What user problem are you trying to solve? Who are the users? What are their tasks?
2. Demonstration. (6 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.
3. Evaluation. (6 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.
4. Summarize. (1 min) What are the big take aways? What did you learn? What would you have done differently?
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.
T9B
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 -10 pages long, following the CHI HCI Archive format. Post a PDF on your web site and also email it to me. Here are some examples of final papers from last semester: 1, 2, 3.
After our final class, please complete the Team Project Peer Evaluation Survey.