Lime scooters recently entered the streets of Salt Lake City. While living in Salt Lake I enjoyed using the scooter service many times. However, I often have the following problem: I find a scooter close to me on the map. Then, as I get closer, I see another Lime rider pick up the same scooter I was searching for.
During this redesign, I wanted to explore if there was a feature to solve this problem.
Before diving into this problem, I wanted to 1.) find out it if other riders are facing this problem 2.) and understand the implications of the problem 3.) and identify other problems users are facing.
- Busy Lime riders do not feel confident that a scooter will still be at the location by the time they get there
- Lime riders walk 0.5–1.5 miles to find a scooter
- Lime riders want the ability to rent multiple scooters for a group on one phone (check out the case study for this problem)
- If Lime riders can’t get a scooter in time they will find a more dependable form of transportation
- In a survey conducted by Lime, results showed that 55% of riders are using scooters to commute to/from work/school
Lime riders in a time crunch have no way to ensure that they can find an available scooter.
Rachel is a 25-year-old graphic designer working at an agency in Boston. She enjoys photography, exploring the city and socializing with friends. She typically uses Uber but has started to try out Lime scooters. To her, the app seems simple and easy to locate the scooters around the city.
Rachel’s Journey Map:
- Rachel is looking to get across the city for lunch with some friends
- She gets on the Lime app and finds a scooter about a mile away
- As she is walking she sees the scooter at the end of the block
- As she gets closer she sees another Lime rider walk up to the scooter and takes it
- Rachel ends up calling for an Uber because she is late for lunch now
I started my ideation process by creating specific a design question based on the from the research I found. Below I looked at the current Lime app user flow for renting a scooter, this allowed me to understand the layout even more.
Design Question: How might we ensure busy Lime riders can feel confident that they will find an available scooter?
Potential feature solution: When Lime riders reach a certain distance from the scooter selected, the app will give them an option to reserve the scooter for a certain price.
Things I considered:
- What is a fair price?
- How close is a fair distance for reserving a scooter?
- Will the reserve price still help the business make money?
- Are riders willing to pay the extra fee to reserve the scooter?
I sketched out a storyboard to visualize the interactions with this feature.
Why this idea?
To me I feel like there are two main value propositions for the business and the end customer:
- Customer trust — with the ability to guarantee an available scooter, Lime riders will trust the service as a dependable way of transportation.
- Profit maximization — through unused scooters being reserved for a price, the business will increase revenue.
Pricing the reservation
Currently, Lime scooters cost $1.00 to unlock and $0.15 a minute to continue riding. If the rider can reserve the scooter from 0.5 miles away then the price of the reservation depends on how long it takes for the rider to get to the scooter. If the average rider takes 15 mins to walk 0.5 to the scooter than that would cost 15 mins * $0.15 = $2.25. Therefore, a fair price for a reservation could be $3.00. That way the business would make an extra $0.75 per reservation.
New things to consider:
- How do you ensure that riders get to the scooter within 15 minutes of being reserved?
- Would a countdown timer solve that problem?
- What if they want to turn off this feature?
- Should there be an option to reserve if you are already within 0.5 miles of the selected scooter?
Validating the idea
I mocked up 3 different screens and added each to a separate prototype. I conducted a multivariate test to see which screen would do best. Overall most participants ended up using the reservation feature on option B because the price was clear and the description was short.
I conducted a similar test but for Lime riders within the 0.5-mile ratio of the selected scooter. Option B did best during this round of multivariate tests. Test participates said that Option A had text and they wouldn’t read it.
Testing the timer
I tested out the full user flow from reservation to expired time with 5 participates.
- Users understand why there was a required time to get to the scooter
- Users want this feature to be optional
- Users felt 15-minutes was enough time to get to the scooter
- Users want to know they have a 15 minute time limit on the reservation
Users exploring the feature
To help users be aware of the time limit on the reservation feature, I added a first-time feature interaction. This would allow the user to explore the reservation feature for the first time without committing to it.
After the user has interacted with the feature for the first time the app will just give the option to reserve for $3.
I added a way for users to turn on/off this feature in the settings page.
Things to consider:
- How often will users turn off this feature?
- Is turning the feature off easy for users to find?
Testing the full experience
After gaining small bits of feedback from users I wanted to test the experience as a whole. I created a prototype of the full experience then created some task scenarios for the test.
I am currently testing the solution as a whole to gain user feedback. I will update this case study as I continue to learn more.