...
Given the chance to restart this project, we would be sure to focus only on user interface elements. We had some issues during the implementation stages (GR4 and GR5) that we eventually realized were not related to how our UI would work. It would have been less stressful and less time-consuming to not try to implement these "mostly system back-end" functions. They were not part of the interface back-end, but actual product's functions, and we realized that implementing them was unnecessary to testing and demonstration of our interface. At the same time, it was also important to consider the real-world implications of each of our design decisions. In this project, when we initially thought we could make it possible to "claim" a machine, we didn't realize that it was likely that we would have only partial adoption of our system. Such considerations would play a larger part in the initialization steps of other future projects.
Since this section is meant to be reflective and "meta," we can consider what we would do with other types of projects given this experience. With a project that is more difficult to simplify, after considering this type of project we believe we could implement some iterative learning steps with effective information scent and self-disclosure to enable users to build their way up to complex tasks. This principle is demonstrated in a small way in our choices for the text buttons in our app and how they change, but it can be generalized to any project that requires tasks of increasing difficulty.
Our design and prototyping process went very smoothly, for the most part. As our experimental test at the end of our last user testing phase demonstrated, we should be careful to keep even our testing process internally consistent. We made a try at doing a Wizard-of-Oz style prototype for one test, but having this test be different was confusing and was susceptible to real-world diversion. It is harder to nudge users in the right direction from just the Interface itself (without interaction from the observers and facilitators) if the user is interacting with a real-world environment. Our group would find it interesting to test a full Wizard-of-Oz prototype of this system to make the interactions with hardware easier to replicate without implementation; we might have replaced the testing cycle of this GR assignment with that if we were to redo this project.
In general, group consensus led toward certain decisions, and these decisions were not always in line with the test results we found after making the decisions. The design iteration process was very helpful in discarding our initial unfounded preconceptions of how our product would be used and how users would interact with it. We were lucky to be in a group where all members were very willing and eager to adapt our design to meet the usability challenges we discovered through the testing phases.
...
Return to Laundry Quandary homepage.