OneRide

The Opportunity

We started by talking about what we wanted the future of public transit to look like. Here in Portugal, the public transport infrastructure is quite robust but it lacked a consolidated digital interface. The information about the schedules, prices, routes, were fractured across various platforms and apps with varying levels of functionality and usability. Uber demonstrated that by leveraging technology, they successfully redefined the industry of private transportation. Could this be done with city metro and bus systems? With trams and trains and everything  else in between with public transportation?

We believed we could.

The Approach

An single app that consolidated all the various public transport options in the city was a good start. Google maps and Moovit provided us with some ideas. We wanted to go further though. What if the user could pay for a metro ride with his phone as and when he wanted to use it. How would that work? How would it integrate with the existing public transport infrastructure of a city?

We figured that using QR codes at a station could work as an accurate indicator of the user’s geolocation (GPS often fails at underground stations). Thus all the user has to do is to check in at the origin station, ride the metro/bus and check out at the destination station. Behind the scenes we would calculate the route taken and charge the user’s credit card accordingly.

The app was the ticket.

With this approach we started building a prototype to validate our ideas. Working with the various incumbent transport operators with proprietary pricing models very quickly proved to be an uphill challenge. We had our work cut out – and we got cracking.

Iteration 1

Primary user personas

We identified two distinct business cases – the regular commuters and the occasional travelers. For the regular commuters, we assumed that they were familiar with public transport and used it as their primary mobility service in the city. So it was safe to assume to regular commuters would most likely walk into a bus/metro station and check in, ride the vehicle, transfer vehicles if necessary and finally check out at the destination station before exiting. With this basis, I sketched and wireframed flows for the Unplanned Trip use case.

Early wireframes of Unplanned trip use case

Iteration 2

For the occasional travelers, our goal was to encourage them to adopt public transit systems more often. So like Google Maps, user’s could search and find routes for travel with public transport. Unlike Google Maps though, we provided users with trips with real time as opposed to using a scheduled timetable (perks of partnering with the mobility providers!). Additionally if a user has already provided us with his destination, we don’t need him to check out at his destination. This was the basis of the Planned Trip use case.

UX flow for planning trips.

Initially we imagined that OneRide would be used for a single trip at a time. Thus I organized the information architecture based on two distinct contexts – On a trip and Pre/Post Trip. However with Planned trips, we quickly realized that the user may have multiple planned trips, a current active trip and receipts of past trips at the same moment. The distinct modes of the app were blurring and our assumptions were eroded as we expanded the product scope.

I eventually reworked the information architecture to separate planning (Home) and traveling (My Trips). This led to a ovehaul of the entire app and I reviewed and reworked many flows in the app. My Trips was now the home of all upcoming trips, past  trips and the current active trip if it existed.

Iteration 3

Five months in, we brought on a visual designer to start working on OneRide. We encouraged him to create a brand and style guide for a modern urban mobilty app test it with my wireframes approved by all the stakeholders. I brought him upto speed on the product, guided his work and reviewed the visual style he was taking. While he worked to polish the visual, I continued working on the app with testing and new features.

The three types of trips – Upcoming, Active, Past

UX testing was not originally on the project timeline but with some deft planning, we squeezed in some technical testing. I had already conducted cognitive walkthroughs with colleagues on the design team to aid me over the months. Since Porto was the site for the product pilot, the lead engineer and I headed to Porto for a business trip and spent the day testing OneRide. We took a lot of buses and trains to see the app functioning in the real world. We learned more lessons and figured out more decisions in that one day than weeks of debating assumptions and opinions! We returned home and reworked the product’s pricing model, the validity model and redesigned many flows in the app. We now had a product that was finally coming alive as we headed to a 4th quarter launch date.

The App map with flows

Lessons

In retrospect, I think we made a few assumptions that blindly mimicked the functioning of the existing analog ticket. This was a clearly a missed opportunity. We had the opportunity to aggressively to rethink how public transport ticketing is done.  could For instance we could have discarded the entire Unplanned Trip use case by asking the user where he was going after the first check in. This would convert every trip into a planned trip, consequently eliminate the need for a check out, simplify our model for validity and pricing. I also think we spent a great deal of time debating and refining UX flows based on opinions than conducting usability tests. Sure there were time and budget constraints (when is that not the case?) but I now clearly understand need for testing when creating something new without having any clear points of ref/competitors.

Note: OneRide is a copyrighted digital product owned by Novabase SGPS, S.A. including all intellectual property. The above information is drawn from my experience working in the capacity of an employee at Novabse.pt