Design

• Describe the final design of your interface. 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).

The final design of the website was extremely focussed on a bulletin board, allowing users to post notes to their board and arrange them however they want.

In our initial paper prototypes, the bulletin board was only a tab, and each 

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 (but don't identify your users by name). Describe how the users were briefed and what tasks they performed; if you did a demo for them as part of your briefing, justify that decision. List the usability problems you found, and discuss how you might solve them.

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!

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. 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). 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