Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • CATASTROPHIC problem:  Instructors have no idea what the red E and the blue A mean unless they have seen the admin interface.
  • MAJOR problem:  Users are unclear what the button with the white arrow (which reverts their cursor to a normal mouse cursor) does.
  • MAJOR problem:  Drawing a gray box around shifts that are pending add or pending delete does not convey the pending status to the user.
  • MINOR problem:  The majority of the users during user testing expected instructions.
  • MINOR problem:  It is easy to miss the "You must submit..." message at the top, since users' attentions tend to be drawn to the calendar.
  • MINOR problem:  On the admin interface, the users did not immediately notice the radio buttons used for accepting/rejecting requests.
  • MINOR problem:  The wording of the message on the popup box that appears if the user tries to navigate away from the calendar does not make it extremely clear that the user must press submit to save changes.
  • COSMETIC problem:  The color scheme (yellow/blue/black to represent day/evening/night) the buttons have when users schedule shifts is not extremely intuitive until the user has many shifts scheduled.

Reflection

Over the course of the iterative design process, we learned how important planning is.  While had we not been forced to follow an iterative design process, we likely would not have done nearly as much planning near the beginning of our interface, we found that implementing our final version was much easier because of all of the planning we had put in early on.  Furthermore, we learned the importance of user testing because there were things that we thought would be very intuitive, but that users sometimes couldn’t figure out.  Since we found out many of these problems early on in our paper prototype, we were able to fix them much more quickly than had we not found them until after our final implementation.  Finally, we learned the importance of testing on users that are representative of our user population.  We found that our paper-prototype testers (who were all MIT students) often wanted features that would make the application more efficient to use; however, when we tested on our actual user population (much less technically savvy), their primary concern was just being able to figure out the interface.  We did a good job of recognizing this and using our intuition to guide how we actually responded to user feedback; however, it would definitely be more ideal to use actual user feedback rather than having to rely on our intuition for how our testers differed from actual users.

...