Paper Prototype
From the sitemap, discussed in the previous section, we generated a paper prototype in order to test the our concept with potential users. Creating the sitemap helped us imagine how we might organize all the information visually, so we took a first attempt at prototyping based very closely on how the sitemap was designed.
Paper prototypes are a quick (and cheap!) way to try new solutions with users and solicit valuable feedback to inform the next iteration of prototyping before generating the engineering spec and handing the project over to developers. This way, developers do not waste time and resources building a solution that, in the end, might not work because it was never tested with users. We conducted three rounds of testing with at least two users per round, making changes to the prototype after each round, and sometimes in the middle of a round. Each round of testing is summarized below. By the end of testing, our most up-to-date version of the paper prototype very closely resembled what would become our wireframe.
Testing: Round 1
We interviewed our first user, a fourth year, male, HCDE student, in the Husky Union
Building (HUB) on the UW campus. He was initially confused about the function of the bathroom status bars on the main interface. After telling him that the bar helps to inform people about levels of supplies in the bathroom, the user pointed out it might be hard to accurately measure these levels in a way that would be meaningful for other users. For the individual bathroom interface, the user suggested changing our phrasing by using action verbs on labels for clearer communication. For example, we changed “Sink Height Adjustment” into “Adjust Sink Height”. We deleted the “Light Adjustment” button because the user thought it was an unnecessary function.
The user gave us the suggestion of adding a shower option in the “Accessibility”category since homeless people usually do not have consistent access to it. A different user, a third year female who was tabling outside the HUB wanted to have an emergency button within the phone feature so she could call 911 directly if needed. The “Information” button on the individual bathroom interface was confusing to the user. The word “Information”, in the context of this interface, is too vague, and the icon we chose to represent it is also too generic. It does not serve the purpose of informing the user about other useful apps they can use such as Google Maps and OneBusAway. The user also showed concerns about the 20 minute limit use of the bathroom. We agreed it seemed too strict, so we decided to reduce the time limit to 15 minutes and charge people incremental fees if they needed to exceed the 15 minute limit.
Testing: Round 2
During Round 2, we tested with slightly higher fidelity paper prototypes, compiled withAdobe Illustrator and printed out on paper, so that testing participants could interpret text and glyphs more easily.
We tried to add an indication that certain restrooms were unavailable by “dimming” out the occupied bathroom’s corresponding tile; however, participants did not respond well to the dimming, and thought it was a printing mistake; thus, we added the text “Available” in green to the corresponding tiles of available bathrooms. After testing the above solution, we realized that we could actually remove the “Available” text from the tiles completely, and only display the “Tap to Request” text on tiles that mapped to available bathrooms. Similarly, our customer service icon and tab did not convey well to several participants. Many were confused by what it meant, whether they could interact with it, and whether or not it meant they got to talk to a person in real time. Participants during this round of testing also noticed that there were two places to change the text size inside of the “Accessibility” page and on the individual bathroom interfaces; thus to reduce redundancy, we replaced the text size adjustment slider in “Accessibility” with a button that controls the height of a diaper changing table.
Many participants were also confused by the “Information” page. Users voiced concerns about what they expected to be on the “Information” page and what was actually there (a OneBusAway map widget, and a Google Map widget).
Although many participants could not narrow down exactly what they thought should be on the “Information” page, a majority of participants expressed some sort of disappointment once arriving at the “Information” page, which caused us to reconsider what should actually occupy that page, and whether we should even call it “Information.” Finally, the participants were a little confused with the phone widget. Many participants actually complained about being able to make nonemergency calls because of misuse concerns. Further, participants found the emergency 911 button too large and easy to select by mistake.
Testing: Round 3
After making further edits, we took the printed prototype for another round of testing with
more UW students, both female undergraduates in a home setting. In terms of user flow, both users were able to navigate through both interfaces with ease, but would have occasional clarifying questions about a feature, or suggestions on how to improve our layout. The customer service button on the main interface was still confusing to one; she wasn’t sure if it was clickable due to its small size in comparison to the rest of the interface, and the other was unclear about the icon’s meaning. Under the “Information” category, which we still need to rename, the second user suggested that the One Bus Away API and Google Maps API should be the same size, and expressed confusion as to why the exit button was so unusually large. Upon further discussion, we realized that there should not even be an exit button in the upper corner at all, because in real life implementation, these different pages are not new windows that are going to overlay a static homepage; but instead, the homepage is dynamic and changing.
We decided to update the next version with “Back” buttons instead. In the “Supplies/Services” category, the first user asked whether they would be able to obtain an unlimited number of feminine hygiene products, condoms, etc, because there was no indicator that the interface limits how many products an individual can obtain, so that is something we are going to implement in the next version. The second user also expressed concern that the “Call 911” button on the phone interface was too large and prone to accidental calls, something that was also brought up in Round 2 of testing but has not been corrected yet. We will also improve upon the “Information” page, as it is vague and incomplete.