...
Our initial writeup for GR1 did not fully cover the details of the user population, and did not distinguish between essential and non-essential tasks. After extensive feedback from Sacha, we revisited our task analysis and worked to resolve those issues, ultimately creating a great road map for Hubbub's design and implementation. We created three essential tasks: reading, filtering, and managing/saving items. The reading and filtering tasks remained consistent throughout Hubbub's entire design and implementation process. Managing Similarly, the subtask of managing items translated into a tagging interface with minor design changes across milestones. In contrast, the process for saving items underwent extensive redesign multiple times from GR2 to GR5. Evaluating our user population turned out to be a very important part our analysis, and helped us frame Hubbub's design goals in a way that made Hubbub considerably more useful for our target user population. If we didn't act on Sacha's feedback, we would've run the risk of completely missing the whole point of the UID course, focusing more on the low-level details of Hubbub (like algorithms and performance) than what users would actually want out of it.
GR2 - Designs
Initially, we each had very different ideas for how we wanted Hubbub to look and behave, which translated into a lot of different interface sketches for GR2. However, by the end of GR2 we had a pretty clear idea for Hubbub's design, and some of our story boards ended up being fairly close to the behavior of Hubbub's final interface. We explored different ways to filter feed information, as well as alternative approaches for presenting feed items to the user. Initially, we wanted to restrict the length of the feed based on the amount of free time the user had to devote to interacting with the feed. However, we abandoned this idea in favor of a more intuitive filtering interface. This made Hubbub's filtering implementation simpler for GR5, since the filtering algorithms were easier to implement. In addition, we decided to provide a scrollable list of feed items. We decided that this was much more efficient than our other interfaces, which would require the user to swipe or tap a button every time they want to see a new feed item. The feed list ended up being very intuitive for our users, and none of them suggested changing this part of the interface's design.
GR3 - Paper Prototyping
The feedback we received from users interacting with our paper prototype was very helpful, and we were able to make several major design improvements on the fly. For example, we switched from a tabbed interface to a main page with navigation buttons because users found the tabs counter-intuitive. Doing this for our computer prototype would've been a lot harder, since we would have had to throw away the work involved in creating the tabs in the first place.
We decided to focus on four sources of information for the prototype (Gmail, Twitter, Facebook, and Imgur), which lasted for the rest of the project. Drawing We actually had a long debate about whether to draw a larger or smaller paper prototype, and eventually decided to draw the interface bigger (which was the advice given by lecture and the TA's). Unfortunately, drawing the interface on a large sheet of paper obscured the a space issue that comes with designing on phoneswe had later on in terms of fitting buttons on the screen. When the interface became phone size in GR4, it was more cluttered and considerably harder to navigate. However, there was one user that told us she felt our interface seemed cluttered during paper prototyping. Since she was the only user that thought our interface was cluttered, we decided not to change it at the time. In retrospect, it would have been more beneficial for us to have users interact with a much smaller version of our paper prototype. We could have caught our space issue much earlier.
GR4 - Computer Prototyping
...