Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

...

  • Time selection widget unnatural (moderate)
    • Remove the widget and just specify a format for user to type time
  • The user asked about the politician's office hours (minor)
    • We could gray out the unavailable hours in the date and time selection widgets
  • The "View Scheduled Calls" link in the menu bar was not immediately visible (minor)
    • Provide visual distinctions for buttons (colored boxes, perhaps)
  • The now button on the time entry widget confused the user because it did not affect the date, only time (minor)
    • Have the now button apply to dates too
  • Possible safety issue for accidentally canceling scheduled calls (minor)
    • Add a confirmation dialogue

User 3

  • The "View Scheduled Calls" link in the menu bar was not immediately visible (minor)
    • Perhaps draw attention to the button temporarily after a call is scheduled for the first time
  • From the Scheduled Calls page, there is no way to return to the results -- home and New Search do the same thing (minor)
    • Perhaps make the home button "Expect Us" return to the results page, or add a "Most Recent Search" button in the menu bar
  • It was not obvious to the user when the recording widget started recording, so they did not know when to speak (moderate)
    • Add some sort of feedback mechanism, such as the number of seconds the widget has been recording.
  • The security hole presented by the lack of verification of phone numbers made this user hesitate to use the site at all (minor)
    • Text the user a verification code that they must enter before using that number for calling.

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 cssCSS, javascript, or phpPHP, 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 Web prototyping is so quick, that we think it might have been more useful to test a wire-frame prototype a little earlier on.