Team Assignment #1: Find a Team, Find a Project (3 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 multiple 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 3-4 people. Teams will primarily be formed based on the results on the first brainstorming exercise and in-class discussion. A directory of all students in the class will be posted to help you with informal networking to find teammates. At least two people on your team should have solid programming skills in the same programming language or platform that your team decides to use. 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 ...@neu.edu.

Group projects will involve the design of health interfaces for older adults users. Non-technical, older adults who will be evaluating your interface at the end of the semester. 

Here are some guidelines to help you develop your project proposal.

Your project must

• Have a substantial user interface. A health screening system that simply administers a questionnaire is not enough.
• Be interactive. A patient education system that simply displays a page of text or sequences through a series of pages would not be acceptable.
• Work robustly. You will need to fully build what you propose. Ideas are not enough. 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.
• Contribute to health or health research.
• Solve a real-world problem.
• Be targeted for and tested with older adults.

Your project should

• Be creative.
• Be original.
• Be non-obvious.
• Have a “wow” factor.
• Allow you, at the end of this course, to have an amazing system to add to your design/programming portfolio.

One way to figure out if your ideas is creative, original, and non-obvious is to do a lot of searching and reading on your own of research papers in the HCI literature to figure out what really is a new idea. The instructor will tell you when an idea does not meet these criteria, but it will be left to you to figure out why and propose alternatives. Coming up with a good idea, and knowing when and having the courage to switch ideas when you discover one is not good, is one of the biggest challenges in this course.

Your project must fall into one of these three categories:

• A health-related application for older adults that can be used in a senior center(to facilitate goals/tasks you identify)
• A “serious game” for older adults to generate a food nutrition database for researchers
• A health-related application for older adults that meets guidelines for an available software application or mobile application competition (e.g., see this example) (with the caveat that this option must be approved by the instructor and there are important restrictions with respect to deadlines, scope, etc. )

An important note: Your technology must run robustly on standard Windows-based PCs or Android phones/tablets. Students without substantial mobile experience are strongly encouraged to simulate their interfaces on PCs in a language they already know well to reduce the complexity of project implementation. 

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 someone.
2. Target users. Characterize the user population. (Be much more specific than "older adults" ... which older adults? Motivated by what?)
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.

Team Project Assignment #2 – Task Analysis and basic GUI (1 week)

Your mission in this exercise is to design the best interface you can to address the task described below. You will have one week to employ the skills you have learned to date to develop the design for an interface. Your goal will be to storyboard the interface in as much detail as you can so that someone can understand exactly what how it would work and critique it, and to implement a test screen that shows that you have the ability to use basic GUI components in your language of choice.

The Task:

- A relative died and left you as the proud owner of of the "Nerd Bistro," one of the new hippest spots to socialize and eat in town. As part of the experience that makes the restaurant unique, it uses the latest and greatest technology. Before your relative passed, she had ordered enough tablet computing devices so that each diner could have a tablet for electronic ordering and service during the meal. You goal is to figure out how to use these tablets to enhance the dining experience for older adults (and others).

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, identify each one. Identify all stakeholders in your application.
• 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.
• Basic GUI. In your language of choice you will write a demonstration program with a basic GUI. This should be one or more screens of your interface. You must use these GUI components:
  • Two Labels, one with an icon.
  • Two Buttons, one with an icon.
  • One ButtonGroup with at least 3 RadioButton options (with toggling between buttons functional).
  • Two CheckBoxes.
  • One ComboBox with at least two items.
  • One TextField One Panel with a titled border enclosing at least one other component.
  • One tool tip on one component.
  • One Menu with at least two options.

Important note: Your interface may not require all of these widgets. If that is the case, use the ones that you need and then create another screen that includes all the rest and shows you know how to implement them. You do not need to implement the actual operation of the interface, just show screens that clearly demonstrate that you know how to use the widgets.

What to Post. Your user analysis and task analysis report should include the following parts:

• Title. Give your application a title.
• Methods. Use Soft Systems Methodology (Ch 13 of Dix) to characterize the problem.
• Tasks. Describe 6 (or more) tasks you have identified. Every task should have a goal, preconditions, subtasks (if any), and exceptions (what can go wrong). Also include a paragraph describing other relevant features of the task, such as time constraints or frequency of use.
• Storyboard. Hand in a detailed a storyboard for your application that fully shows the operation of the proposed interface.
• Basic GUI program. Post an executable and instructions on how to run your basic GUI example. It must be easy for us to run the software!

Team Project Assignment #3 – Interaction Metaphors and StoryBoarding (1 week)

In this team assignment, you will continue the design of your term project by exploring possible interaction metaphors and combining the work you did independently last week with the instructor's "challenge" comments.

• Problem. Clearly list the overall idea for your project and the problem(s) it will solve.
• Tasks. Combine and organize the list of tasks and subtasks from each individual assignment handed in last week. Develop a specific, well-organized list of tasks. very task should have a goal, preconditions, subtasks (if any), and exceptions (what can go wrong). Also include a paragraph describing other relevant features of the task, such as time constraints or frequency of use. Include bullet points describing what you learned when you tried to combine tasks from all the team members. (Note that the goal here is NOT just to combine the lists but to start with the separate lists and reorganize them into a new list that is better than each of the individual lists!)
• Metaphors. For six tasks, make a list of possible interaction metaphors for your interface, following the examples in the lecture from Rosson & Carroll Ch 3, Tables 3.1 and 3.2. For each of your tasks, list two options for interaction metaphors and some of their implications.
• Storyboard. After merging the ideas from each individual assignment (and taking into account the "challenge" comments that will be emailed to your team by the Instructor by Sat night) and thinking about metaphors, hand in a detailed storyboard for your application that fully shows the operation of the proposed interface. Include 2-3 paragraphs that explain how you have changed your interface in light of this exercise.

What to Post. Your report containing the above.

Team Project Assignment #4 – Design Sketches and Paper Prototyping (1 week)

In this team assignment, you will continue the design of your term project by exploring possible design options.

• Preliminary interface design. Based on the feedback you will be sent by Saturday from your prior team assignment, refine your idea. 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. You should be responding to the feedback you are getting from Stephen but also feedback you should be eliciting from others. It is your job to use the ideas discussed in class to refine the "big ideas" behind your proposal.
• Storyboards. Based on the feedback you will be sent on Saturday from your prior team assignment, refine your idea. You will be sent a short persona/problem description where a hypothetical user experiences a problem. You must adapt your storyboard for this example. Your storyboard should be substantially more detailed than what you turned in last week. Remember that the storyboard is different from screenshots because it shows more context about what the user is doing. It tell's a story of the use of the app and the problem(s) being solved with it. Do not just have the storyboard describe the simplest case. Your goal is to have the storyboard show how your design would work well in the more complex situations (where lesser interface designs might fail). The storyboard should clearly indicate what things about the design are going to make it successful with older adults.
• Paper prototyping. Develop a paper prototyping kit and practice using it on at least one friend who is not in the class. One or two teams will be selected to do paper prototyping (with Stephen as the user) in class. We will critique the team's prototype and also the paper prototyping session. Follow the suggestions mentioned in class and the suggestions in the Rettig paper. Remember that you are creating paper tools that allow you to manipulate the interface as a tester "uses" it. You are not just handing in screenshots.

What to Post. Include the following:

• Preliminary interface design. Provide a bullet list describing how your idea has evolved and the specific strategies from class and the readings that you have used to refine it.
• Storyboard. Someone who knows nothing about your idea should be able to look at your storyboard and understand the problem(s) you are solving and see evidence that the interface concept is going to actual have the ability to do so.
• Paper prototyping script. Turn in the script you will use when using your paper prototype. This script should explain the problem your interface is trying to solve, set the context for the tester, and provide the tester with a set of tasks the person should try to accomplish using the interface.
• Paper prototype materials. Bring your paper prototyping materials to class in an 8.5x11 envelope labeled with your team member emails. Include a printout of the paper prototyping script. You will hand these in after class so please make a photocopy of the materials so your group has them during the week. Your next assignment will also involve paper prototyping.
  

Team Project Assignment #5 – Paper Prototyping (2 weeks)

In this team assignment, you will do a full paper prototype of your interface. Your paper prototype should be able to handle anything that someone could do with your interface. You will then test the prototype with three older adults in full paper prototyping sessions. In response, you will redo your prototype.

For most teams, based on where things are at right now, this will require a lot of work! Get going!

What to Prepare. Before testing your prototype, you should:

• 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. Use all the tips and tricks in the readings and discussed in class.
• 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. You will read this to your test users. This is not a manual or quick-reference card. It should absolutely not describe how to use the interface.
• Write 3 scenario 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. Some tasks may be brief (5 minutes), but others are likely to take longer. Your tasks should not be trivial; in fact, your tasks should be some of the most complex that someone might have to do with your interface. You will read these tasks to your test users.
• Choose roles for your team members. One person must play the computer and one should play the facilitator. The other team members 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 tasks you chose, as well as all major functionality you propose to build.

Before you run tests with older adults, you will do at least two tests with two different family members or friends who are unfamilar with your project.

Testing. When you run your prototype on a user, you should do the following things:

• 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. Use the tips discussed in class and in Rettig.
• With at least one of your tests with a friend: using either a mobile phone or a webcam, videotape your process (try to show screens and hands, no faces of testers). (If you can videotape one test with an older adult, that would be excellent, but don't make anyone uncomfortable.

Revise your paper prototype, and then run at least two additional tests with older adults who are in your target user group. It is up to you to find older adults to test with ... you will need to be resourceful.

What to Post You should post a report with the following parts:

• In an envelope, prototype parts from part 1 (before your revision).
• Briefing. The briefing you gave to users.
• A brief description of each person you tested with and where you found them (no names, please).
• Scenario tasks. The tasks you gave to users, exactly as you wrote them on the cards.
• In an envelope, prototype parts from your final paper prototoype (after all your revisions).
• Observations. A bullet list of usability problems you discovered from the the four testing sessions, and your proposed solutions.
• Video of at least one of the sessions.

Optional Team Project Assignment #5b – Paper Prototyping (1 week)

This is an optional but strongly recommended team assignment.

Revise your paper prototype one more time based the in-class paper prototyping session. Prepare your interface for a session with Stephen. Schedule this session the week of March 19th ... the earlier int he week, the better. Stephen will provide feedback on your idea and suggestions on changes you should make prior to handing in a final project.

You should have the entire interface implemented on paper for this session.

What to Prepare. Before testing your prototype with Stephen, you should:

• Stephen is familiar with you and paper prototyping, so there is no need to spend time on introductions, etc. I know you know how to do that now. We will launch right into prototyping session and be a bit more informal. I still don't want you explaining anything unless you are asked. Your job is to listen and take notes about problems you need to address.
• Please have your entire interface implemented on paper, including help and instructions should those be necessary (hint: if your interface requires a lot of "help" buttons you probably still have design work to do)
• Tell me succinctly what problem your interface will solve for older adults.
• Have at least 3 tasks perpared that I should do. These should be high-level tasks (e.g., "find a volunteer to shovel snow") not low-level tasks (e.g., "login to the system").

What to Post:

• Post a bullet list of things you need to fix that were mentioned in the session.

Teams that complete this assignment and make changes to their design in response are likely to end up with substanitally improved final projects.

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 back end. 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.
• 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 evaluated by your classmates in a class exercise. You must make it easy for other people in the class to be able to run your prototoype. If your prototype requires special hardware, you are going to need to bring whatever is required to run your software to class sessions from now through the end of the course. 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/platform is commonly available.

You should create a separate web page for your evaluators (linked to your project web page) with the following information on it:

• A link to your prototype (your prototype must remain frozen and accessible at this location for the remainder of the course, warts adn all).
• Startup instructions on installing/running whatever software is required to run your prototyping (this MUST be easy). Specify the platform and browser requirements for your prototype. Give any special instructions for starting it up. If running your prototype requires special hardware that others are unlikely to have, provide instructions on how to schedule a time to get access to the equipment required (e.g., large blocks of time when you will be available so someone can try it).
• Briefing (from T5). The briefing you gave to users of your paper prototype describing the purpose of your application (i.e., the problem(s) it solves or helps with) and background information about the domain.  

This must be posted by the beginning of class on March 29, because other students will be testing your interface during class.

Hint: You might think about getting a start on the project report at this point, see T9 below.

Team Project Assignment #7 – Heuristic Evaluation & Prototype Revision #1 (1 week) 

This assignment is identical to assignment T6. Please do not overwrite/change assignment T6. You are posting a new version of everything (this is so we can see how your idea has evolved from one assignment to the next).

What to Post   

• A link to your revised prototype (your prototype must remain frozen and accessible at this location for the remainder of the course, warts and all).
• Revised startup instructions (see last assignment)
• Revised briefing (see last assignment)
• After you receive the heuristic evaluation from your classmate (and Stephen and Zeeshan) you should assign each problem identified a severity rating (cosmetic, minor, major, catastrophic), and brainstorm possible solutions for it. Document if/how you have modiied your system to correct as many of the problems found as possible (in priority order). If you do not address a concern, then justify why.
• A bullet list indicating everything else you have changed/improved from T6 to T7 in your interface design and implementation.

Team Project Assignment #8 – User Testing & Prototype Revision #2 (1 week)

In this group assignment, you will conduct one or more user tests of your interface. It is up to you to find at east one older adult in your target user group to test with ... you will need to be resourceful.

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.

Conduct a formative evaluation with each user:

• Provide your briefing.
• 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.

If you can test with more than one user you should try to do so (because you will improve your idea), but only one is required.

What to Post

• A link to your revised prototype (your prototype must remain frozen and accessible at this location for the remainder of the course, warts and all).
• Revised startup instructions (see last assignment)
• Revised briefing (see last assignment)
• Observations. A bullet list of usability problems you discovered form the user test(s), severity ratings, and status on fixing the problems.
• Video of one of the sessions.

You need to be prepared to run an additional user interface test in class with your latest design.

Team Project Assignment #9 – Final Interface and Report

On April 19, your team will give a presentation of your project following these presentation instructions and the linked template: final presentation instructions.

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 carefully selected screen shots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluation phases (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 one or more 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.

Your report (including references and figures) should be no more than 8 pages long, following the CHI long paper format.

A this point, the expectation is that you have a robust, well-designed, and creative user interface that solves a real problem. It should reflect a great deal of progress from prior versions, even the version demonstrated in T8. Keep in mind what is being assessed is not only the idea, but evidence of major improvements in the design from prior assignments.

What to Post 

• A Word (ideal) or PDF of your report (It is easier for me to provide feedback if you submit a Word document)
• The Powerpoint file for your final project presentation
• The final version of your interface with all instructions necessary to run it. This is the version that Stephen will use when assigning the final project grade.