UX DESIGN
Home > UX > Dockless Bike Share App
Dockless Bike Share App
approach
If you live in a big/medium sized city, these days you cannot help but notice that they are bikes are over the place. Bike Share companies are ubiquitous. Offering everything from scooters, electric bikes, manual bikes, and everything in between, the aim to free us from our cars, get us some exercise, and lower our carbon footprint. Sounds like a great idea, right? Yes. But in the case of bike sharing, it's all in the execution.
The vast majority of the criticism lies in the bikes themselves. Everything from the quality and the maintenance of the bikes offered, the availability of the bikes, to the sad fact that we, as a species, cannot figure out how and where to leave them when we are done with them.
My aim in this project was to discover the pain points present in dockless bike share apps today and provide solutions to give users a better experience.
research
Most complaints for bike shares fall in the following categories:
-
Bikes piling up/blocking access
-
Thieves and vandals
-
Bikes not well maintained
-
Bike availability lacking
User reviews of bike share apps yielded the following complaints:
-
Have to go through too many screens before you can ride
-
Need for permissions not well described
-
Nut using native mobile functionality
-
Get rider to ride faster - allow access to other options within app if needed
-
User flows not based in user needs
Using San Francisco as a target city, Yelp was used as a major source of rider dissatisfaction data. The major player in the San Francisco area for dockless bike sharing is Jump. User comments yielded complaints in 3 categories: Bikes, Support, and the App. Out of 20 comments, most referenced the bikes themselves (16 out of 20), next was Support (8 out of 20), and last was the App itself (3 out of 20). For the App, the following complaints were lodged:
-
App not recognizing ride is over/no way to shut down ride on app
-
No bike tracking on app
-
Cant find the bike/bike not there
some users had suggestions too:
-
User stats to track carbon emissions avoided
-
Personal totals listed and accumulated after ride ends
-
Connect to persona fitness apps
* pain points *
Since limitations lie in addressing all issues, the case stud is focused on the design of the App, its information architecture, and typical user flows. From the research data, we can find the pain points, and look for solutions to alleviate these problems and give users a better experience with bike shares.
-
Users had trouble ending their rides, and having both the app and the bike recognize that fact.
-
Users had to go through too many screens before they could ride the bike.
-
Apps not taking advantange of native mobile capabilities.
-
User's journey through the app is not based on user needs
user flows
I found an article on Bike Shares from Luke W. (https://www.lukew.com/ff/entry.asp?1995) that was particularly helpful in creating user flows for the different bike share companies in the U.S. He reviewed 6 bike shares, and took screenshots of his user flow through each of the 6 different apps . He reviewed Bird, Hello Bike, Jump bike, Off, and Spin. From these screenshots, I created user flows for each app and integrated design patterns from Lime Bike on Mobbin.
Please click on the image below to see a larger version:
personas
Tourist in downtown:
Joe Schmoe
Joe Schmoe is visiting with his family from the Midwest. His wife, and his two teenage children are with him. They've flown in the night before, and are staying in a downtown hotel. It is the following morning, and they have just finished breakfast and are trying to figure out where to go first. They are walking along the street, and see a fleet of Ride bikes...
Tourist along waterfront:
Lucy Goosey
Lucy Goosey and her fiancé are visiting from Europe. It's their first time in San Francisco and they are eager to get out and start exploring. They have been wandering around, and are a bit tired of walking, but still want to see more sights. While looking at a map, they notice a fleet of Ride bikes a block away...
Tourist in park:
Dan the Man
Dan is visiting from Asia. He is a young tech worker who had business in Silicon Valley. He had a couple days free to tack some travel onto his visit, so he took advantage. He has been to the bay area before, but never had much time to explore SF. He takes Caltrain up from the Peninsula, and wants to explore Golden Gate Park. He decides on Ride bikes. He steps off Caltrain, and sees a Ride bike sitting there...
design deliverables
initial wireframes sketch
low-fidelity wireframes
.png)
Between the low-fidelity wireframes, and the mockups, that the number of screen increases quite a bit.
I realized I needed to add additional functionality to the app that I did not have in mind initially.
high-fidelity mock-ups
I included the end of ride process as that was a major complaint form users.
My solution was to have the user snap a picture of where they leave their bike.
The app then confirms it is secured and locked, and issues a confirmation screen for proof.
This takes advantage of native mobile functionality and currently used processes to which the user is already accustomed.
lessons learned
I really enjoyed working on this project. It was my first attempt at designing app screens, so I am sure that it can be improved upon and my skillset increased. Designing within the bounds of a screen, all the while weaving in the native capabilities of mobile devices, was a good experience to have. I also noticed how initially, I thought I could create a solid user flow with a limited number of screens. However, once I delved into the mockups, I realized that I needed to take in account additional steps that were included in the user flow that did not come to mind initially.
I also discovered tools like Mobbin as a hub of screen designs that I borrowed heavily from. I welcome any feedback that readers may have, as I strive to create designs that are functional and beautiful.