COGS 120: HUMAN-COMPUTER INTERACTION DESIGN
Where To Go
The Task
WHAT WE WERE TRYING TO DO
The Task
Our goal was to design an application that "enhanced" recreation on campus by improving the navigation experience. We observed that navigating your way through campus and finding different buildings and rooms could be easy, but it often required users to visit several websites or use multiple apps to get the information you need. Our team of three decided to create an application that enhanced recreation for UCSD students by designing an app that made navigating the large, complicated campus easier. Our app, Where To Go, helps the user find all the different rooms on the school campus, and not just the buildings.
Problem Definition
Through interviews with UCSD students, we found that students of all different years and experiences with the campus had trouble navigating it when they needed to find a new place. Students used a variety of methods to find specific places, such as Google Maps, UCSD Maps, and asking strangers for directions. What we found was that existing options lacked the ability to guide students to rooms, they could only give directions to buildings. What we set out to do was help students find all the nooks on campus that are usually hard to find.
One student that we interviewed got directions to her classrooms by entering the location in her calendar to Google Maps.
Prototyping
STORYBOARDING
The idea that we decided on was to create a navigation application that allowed the target users, UCSD students and faculty, to find all the different rooms around campus in one easy-to-use interface. The first thing we did to begin designing was create three storyboards to show how we wanted our app to be used, and what we wanted it to accomplish. This included allowing users to search by classrooms, specific buildings, or types of rooms like study and bathrooms.
This storyboard showed a student struggling to find his classroom before using our app and finding it quickly.
RAPID PROTOTYPING
Next, we made rapid prototypes, drawing out two different potential interface flows with whiteboard markers. Our first design included a search bar and icons on the main screen with options that the user could click to make the process of finding rooms easier. The second design got rid of the search bar all together and only included a drop down menu where users could search for rooms in different buildings.
VERSION 1
VERSION 2
First Iteration
In order to narrow down our ideas before beginning implementation, we conducted a heuristic evaluation comparing our two storyboards. That evaluation can be found here. What we learned from those findings was that we needed to focus in on the purpose of our app. Our goal was to fix the gaps that existed in the popular navigation apps by helping users find all the rooms that they use around campus. We found that our first storyboard (Version A) was more intuitive because the prominent search bar made it look like current popular navigation apps. However it didn't give step-by-step directions to the user and it didn't highlight all the potential ways to use the application, so the features that made the app unique weren't as noticeable. On the other hand, the second storyboard (Version B) was too simple, and didn't allow users to find rooms that didn't have numbers, like bathrooms, or make more detailed searches. We reflected on the benefits and downfalls of both designs and made a list of potential changes we wanted to make to the app. Our last step before beginning coding was making a video prototype and wireframes so that we had a clear vision going into implementation.
​
WIREFRAMES
Implementation
THE STAGES OF DEVELOPMENT
We began implementing our design by creating a website prototype. First, using HTML, we made a skeleton of all the necessary screens we would be including, as well as all the navigation links that we would need. After making sure we didn't have any dead-ends, we moved on to adding Javascript. In order to create a "wizard-of-oz" backend, we used the MapWize API, which allowed us to program directions directly onto floor plan PDFs. This API gave us the ability to create the most unique aspect of our application: directions within buildings, not just between buildings.
The first big change that we made was removing the search bar from the Index screen, and putting it as a button like the other options. We did this to keep the focus on the unique features of the app, instead of the typical search capabilities.
Our goal for the app was to make it easier to find rooms on campus, and these rooms often don't have addresses. So in each category (restrooms, classrooms, and other specialty rooms) we created options to help users find where they need to go easier.
After making a search, the user would be presented with a list of the places that match their search, as well as a distance indicating how far each option is from their current location.
The Mapwize API allowed us to give the user directions inside the building by using floor plans as the map. This also gives the user the ability to explore buildings by floors, and continue directions once they reach a different floor by pressing the elevator icon on the map.
Testing & Iteration
WHAT WE CHANGED
The next step after we completed implementation was testing, which we did over two phases. First, we conducted usability testing, where we instructed users to complete 4 easy tasks using our application, and observed their actions. Afterwards, we interviewed them to get their feedback about what features were most intuitive and what was confusing. What we observed was that users could navigate to the bathroom and classroom pages easily, but some got confused when we asked them to search for an address because they didn't notice the "Search" button. Using this feedback, we created an alternate index screen that we used for A/B testing. The new screen included a search bar, and more instructions about what the user could search for. Underneath the search bar, we included links for users to pick a category if they preferred that over searching. The A/B testing was similar to the usability testing, but we collected both qualitative and quantitative data. We found that while version 1 highlighted the unique features of the app more, and made it clearer what the capabilities were. Version 2 was more confusing for users because the search bar was too similar to traditional navigation apps, and made it less clear what the differentiating capabilities were.
VERSION 1
VERSION 2
VS
These graphs show the data we collected during our A/B Testing. The left one shows how long it took (in seconds) for users to find a gender-neutral bathroom and the right is how long it took them to find Geisel Library. In both graphs, the blue line is using Version1 and the orange line is using Version 2. We found that often times, the quicker rates using Version 2 can be attributed to the user being more comfortable with the task itself having done the same one with Version 1 first.
Wrapping Up
THE FINAL PRODUCT
After evaluating the results of our tests, we decided to stick with the original design that included 4 buttons on the main screen without any search bar because we felt that it highlighted the important and unique features of our application best. Our last step was adding CSS and making a demo video to show off our application... and we were done!
DEMO VIDEO