Design

Throughout our design, our team tried to maintain as much simplicity as possible.  Following this design decision, the implementation of our laundry app consists of an all-in-one home screen (see screenshot 1).  This screen presents the following information to he user:

1. A list of the available washers and dryers in the user's laundromat area.  This list of machines represents each machine as an expandable accordion-style box; once expanded, more details about that machine can be seen.
2. How much time is remaining for a machine that the user has put clothes in and started (see screenshot 2).
3. A specific message should no washers/dryers be available at that particular time.  This functionality also allows the user to be notified when a machine becomes available.
4. The ability to leave notes on machines, read notes from previous users on machines, and indicate that you are about to use a machine.

One important design decision that we incorporated into our document was the removal of the "finished" machine state.  Previously, we had wanted to let the user know if there was some other user's clothes sitting in the washer/dryer that needed to be moved before that user could use the machine, but users found our implementation of this state confusing.  After much deliberation, we decided that the cons outweighed the pros of keeping this state, so we removed it.

In our heuristic evaluations, multiple evaluators were confused with what the checkboxes associated with each machine actually controlled.  To address this, we changed the text label next to the checkbox from "Notify me when this machine has finished" to "I've loaded this machine".  We feel that this message makes the checkboxes' functionality much more apparent (see screenshot 3 for example of this).

For our conversation functionality, we decided to include a header at the top providing some very basic information to the user.  This information includes that the user is chatting with a previous user of the same machine and the name of the machine the conversation is centered around (see screenshot 5).

Overall, our design did not drastically change from paper prototyping to heuristic evaluation to final user testing.  We feel this is because we came up with a solid original design, which considered many problems that could have arisen with alternative designs.

Screenshot 1: The LaundryQuandary homescreen.

Screenshot 2: Machines running with progressbar.

Screenshot 3: Available machines options.

Screenshot 4: A message left by a previous user.

Screenshot 5: A conversation held between the current and previous users.

Implementation

There are three main components to the implementation of our design:

1. The back end allows us to update and receive information about the current states of all the machines in the laundry room. It keeps track of things like the machine’s identity (washer vs. dryer), its name, its availability, minutes remaining until finished, and any notifications associated with it).
2. The xml layouts.  Besides the home page layout, our xml layouts include the individual displays for available machines, progress bar displays for any machines that the user is currently running, as well as the display that is used when no washers or dryers are available. These are inflated and added to the main view according to the state of the laundry facility. We have additional xml layouts for leaving notes and reading notes/conversations between users.
3. The main java code, which dynamically updates the interface by finding the current states of all machines in the laundry room from the back end, and inflating the appropriate xml layouts. This code is also responsible for changing the interface and the back end when the user interacts with the application.

There were several important implementation decisions we made. Firstly, we decided not to use a server in order to store user information and allow them to message each other with laundry instructions. Instead, we implemented as though we were only concerned with a single user. This user could interact with other hypothetical users, but the user would simply receive canned responses. We made this decision because we thought dealing with a server is outside the necessary scope of this class, and we wanted to focus more on the GUI.

In addition, we decided not to create an automatically updating laundry facility in our back end. Instead, we simply demonstrated our application with a set of static machines that we could add or remove. Unfortunately, this meant that our users could not receive updating time estimates for laundry machines. However, for the purposes of the GUI demonstration, we didn’t think this was too much of a hindrance.

Overall, we did not come across any insurmountable implementation problems that affected our final product. We managed to produce a GUI that was very much as we envisioned it.

Evaluation via User Testing

Choice of Users

We chose our four Testers from two main groups, one group being laundry room users at the fraternity two of us live at, and one group being laundry room users from Simmons Hall. We picked users from people that we know, but this should not significantly impact the user set selected. We also made the decision to use only people who already had compatible Android phones. We felt that this decision would ensure test results reflecting our design's internal consistency with the Android platform. If we had been designing for iPhone as well, then we would include iPhone users, but currently our service only has a prototype out for Android users. Our user set should consist of people already owning a compatible smartphone (since one would not buy a smartphone just to help with laundry in communal living places) - thus we chose a user set from known friends who are Android users. 

Representativeness of User Set

The users we chose are almost representative of our target population. Both genders and several different races are represented. All the users are in the age range of 18-22, but this makes sense because our target user population is college students in communal living situations who have Android phones. The way in which they are not representative is that all of them are from MIT, which might have specific laundry procedure habits as a school. It would have been more difficult to get users from other schools on a short schedule, but we would do this if we were to take the project forward at other schools. 

Briefings and Tasks

Our task briefings were pretty similar to our briefings from GR3; we had users operate the same tasks, with one additional task. This task tried to be very creative and explore whether a user would think a laundry machine was claimed, and we had one outside person help with this task by coming into the laundry room and taking the machine that was being claimed. This attempt did not give us satisfactory results, as we show in the next section. We also asked users to explore the application and point out bugs or other sources of questions. One crucial difference between this testing cycle and GR3 (the paper prototypes) is that we installed our prototype application on each user's phone; this is similar to our GR4 (computer prototype) but with user testing instead of heuristic evaluation. The other difference was that for the final task, we used an actual laundry room and tried to replicate a particular situation. We did not use the room for the other tasks, because they were simple enough that our prototype was enough to demonstrate task mastery. We did not use a demo as part of our briefing, because we felt that with our minimalist design principle, we did not need to brief users on how to use any of our features. The users mostly figured out how to do our tasks, and the hiccups in this process are described in the next section. 

Results of Experimental Additional Test

The results of our tests were a little better than the results of the previous iterations, though we didn't see anywhere near the size of usability gains between GR3 and GR4. Our experimental additional task was inconsistent with the rest of our testing procedures. The results it produced were markedly different for each tester (one did not begin the claiming process until she was sitting perched on the washer, preempting our planned "interruption"). If we had more time, we could redesign all of our tests to reflect use of an actual laundry room using the Wizard-of-Oz prototype update concept we discussed at the group meeting for GR5. This redesign would lead to consistent tests and a better feel for how our implementation would work. Other than our failed last test, our users did not have many problems with using our application.

Usability Problems

One problem that we encountered was that one button (a Leave Note instead of Conversation for machine 5 in the third screenshot above) was misclicked by a user. The user's response was to press the default Android back button (a hardware button) which brought the user back immediately. The problem is easily recovered, but can it be prevented? When exploring why this occurred, the most likely explanation seemed to be that our buttons could be too small - but in our minimalist design it would be difficult to increase the button size without modifying our carefully planned layout.  Since only one user had this problem, and since the problem is easy to recover, we choose to let it remain. The problem is cosmetic in nature. In our next iteration, we would perhaps consider alternate layouts, but the one we have is already quite good as demonstrated by our other tests.

Another problem was that one user thought the exclamation point we use to indicate the presence of a previous user note was an Android notification of some kind. In one test, a user explained that they clicked that machine first because they thought it was important to "respond to the notification". While this does not introduce a catastrophic problem (the system was still usable, the user would just do extra work if there was a machine with no note and they chose one with a note) we could consider trying to direct users to pick noteless machines or easier machines first. This problem is a problem with efficiency, and we termed it a minor problem. To solve it, we might change the nature of the exclamation point to be a question mark, or at least consider testing more different icon designs here. 

In general, our app mostly uses one home screen, with one popover. Due to the minimal nature of our design, users found it easy to understand and didn't encounter many problems at all. The two problems listed were the only problems of any significance that our users expressed. Some of the users were slightly surprised when "Message" changed to "Conversation" but they immediately understood and both of the ones who noticed smiled at this detail. It is this sort of reaction that we are targeting with such minor implementation reactive changes.

Reflections

Over the course of the iterative design process, we had one main lesson. We learned that a lot of the planned features that we thought would be useful would instead overwhelm the user with too much or too confusing information, and this led to user errors and dissatisfaction. If we were to restart this project, we would probably use a minimalist design paradigm from the very start of the project, even before the first paper prototype test. Instead of trying to provide the most useful product for an experienced user, we would tailor our product to prioritize learnability and simplicity first.

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.