...

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 GRXGR3; 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 their phone, instead of using the prototypes we built 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 our bConversation 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, in fact, 

Reflections

...

Return to Laundry Quandary homepage.