...
1.0 Login Page
The login screen is very standardprovides a brief description of the site's purpose.
1.1 Meals
The Meals page (formerly called the Meal Log) of our final implementation is not drastically different from the design used in earlier GR’s. It mimics the Google Calendar interface for good learnability, which was received positively by users in the heuristic evaluation and user testing stages. Unlike Google Calendar, meals (events in Google Calendar) are not centered around times of the day (3AM vs. 5PM), but rather by their meal type (breakfast vs. lunch). This makes the most sense for DailyDigest since we do not handle data about the time of day that meals were eaten at.
...
The transcripts from our user tests can be found here.
4. Reflection
We should have done more paper prototypes and earlier iterations before moving into the computer prototypes. We We learned a few important lessons from this class the hard way.
First: test cheaply and often. We would have benefited from making additional paper prototypes and doing more paper testing after receiving feedback for GR3, before making the computer prototype. Instead, we came up with several new ideas and just picked one. Our computer prototype ended up not being great, meaning losses on two fronts: wasting time on a pretty flawed implementation, and more importantly missing an opportunity for feedback on a design closer to our final one.
Second: Be risky and prolific on paper. We changed our designs later in the game because we discovered better ways of doing things. We would have saved a lot of sweat and blood had we done the discovering earlier, and creating many more designs in the first place would have helped. However, we also were getting better at critiquing and creating designs as the class went on, so our later iteration may have been a result.
Third: Not all users are the same. We could have focused more on learnability and separated beginner and advanced users, perhaps by having advanced options that the user can choose to display. We tried to accommodate both experienced users and beginners, sacrificing some learnability.
Overall, we learned that usability is harder than it looks. In the process of learning to design, we’ve also become more sensitive users.
We learned a few important lessons from this class the hard way.
First: test cheaply and often. We would have benefited from making additional paper prototypes and doing more paper testing after receiving feedback for GR3, before making the computer prototype. Instead, we came up with several new ideas and just picked one. Our computer prototype ended up not being great, meaning losses on two fronts: wasting time on a pretty flawed implementation, and more importantly missing , but simply picked one for the computer prototype instead of creating another paper test. Because of this, we created a computer prototype that was not as good as it could have been, and we missed an opportunity for feedback on a design more similar closer to our final one.
Second: Be risky and prolific on paper. We changed our designs later in the game because we discovered better ways of doing things. We would have saved a lot of sweat and blood had we done the discovering earlier, and creating many more designs in the first place would have helped. However, we also were getting better at critiquing and creating designs as the class went on, so our later iteration may have been a result.
Third: Not all users are the same. We could have focused more on learnability and separated beginner and advanced users, perhaps by having an “Advanced” page advanced options that the user can select to access the additional options. (If it’s good for everything, it’s good for nothing.) choose to display. We tried to accommodate both experienced users and beginners, and made it difficult to use for bothsacrificing some learnability.
Overall, we learned that usability is harder than it looks. In the process of learning to design, we’ve also become more sensitive users.