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

Home

Originally the home page had a tab in the lower right hand corner that would allow users to cancel a previously scheduled call, but from feedback we found that this wasn't externally consistent with other web pages. Instead we moved this functionality to the page header along with other options. Additionally this allowed the user to access these options regardless of the mode they were in.

Zip code results

The filter tab originally had radio buttons and an option for 'All,' but the heuristic evaluations correctly pointed out that check boxes would make more sense and provide greater flexibility for the user. We also added an input field at the top of the page that would allow the user to search a new zip code without having to return to the previous page (this improves efficiency).

Call now

One of our heuristic evaluators pointed out that we could improve efficiency by remembering what number a user entered previously and then having that number filled out automatically the next time the user decides to make a call. We added a cookie that accomplishes this.

Schedule a call

The cookie mentioned in the previous section was also implemented on this screen.

Record a voicemail

Because the voicemail recording widget as flash based, it loaded slightly after the rest of the page leaving the user guessing about what to do for a small but still noticeable period of time. We added a loading symbol to account for this. Furthermore, the heuristic evaluation mentioned that users could submit without recording first, so we fixed that as well.

View scheduled calls

This page would not exist without the valuable feedback we got from the heuristic evaluations. Previously users would not be able to see what calls they had and instead had to cancel them from memory, but this page provides much more transparency so that the user is much more in touch with the actual model.

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

The iterative design process was useful, because it allowed us to make changes rapidly and then get feedback to double check that we had actually made an improvement with that change. If we were to do this again, we would probably investigate which technologies to use more carefully. For all of us this was our first time using css, javascript, or php, and while we got the work done, we had to spend more time learning the technology than we would have liked. However, now that we know the technology better, it would be useful to run more high fidelity tests, because we believe the feedback from testing phases that actually involved a computer (heuristic evaluation and final user testing) to be the most valuable and actionable. For example, even though our paper prototype had radio buttons on the filter tab, none of our test subjects commented on them, and this was likely due to the low fidelity of paper. Again, web prototyping is so quick, that we think it might have been more useful to test a wire-frame prototype a little earlier on.