Working with existing research on transit applications, our group of 3 multidisciplinary students were tasked with designing an iPhone interface for a "crowdsourced" transit data system. Pittsburgh's Port Authority Transit organization provided the information for stop locations and routes, and Google Maps was used for mapping, however no data was available for where buses are - only the (often inaccurate) scheduled arrival times were available. Thus, our application aimed to gather bus location data from riders to build more accurate estimates of arrivals at stops. To help incentivize users, a points system would be implemented wherein viewing data costs a small number of points, and contributing data generates a greater number of points.
Based on these requirements, our UI had to allow for users to find a stop, optionally input a destination stop, view the available buses based on their start and destination stops, tell the system when they got on the bus (so that the system would know which bus they were on, and begin GPS tracking), and finally to tell the system when they disembark from the bus (to end GPS tracking). Because this was developed for iPhones before background processes were enabled, we also had to attempt to encourage users to keep the application open so that GPS tracking could continue. As we were developing for the iPhone, we relied heavily on existing design patterns and interface guides for the phone to ensure it would be easy to use and require minimum orientation on the part of its users.
Our design focused on the use of favorites, since our target users were frequent bus riders. We emphasized providing minimum-click paths through the system using favorites, resulting in a flow that allows users to access bus listings in only two clicks (once on the Favorites tab, and then on a favorite). By incorporating paired favorites, which include both the start stop and destination stop, this same two-click approach works even when a destination is set. To minimize confusion when entering fullness, we chose to use the likely availability of seats to oncoming passengers as our metric. We felt this would be easier for users to gauge consistently than a more arbitrary numeric or otherwise generalized scale, and tried to further this ease of use by adding representative icons for enhanced recognition and easier clicking. Finally, we offered information about where the user is in their journey as well as a contribution map (showing how past contributions have been used by others) at the end of the UI flow to provide added value and attempt to encourage users to keep the app open and continue contributing tracking data.
design, ideation, usability testing