One of the first big initiatives at Scoot was the strategic decision to focus on our heaviest users, field technicians fixing scooters on the streets. A normal shift would consist of finding and repairing electric motor scooters, eBikes, and electric kick scooters in the field. This case study explores how I led the user experience for this feature, while working with our junior designer to prototype and test it.
One of the main set of actions within our mobile fleet app was locating and turning on vehicles, and performing various checks to them throughout their shift. We started by mapping out the "Vehicle Actions" to better understand how they were accompishing these goals.
We wanted to collect different approaches for solving complex actions on a mobile device. Working with my junior designer, we looked at variety of apps. I find this a great way to get some inspiration before sketching out ideas.
Our first iterations tried to solve too many scenarios at once. We quickly learned that we need a better system to launch the vehicle actions regardlesss of the entry point.
We were curious how a stacked button list, launched from the top right of each vehicle page, would perform. Some of our bigger assumptions were around the discoverability of the vehicle actions within that list.
General feedback on iteration 1 was that it worked - but we wanted to push it a little further. Prototype 2 took the "floating action button" approach that google had popularized. We created this prototype and tested it with some of our users.
Despite being an elegant solution, zero users were able to find them. We collected our learnings on a trello board and shared the learnings with our team. It was overwhelmingly clear that the floating action button was not appropriate and we needed to continue iterating.
Many, many iterations later I put together this prototype that we tested. I moved my junior designer onto another project for discovering ad-hoc tasks, so we also tested that in this version. Were also iterating on our validation process so we collected our learnings in a rainbow spreadsheet style this time, instead of trello.
Overall we had a very successful set of iterations that led to a more accessible, user friendly, set of actions that field technicians use constantly.
After completing development and shipping in Scoot's 3 cities, we started tracking some metrics via our mobile analytics platform Amplitude. We wanted to see a 50% increase in user adoption for the fleet app (away from the existing tool). We also wanted to track the number of rides that were greater than 12 hours, or "forgotten and held" each month. Our hypothesis was that the better visual system to see which vehicle is "reserved" for work would reduce that, and increase the number of available vehicles for public use.
Overall it was a huge success, and we learned a lot about how our users interact with vehicles in the field, while building and sharing empathy with all our fleet management stakeholders. Sweet!