...
From the iterative process, we learned many things about computer user interface design, and looking back at our development process, there doesn't seem like there's any other logical way to go about it. It's important to establish some the start what we wanted our website to do, so that we can optimize the interface for it (GR1). If we hadn't done that, we would be faced with problems of clutter and inconsistency that plagues many websites today. The next step of the iterative process taught us that each developer has a different sense of what's important to an UI (GR2). .
-If we could do it again, what would we do differently?
During this process, we were able to come together and agree on the important aspects of the design that needs to be focused on.
The next phases of the iterative design process involves prototyping (GR3 and GR4). Although we learned about how paper and digital prototypes stress different design aspect in lecture, we didn't fully realize it until we prototyped. During paper prototyping, we ran into problems of communicating animation and state changes due to the static nature of paper. However we learned a lot about the importance of simple layout and information display during this process. During computer prototyping, we learned lessons in implementation. Some of the things we took for granted in design are not so easy to implement on a computer. Computer prototyping made us think about the practicality of interface design. Things like compatibility and graphic rendering were brought to our attention through this process.
Ultimately all the earlier steps of the iterative process leads up to the final implementation of our design. Without feedback from experts (6.813 staff) and users, it's incredibly easy to miss usability flaws that seem trivial to the developers. There were also definitely features and affordances (or lack thereof) that we as developers skipped out of laziness that were later revealed to be important to the overall usability of our interface. Each step of the iterative process is like a reality check for us. It helps to guide us in the right path of design and implementation and reveals what needs to be done.
If we were to redo the project, there would be a few things we could improve on. We could have spent more time in the earlier design phases of the project. We borrowed a lot of usability tools and design techniques were preexisting website. This is a good thing because users are immediately familiar with some parts of our UI, but these choices are not optimized for our tasks and is not too impressive or revolutionary. We also could have put more thought into the organization of data. Currently we are confined by the categories of Justin.tv, our source of streams, which these categories can be limiting and inefficient in some use cases. Lastly, our stream player is the generic embed player from Justin.tv, so it is designed for Justin.tv's websites. Because of this, its usability features do not completely complement StreamBrowser, and we should have thought about how to better integrate it into our interface-Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.