...
Our initial writeup for GR1 did not fully cover the details of the user population and listed only superficial details. We revisited it later and worked to resolve those issues. Evaluating the user population turned out to be quite important, to learn more about what they expect from our interface and how to fulfill their needs. The next time we go through the user interface design process, we plan to spend more time talking with users and understanding what they are looking for.Also, our initial writeup did not clearly focus on the difference did not distinguish between essential and non-essential tasks (this has since been fixed). In the future, we plan to spend more time looking at the frequency and necessity of tasks to better understand what components to focus on. At this point, we picked three valid . 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 to read later (which took the form of tagging items to make them searchable). Reading and filtering remained essential tasks in their current form throughout the whole project. Saving items for later was fleshed out into a tagging interface for GR2-4, and augmented with a save button in GR5.
GR2 - Designs
We were fairly pleased with how our storyboard turned out. It was fairly close to the actions most users would do with the final version of our interface.
. The reading and filtering tasks remained consistent throughout Hubbub's entire design and implementation process. 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 of Hubbub's design, and helped us to frame Hubbub's design goals in a way that made Hubbub considerably more useful for our target user population.
GR2 - Designs
Initially, we each had very different ideas for how we wanted Hubbub to look and behave. 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 implementOur designs turned out relatively well and provided a clear way forward when prototyping. We didn't consider the real-estate issue that come up when designing for mobile, but for the most part the GR2 sketches translated into a useful prototype. Looking back, considering the screen space issue might have made the results of GR2 even more useful.
GR3 - Paper Prototyping
The paper prototyping sessions were quite satisfying and getting feedback feedback we received from users about our interfaces after they played out an interaction interacting with our paper prototype was very helpful. We made several amendments to improve the interface at a time when doing so was cheap, and we were able to make several major design improvements on the fly. For example, we originally had switched from a tabbed interface to switch between the news feed and the filter form, but users found it counterintuitive so we dropped it.a main page with navigation buttons because users found the tabs counter-intuitive.
We At this point, we decided to focus on four sources of information for the prototype (Gmail, Twitter, Facebook, and Imgur), and this choice which lasted for the rest of the project. Drawing the interface on a large sheet of paper hid obscured the real estate space issue that comes with designing on phones. When the interface was shrunk to became phone size in GR4, it was more cluttered and fat-finger problems emerged. Even if users used their whole hand to "click" on elements, their input device was at a higher resolution than it is on phone screens. We don't think we should have drawn the paper prototype on a phone-sized sheet of paper - it would still not be that close to the computer interface, and Prof. Miller explained in lecture that building and amending a smaller-sized prototype is significantly less efficient (so a phone-sized sheet would have compromised our ability to respond to feedback from paper prototype testing)considerably harder to navigate. In retrospect, it would have been more beneficial to have users interact with a much smaller version of our paper prototype.
GR4 - Computer Prototyping
...