How would you design a consumer application for a scooter sharing business?
+8 votes
in Product Design by (725 points) | 1.8k views

5 Answers

+6 votes

I would like to know
1. which scooter are we talking about (Ans – a)
a. 2 person scooter so that the owner/driver can offer the vacant seat to a rider
b. 1 person electric scooter that can be shared/rented to people by the owner.
2. Do we need a mobile or desktop application ? (Ans – Mobile)

Confirming that the business model is that the app connects owner/driver with riders so that they can scooter-pool together. For the initial design, I am assuming that the driver of the scooter is the owner as this would reduce complexity in design. Also, I believe we are not focusing on monetization for the business as of now. However, I will address the payment issues between driver and rider (Ans – yes to all)

Having understood the business, I will come up with personas, find their needs, build user stories, create solutions and evaluate them to create an MVP.
There are 3 Personas for our application
1. Driver
2. Rider
3. Customer Support who can remotely access application to help user resolve any issue

I will focus on Driver because other 2 do not matter if we cannot get Driver on-board first. This is the same reason why uber first on-boarded drivers and then opened it to riders.

Driver would generally be a person between 18-35 years of age who needs extra cash and can adjust with a stranger on a scooter for a ride to increase his/her income. I believe people 35 years are more likely to earn decent in comparison to the extra money they get by sharing their scooter. Of course, there can be people outside this range but I believe majority of drivers will be in this range. Few of the needs of drivers would be
1. Finding and confirming riders
2. Deciding a pickup point
3. Estimated fare
4. Payment and ride completion confirmation
5. Security
6. Hygiene

Since we are focusing on MVP, I will build the most needed features which are 1, 3, and 4. So my user stories are
1. As an owner, I want to find riders and send them a confirmation so that I can start my ride
2. As an owner, I want to know the fare I will get so that I can decide whether it is meaningful for me or not
3. As an owner, I want a way to tell the system that I completed the ride and will be paid so that I can drive without any hesitation

Usually I will pick one of these user stories and create solutions to them but since MVP will not be complete without all these 3 user stories, I will create options of solutions for each and select one solution for each user story to build an MVP.

Solution to User Story 1 (US1):
1. Display list of all riders near owner’s location who are interested in going the destination selected by owner. This can have additional details on age, interest etc.
2. Let the owner find a rider by riders’ username
3. Blind Match from nearby riders going to owner’s destination

Solution to US2:
1. Owner decides and sends the fare to rider
2. We estimate the far using a) distance and fuel cost b) data from other rider with same start and end destination
3. Rider decided and sends the far to owner

Solution to US3:
1. Rider send the ride completion confirmation
2. Auto tracking using GPS co-ordinates of both driver and owner
3. For assurance, we can have a) credit card b) create a wallet where rider prepays if ride completes c) insure the payment to driver

I will evaluate solutions in each story on customer impact and ease of implementation (skipping this, fairly simple). After the evaluation, I selected 1 in US1, 2 in US2, 1 and 3a) in US3 for the MVP.

What is the difference between PERSONA and USER? According to this answer, there are 3 personas but all of them are not users.
0 votes

The use-case is that it an Air BnB for scooters.
1. This app is a mobile app
2. The users intend to rent a scooter for a few days
3. The same app should be used to put up the listing as well. However, it is currently out of the scope of this document.
4. Users will have to pick up the vehicle from the owner, the owner will not come and deliver
4. The company will not pay for the petrol

In the current version, we will address three kinds of users
The user has come to a new city and wants to be independent while traveling that is why they want to hire a scooter. This is very common in South Asian countries.
The other user is someone who lives in the city and wants to drive down to someplace and will be back in a few days.
Another use case could also be someone wants to use the vehicle within the city for business purposes

Major restriction
Identification of a user. This process has to be manual as of now. The owner of the vehicle will take the responsibility of verifying if the person who has come to pick up the vehicle has a legit DL.

Basic Requirements
The user gets to select the date range for which they want to hire the vehicle
The user also gets to select the spot from which they want to hire the vehicle (details ahead)
The app in the background tracks the km the vehicle has traveled
The business model is to charge on the distance plus some daily charges
The daily charges will be paid upfront as a token amount while the distance fee will be paid at the completion of the trip
All the payment will be online in nature

Functional requirements

The user should be able to select the date range of the duration of the hire
The time when the vehicle will be picked and when it will be dropped off to the same location.
By default, it will pick the current location of the user. However, the user also gets to over-ride this and select some other location. This interface will be like Uber.

The above information should take them to the listing page. Let us talk about the listing page where all the available vehicles are listed
The following information will be shown on this page
Picture of the vehicle
Name (Company with specification)
Kilometers it has already been driven
Price (per km)
Distance from the location of the user

Following action items will be there on this page
Select (with the purpose of checkout)
View details

The user clicks on start trip, indicating the start of their trip and the km starts getting counted.
When the user clicks on end trip, the final km count is shown to them and a bill gets generated and the user is supposed to pay for the same

Definition of an active user- A user who has completely completed at least one trip and has paid for the same.

Sucess metrics
Number of app downloads
Number of bookings per day/per week vs Number of successful completion of trips
Number of repeats users per month

by (281 points)
you need to drill down into the user and their problems more
0 votes

I would answer this question assuming the interviewer has informed me that we’re building a Mobile App for scooters lending.

For this App we’ll have 2 main user types:

  • Lender: a person who’s offering one or multiple owned scooters for lending within specific conditions. 
    • Persona Motive
    • Gaining extra income with convenience in terms of logistics and payment.

  • Borrower: a person who’s seeking to borrow a scooter with certain preferences for a certain period. 
    • Personas Motive
    • Scooters enthusiast: experiencing new and unique scooter models without the need of large investment or long term commitment of buying a scooter.
    • Tourist: a person who wants a convenient, relatively cheap, and fun way of transportation within their period of stay in a city.
    • College Students or employees: a person seeks a relatively cheap, safe and convenient way of transportation without the need of doing quite active, sweating movements as in cycling. this persona is typically planning for a more extended period of borrowing.

Stating the critical borrower needs:

  • As a borrower, i want to browse all available scooters for lending and confirm a booking.
  • As a borrower, i want a convenient medium for communication with the lender.
  • As a borrower, i want a reliable payment solution to pay for the service.

Stating the critical lender needs:

  • As a lender, i want to list my scooter/s with a picture, textual details, and available lending times.
  • As a lender, i want a convenient medium for communication with the borrower.
  • As a lender, i want a reliable payment solution receive the payment for the service.

At this point, i’d mention several solutions and approaches for each User Story:

User Story #1: Browsing/listing User:

  1. Borrower gets to find scooters by revealing to them a map with the nearest lenders.
  2. Borrower gets to find scooters by showing them all listed scooters with description and picture.

User Story #2: Payment:

  1. Lender specifies daily rate and borrower pays with cash once they see.
  2. Lender specifies daily rate and borrower pays with digital credit card.

User Story #3: Communication:

  1. Implement a Chat medium.
  2. Show with text a phone number or email address next to every scooter

Prioritizing by implementation effort, minimum anticipated technical flaws and minimum required time to achieve product validation in the quickest manner: i’d go US1 with 2, US2 with 1, and US3 with 2.

This is my very first attempt answering PM exercises, your thoughts and feedback are highly appreciated!

Good structure. But I think you missed the end goal. The end goal is sharing the scooter ride and not lending the whole scooter.
0 votes

1. I believe in US scooter is very different than that from say Europe or Asia, which vehicle are we talking about?

2. Which market?

Let's say the answer comes back to US and US version of scooter which means single rider, no gas almost like a skateboard but with a longer handle for holding. Also no lender needed per se.

Business Model and App design are going to be similar to bike sharing like 'scoot', 'jump' or 'lime' which are already in place. Also a scooter only company 'bird' also has an app out. So those are good starting points. Not sure what else to say except that it's a standard 4 step UI

1. Locate where you are

2. Find the nearest asset on map

3. Approach, unlock, authorize pay and ride start

4. Ride, park & settle payment

If on the other hand it's a Europe or Asia use case with a lender and borrower ecosystem, then for that the design to be followed is the 'airbnb', 'turo' or 'getaround' design.

Is there anything in particular that is missed above and needs to be addressed for this question?
by (65 points)
Hi viaro29
Your answer is not following the right structure of how to answer a product design job interview question. See below
–2 votes

clarifications: sharing the ride (people going to the same destination paired??) or the scooter (like Zip car).
personas: borrower and lender
use cases: borrower wishes to reserve a scooter, lender wishes to lend out his scooter

– [screen 1] users login and have two options (screen 2) – lender or borrower.
– informational/ data (screen3) – lenders list location, vehicle model detail, time available (from and duration), – can view current status of his scooters including contact detail of borrower(screen 3a) a password to unlock the scooter(shared after checkout time is active), other details – lender information, contact details , option to provide reviews (screen 3a1).
– borrower (screen 4)- searches using location, time –> makes a reservation –> leaves a review after done(screen 4a1);

would prioritize above as it pertains to basic functionality
– lender/ borrower can address grievances (vehicle unavailable, out of fuel, etc.)

– number of app downloads,
– number of lenders signed up
– number of borrowers
information about their demographics to trace any dip (numbers from market analysis can be used as a baseline)

Your name to display (optional):
Privacy: Your email address will only be used for sending these notifications.
To avoid this verification in future, please log in or register.
Your name to display (optional):
Privacy: Your email address will only be used for sending these notifications.
To avoid this verification in future, please log in or register.

Related questions