+8 votes
275 views
Post and review answers and feedback to answers in the comments section of this post.
asked in Product Design by (548 points)
edited by | 275 views

3 Answers

+8 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.

answered by (155 points)
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

Users
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.

Metrics
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

answered by (206 points)
0
you need to drill down into the user and their problems more
–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

DESIGN
– [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);

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

METRICS:
– 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)

answered by

Please log in or register to answer this question.

Privacy - Cookies - Terms - Contact