Project 3
This project, its decriptions and parts are used with permission from Scott Klemmer and Terry Winograd at Stanford.
The goal of the project is to use the methods discussed in class to design and test a working prototype of an interactive system that solves a problem that is significant to some group of users. This is a time-consuming project, so please be aware of the deadlines. The project starts early in the quarter to give you as much time as you can to produce a great project, so good luck!
Teams: Project teams will be formed by the instructor, who will assign you to a team of 3 or 4 students. We will attempt to balance the groups by programming, art, and design abilities.
Feedback: Feedback on your projects will be given to you during studio time and through the milestones. We will also discuss the projects in class periodically to get feedback from myself and your classmates.
Submissions: You will post all project deliverables online before class on the due date of each project part. Al project parts should be posted on your edlab webpages. We do not have a specific form to be used for the pages for your deliverables. If you're comfortable with a web-page design tool, feel free to use it. The easiest method is probably to write it up in Microsoft Word and save it out as HTML.
Late Policy: Please note that there are NO late days. Projects not handed in on time will be given a zero.
Grading: The project is worth 50% of your final grade, which will generally be the same for all members of the team. This may be modified based on the feedback your project team gives you. If you do significantly less work than an equal share, your grade will be adjusted accordingly. There are 10 parts to the project, each will be worth 5% of your grade.
| Project (50% of final grade) | Deliverables Summary |
| P1: Initial Project Point of View |
|
| P2: Contextual Inquiry |
|
| P3:Project Proposal |
|
| P4: Storyboards |
|
| P5: Paper Prototype |
|
| P6: User Testing |
|
| P7: High Fidelity Prototype |
|
| P8: Two-minute madness/Website update |
|
| P9: Final Prototype and Project Fair |
|
| P10: Final Writeup |
|
Grading criteria: The final project will be graded on the following criteria. We are putting this information on the overview page so you can get a better idea of the kind of project we are looking for.
- Project Idea : We are NOT grading your team simply on the coolness of the idea. We are interested in a good design and evaluation of some new interactive system that solves a realistic problem. Suppose your idea is to implement a class scheduling application for users:
- Bad: Simply re-implementing Spire with a faster database, or with AI. This is not the right class for that kind of project. Even just moving buttons around, or making them bigger, doesn't change the interaction of the system very much, it just changes the visual look of the prototype.
- Better: Using direct manipulation as the dominant interaction metaphor. For example, you can schedule your classes by dragging and dropping onto a calendar as opposed to using the current interface.
- Contextual Inquiry : We will grade this based on the quality of your method in finding representative users and and how much you discover about any issues you might be able to resolve with an interactive system. Take our scheduling application:
- Bad: You interview your dormmates and they complain about how slow Spire is and that navigation is difficult. The problem here is that you are not getting a good enough selection.
- Better: You interview a selection of undergrads from different years and majors (and they don't all live in your dorm)
- Great: You interview graduates, staff, and undergraduates in the Campus Center. You discover that graduates only take two classes. Staff members don't take classes but only schedule meetings, which do not always meet at the same time every week. Undergraduates have too many classes, so direct manipulation would clutter the interface.
- Project Proposal and Representative Tasks: Related to concept is your project's scope. You should choose good representative tasks that span a variety of different scenarios, instead of just being variations on a theme. Your project should not be trying to solve a problem that is too simple or too complicated. Suppose you are doing an auction website ala (ebay):
- Bad: Your tasks all revolve around making the checkout better. For example, an easy task is to checkout with one item, a medium task is to checkout with three items, and a hard task is to checkout with a different credit card then you normally use.
- Better: Your easy task is to find an item you are interested in purchasing. Your medium task is to place a bid on an item. Your difficult task is to set up a watchlist for a group of items you are interested in.
- Storyboards: This is the first real glimpse we've seen of your interface, so we care about the amount of thought you've put into coming up with an interface paradigm which can realistically evolve into a useful final product. Of course, we also want to see a good spread of activities in the tasks that you choose for your final three. Back to the ebay example:
- Bad: Your storyboards involve a user logging into the auction site and choosing between two options: "change my password" and "search." Obviously, your final product will house a lot more complexity than just two options at the outset, so it would be wise to spend some more time thinking through the navigation.
- Also Bad: Two of your tasks involve changing your user password, and the third with setting other preferences. This is bad because not only are two of your tasks exploring one part of your interface, all three are presumably relatively unimportant to the larger idea of what your project will do.
- Better: One of the storyboards exhibits your auction site, after login, giving the user a well thought-out set of options about what to do next. The user clicks on one, and proceeds to perform some meaningful activity that you've designed, with the storyboard disclosing the decisions the user makes at each step. Here we have been given a good idea of how the larger framing of the interface will work, and seen the complexity involved with the task.
- Paper Prototype: As with the storyboard, we want to see that your paper prototype has evolved out of a consideration of the range of activities your product will support. It must be robust enough to support user error, and gracefully handle the kinds of I/O needed in a prototype of your design idea. Back to the auctions:
- Bad: Your prototype contains a navigation pane at the top, with options like, "Home," "Search," "Tools," and so on; however, your prototype is not able to react if a user clicks on one of them, because they were not involved in any of your three representative tasks. The principle here: anything that will be interactive, must be interactive in your prototype.
- Better: Your team has created placeholders for all of the pages in the navigation pane which hold the basic content you would expect to see in them. That way, if a user mistakenly expects to find that rare Optimus Prime action figure auction in the "Tools" pane, he or she can recover from the error him/herself.
- Testing: Similar to needfinding, we will grade this based on the quality of your method. In particular, we are interested in seeing how you integrate the results from your tests and comments from your users into real improvements in your interface.
- Hi Fi Prototype Implementation: We will grade this based on how well your prototype deals with the representative tasks you have constructed, and how well it deals with errors. Suppose you are interested in using your mobile phone to help you do trip navigation:
- Bad: Your final implementation runs at full-screen resolution (1280x1024). This is bad because it does not accurately model the phone's resolution. It only has the representative tasks you came up with. However, they are canned, so that if anyone wanders off the pre-planned interaction path, your system does not work.
- Better: Your prototype runs in a limited resolution that models a phone(320x240). Instead of only implementing an error-free path for each of your representative tasks , users can make and recover from errors. Your prototype runs in Java or Flash or HTML (with some good javascript)
- Great: Everything from better, but you using the development kit from Nokia or Motorola to prototype your app.
- Too Much: You make it run on your fancy phone. We would rather you spend some time fleshing out the interactions in your system instead of spending time on low-level implementation details.
- Aesthetics: This is not a graphic design class. As long as your interface prototype is clean and well-organized this is fine. You do not have to have fancy animations or amazing 3D icons (unless for some reason your needfinding has discovered that amazing 3D icons are what is most important for a usable prototype)
Previous page: Project 2
Next page: P1: Initial POV