Solving the Last-Mile Challenge:
Bird Scooters recently hatched all over Denver. While they are an enjoyable and altogether novel way to solve 'the last mile challenge' -- of getting from a public point of departure (a bus stop or train station) to one's home or workplace -- they are also rigidly designed to accommodate only one person in need of one scooter.
Our group was presented with a problem and an opportunity: if other transportation platforms such as Uber could create multi-user options and features, could the same be applied to Bird?
Design features for Bird Scooters that permits the ability to track down multiple units for group travel.
I worked in conjunction with three fellow UX Designers. We collaborated closely throughout the design process, and so I will do my best to communicate individual contributions and accomplishments.
The Discovery Phase
Since nobody on our team had ridden a Bird scooter, we decided to do a little contextual inquiry: we found a scooter, we moved through the onboarding process, and then we rode one through the Denver streets (all in the name of research...).
For first time riders, the onboarding process seemed to take an unusually long time. There were nine screens to move through, each detailing the different processes of a ride (payment, safety, parking, etc.). Eventually, we found ourselves scrolling quickly through important safety warnings, riding features, and user agreements.
We were also presented with the challenge of finding multiple scooters for the four of us: do we *each* track down a scooter, splitting up the group and deciding on a common meeting point? Could we rent one scooter, locate another, and ride two to a scooter? What would best expedite the quest?
After our first onboarding and riding experience, we decided to do a brain dump. We asked: because they were so new to town, what were the various challenges facing Bird, riders, and the City of Denver, and how might any of these intersect with our ability to create a group riding option?
It turns out the challenges were mighty. Problems were emerging from seemingly every sector (transportation safety regulations; city permits and public allowances; business sustainability; rider expectations; scooter charger rivalries; etc.).
We knew we had to get everything on a whiteboard in order to decide our angle of approach.
Because emerging patterns were still difficult to articulate, we decided to conduct user interviews.
In the interview stage that a clear problem emerged: users could not rely on Bird as a reliable mode of transportation.
User interviews revealed that nobody could rely on Bird as a dependable mode of transportation. In one user's words, "Scooters are a great way to get around town--if you're lucky enough to find one."
Another user lamented, "If I can depend on one being close by, and if I could plan of getting one when I need it, I would ride them much more often."
Another emerging pattern? Denver users lack scooter brand loyalty; they simply want whichever scooter is nearby.
At this point, we asked: Does the lack of brand loyalty mean that we move forward with a third-party app? Or is there a way to build Bird brand loyalty through a scooter reservation feature?
We knew we were at a crucial junction and that user personas would help us move forward. Synthesizing the information we had, we generated our personas, Mary and Jenny.
These personas became the anchor point in our design stage, especially as it concerned the guarantee of scooter findability. Scooters are locatable via Bird's native app; however, there is no way of reserving one.
This inability is clear when one analyzes the native Bird app. On the Home screen below, notice that, though many "Nearby Birds" are displayed, this is simply for the sake of location; the user must find the scooter and initiate a "Ride" before somebody else does.
Scooters can be
located but not
We designed a journey map to chart the flow of our persona, Jenny. It shows Jenny's pain points around her (in)ability to reserve a scooter.
Users said that it would be much more useful to them if they could locate a scooter, reserve it, and then walk to it with the assurance that it will be there upon their arrival. This reliability would translate into more ridership for Bird.
Reframing the Problem
Research revealed that users are hampered most by their inability to reserve a scooter to ride. This means that the problem of group ridership--the original concern of our project--is simply nested within this larger issue. It doesn't matter who is trying to find a scooter (individuals or groups); if there is no way to reserve a scooter when you need it, then it cannot be a reliable mode of transportation.
Matched with the need to build Bird brand loyalty, we came up with the following solutions:
Design a "Reserve" feature into Bird's existing ecosystem;
Incorporate the location of competitors into the "Find a Scooter" function via API technologies;
Clean up and speed up the onboarding and "End Your Ride" sequence.
The Design Vision
In a cut-throat world of competition and conflict, we wondered: what if one simple design feature could provide welfare, security, and peace of mind into one's daily transportation needs?
Keeping our personas in mind, who were both moving through a similar user flow, we started sketching and wireframing.
Zach designed the wireframes for this feature. For the first version, we provided the user the following benefits when reserving a scooter:
A five-minute window;
The option to cancel the reservation at any time at no cost to the user;
A ping reminder when the reservation has only one minute left. If the user still wants the scooter but will arrive later than expected, they will be charged as if they are riding the scooter ($0.15/minute).
User testing showed the need to clarify tasks, specifically as they are tied to payment: when, exactly, does a reservation start? When, exactly, is a user being charged?
We cleared up these questions through three rounds of iterations. We also added helpful but missing features that are already deployed by Bird's competitors: scooter battery life and range.
"See All Scooters"
Because user research revealed no scooter brand loyalty, we wondered whether it would serve Bird to incorporate its competitors' scooter locations through API technology. This would allow the user to see all scooters located nearby, not just Birds. If the user wanted a Lime scooter, the Bird app would point the user to Lime's native app.
We reasoned this would be a power move for Bird: they would be the only company that locates all scooters around the user (a useful feature), and they would point users to their competitors in good faith.
After two testing sessions and good user feedback, Zach came up with a modal dialogue box that points to a floating action button. Black scooters are Birds while gray scooters are competitors. Click on the latter and you get information and a redirection to that platform.
User research showed that Bird's onboarding process was too long and tended toward information overload. It overburdened the user with too many rider expectations and seemed only to add to the user's anxiety over engaging the scooter for the first time.
We wondered if we could somehow
1) Shorten the process and
2) Not overload the user with unnecessary information.
Erin took charge of this section and, through three iterations of user testing, did a wonderful job of transforming Bird's nine-screen onboarding process into five. Especially commendable was her ability to boil down confusion over where users are to supposed to ride scooters into one simple sentence (which research showed to be a particularly thorny pain point).
She handed her wireframes to Zach, who turned them into these beautiful mockups for Material.
Research also suggested user confusion over the ability to pause one's ride vs. ending it. I decided to clear up Bird's UI in these matters, especially as it concerned how a ride could be paused and whether the user was being charged during that pause. I designed the following hi-fi wireframes:
Based on testing feedback, I reconfigured the various data points in order to establish a more defined hierarchy. Also, while users enjoyed the quippy "pause" language and the clarification it brought, they wanted the pause/end information on the same screen:
In the end, we integrated these options into Bird's user flows and Material design conventions. Both the "End" and "Pause" options are opened in the floating action button. Once selected, users can choose which option they want (and are met with respective floating dialogue boxes):
Parking & Ride Rating
Following user research, which suggested ambiguity around the parking and ride-rating process, and following our design choice to cut parking from onboarding and paste it to offloading, we put Erin's parking instruction screen at the end of the process (mockup shown here).
Concerning Rating & Offboarding and our attempt to expedite the process, our teammate, Amie, came up with these wireframes, which attempt to communicate 1) crucial ride statistics and 2) a feedback mechanism for any issues/problems/comments:
For our final mockups, we tweaked a few things and combined the above two screens into one:
This demo follows the user flow of Mary, our novice persona. It includes all onboarding, reserving, riding, parking, and offloading.
Clean up design elements.
Possibly pitch this project to Bird Scooters.
Tinker with seamless integration of API data.