We've read it in every written feature regarding NYU, it has a campus that merges with the surrounding city. While that can be an amazing immersive experience, it also creates a navigation problem for the bulk of its student population. Though we have Google maps to help us figure out where our next class is, finding a printer when we're stranded in the middle of Washington Square is a whole 'nother challenge. In comes PrintStatus.
Developed by the Student Technology Innovation Team (STIT) at NYU, PrintStatus lets students view real time availability of printers across campus, including the location of the printer within buildings and the type (B/W v. Color) of printer. The skeleton of the system is relatively linear, with the app broken down into 4 key parts: map, search, printer list, and printer detail.
An early beta of the app had been live for a couple semesters, but the team noticed that not many students use the service. STIT decided that they wanted to redesign the system, figure out what might have gone wrong with the first iteration and roll out a 2.0 with an improved interface and experience.
I was the lead designer in this project, and I worked with one other visual designer and two developers.
To begin, we consulted past user research that was done on PrintStatus, as well as went through a heuristic evaluation of the current system. We wanted to understand why certain choices were made and pain points that we can tackle for the new system.
Our findings could be summarized as the following:
- The current system revolved around the map littered with icons of different shades of purple. The shades of purple to indicate status we found as a particularly complex solution to a simple problem.
- Interface displays a lot of different icons (some are links while others are not, but they are distinguished poorly), most of them nonstandard and makes the navigation process difficult.
- Terminology and copy used across the system lack clarity, especially the filter system, which might be a vital part of a student's search.
- Printer detail page is very repetitive and lengthy, providing information or visual elements that are not necessary.
- Lack of a proper guide/help make it hard for students to seek help if they do need it.
We also looked into different location/place finding applications in their design treatment of maps and lists. Yelp, Google Maps and Facebook Nearby being the main "competitors" we researched. Combining our in office evaluation, comparative analysis and user data, we mocked up a proposed wireframe for the new design.
High Fidelity Prototype
Since the final product will exist as a web app rather than a native app, we designers sat down in a meeting to discuss with the developers in the possibility of certain elements and interactions. The system needed to be feasible coding wise, but also responsive for the wide range of devices students may be accessing the app from. I was very relieved that we did this relatively early in the process, as it saved the designers' time and developers' effort. This also exposed both sides to the entire cycle of design from wireframes to deployment, it was a super valuable experience on both ends!
1) Home/Printer List 2) Building Select 3) Search 4) Building Detail
We also conducted usability tests with students of NYU, our two main goals being:
- How long does it take the average user to find what they need/complete their task?
- What is their first approach? Search bar or map?
- Areas of confusion where users might get stuck
- Unfamiliar or unclear terminology
From our interviews, we found a lot of overlapping observations:
- Directly searching on the web map is the most likely start point.
- User interaction often will end before the building details page; just the map page with available printers will most times suffice.
- The terminology "Online Only" and "Commuter" that we used in our system can be interpreted in a lot of different ways.
- A newer feature we decided to include in the app wasn't explained or introduced in any way.
- Help/Guide, while not really clicked on by the three students, presented a list of features rather than actual instructions on how to use the app.
From the feedback we had gotten, we revised the interactions and refined the design elements for a more cohesive overall design.
Our team is currently in the final development stages of the app. The developers are working on organizing the backend and print data to support the way we want to have printer information displayed in the frontend.
Me and the other designer are continuously reviewing the developers' work but also tackling existing design challenges and new ones that our product owner have brought up.
We are hoping to launch the app as soon as we can and ship out iterations and changes once it's live and we see how students are interacting with it.