...

1. You were just assigned a final project in your Computer Systems class. You need to write a report for next Friday, and give a presentation the following Monday.
   1. Your teacher reminds you that the presentation cannot be longer than 5 minutes, and must include a visual aid.
2. You just submitted the proposal for the group final project in your French Literature class.
   1. You remember that Tracey needs to return the book your group borrowed to the library.
   2. You decide Fatima will take over your responsibility to prepare the presentation.
3. You check what articles are scheduled to be written for this Thursday's newspaper publication.
   1. You decide that there should be a newspaper article about MIT 150 this week, and assign Jason and Matt to write it. It needs to be completed by Wednesday night.
4. You plan what you will do tomorrow, and then go to sleep.

Results of Usability

...

Testing

Reflection

• Discuss what you learned over the course of the iterative design process. If you did it again, what would you do 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: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.

The most important thing we learnt is that user testing is really important!

The most important thing we learnt is that user testing is really important!

If we had to do it again, I think a heuristic evaluation of our initial designs would have been useful, to get some very early feedback on our design (GR2) before even doing the paper prototypes. We spoke to some classmates about our design, but a more in-depth review would have pointed out some obvious problems that we could have then avoided in the paper prototypes. Since this would have been relatively low-cost and easy to do, we would definitely incorporate it in the future.

We would also have done more rounds of testing with paper prototypes. We ended up throwing away a lot of code after doing a round of informal user testing on our initial design (before GR4), and a 3rd round of paper prototype testing would have brought up these issues before we began coding, saving us lots of time. At the same time, some issues became much more obvious once we actually wrote some code (for example, the paper prototype was very big, which hid the fact that screen real-estate was actually very limited in our initial design). Thus writing code and testing that was useful, and it was good that we weren't afraid to throw away code and restart during the early stages of codingIf we had to do it again, I think a heuristic evaluation of our initial designs would have been useful, to get some very early feedback on our design (GR2) before even doing the paper prototypes. We spoke to some classmates about our design, but a more in-depth review would have pointed out some obvious problems that we could have then avoided in the paper prototypes. We would also have done more rounds of testing with paper prototypes. We ended up throwing away a lot of code after doing a round of informal user testing on our initial design (before GR4), and a 3rd round of paper prototype testing would have brought up these issues before we began coding, saving us lots of time.

Reviewing the heuristic evaluations and deciding what advice was important and what we should ignore was also important. Some of the advice we got in our heuristic evaluation was very useful, but other advice was misguided (perhaps because the back-end functionality wasn't working yet, so users had difficulty evaluating some parts of the application). If we had blindly followed all the advice we got, I think we would've ended up scrapping a lot of key features that were important to our design but not clear in implementation as of GR4. Having a relatively advanced prototype as of GR4 helped a lot in this respect, though, because testers could get a better sense of our application.

Another aspect of the design process that was very important was the initial project proposal and analysis, background research, etc. Speaking to users and figuring out what they would actually want was really important and helpful in focusing our application and deciding what features were important. This also let us design our initial prototype with these features in mind, and get feedback on what to include and what to scrap. For example, the bulletin board was initially  

Finally, starting early and planning ahead was really important. GR4 and GR5 required *a lot* of work, so starting on them early was extremely helpful.