Sitemap

Once we had settled on the idea of creating an interface to enhance the public restroom experience, we wanted to further organize the architecture of the features we planned to implement. Part of our vision for the public restroom, as we kept safety and prevention of illegal activity in mind, involved stand-alone, single bathrooms, clustered together but with doors leading to the outside, instead of the standard women’s/men’s bathroom with several stalls inside. Thus, we decided to create two interfaces. One acts as a request system for the cluster of bathrooms, and has no defining features other than its main purpose and providing a door code for the user to insert to a bathroom’s door.

The other interface is more intricate, with several different accessibility features, including height adjustments, a phone, and public resources. With this conglomeration of different features we intended to implement, we had to organize our sitemap as horizontally as possible so that a user would not have to dig too deep to find something they were looking for. As a result, our bathroom interface has five main features, with several different options within some of the features. We believed that this was the best way to navigate our system and offer simplicity to the user.

With a sitemap to guide us, we now had a general idea of how we wanted to assist the user in navigating our system. However, these user flows were just our best guesses. We needed to test our ideas with real humans, and we needed to do it “on the cheap.” We generated low-fidelity paper prototypes in order to test our solution, and conducted several rounds of testing.