We conducted a 2-day design sprint with a given problem statement focusing on the problems IITR junta faces around e-rickshaws in the campus. There were three teams with around six members in each, who worked on proposing an application for the above problem.
For the sprint, we followed the three stage diamond model.
We started off by making HMW notes in which we wrote down whatever pain points, ideas, and solutions came to our heads related to the problem.
To organize these notes, we segregated them into groups.
We defined our vision statement to provide a direction to our next steps -
"Get a great ride, whenever, wherever!"
To accomplish this, we needed to eliminate the problems of unavailability at specific locations, difficulty in payment, and also ensure that the rider reached his destination on time and could report any issues post drop off.
Based on our HMW notes, we identified the most ideal, inclusive path which we wanted to make possible for the rider.
Presently, e-ricks cluster at specific locations and are often unavailable in some areas. This makes the users in that area unclear about the presence of any e-rickshaws nearby.
So we proposed to track the e-ricks by using the driver's GPS and show this in the user's app. We also decided to provide contact details of the nearby drivers in the app so that the user can call them to his location or call them for any clarifications.
On interviewing the e-rick drivers, we found out that most of them had bank accounts and debit cards. Also, they were ok with payments being made directly to their bank accounts.
We proposed making the driver's bank details available through the app and also making payment possible from within the app.
On the driver-side app, we included a passbook feature so that the drivers can view all the payments and keep track of them.
Currently, E-rickshaw bookings are possible only by contacting rickshaw drivers and that too only 4-5 drivers
(who stay in the campus) generally take these bookings.
So on the driver-side app we provided an option to allow/deny bookings. When a user makes a booking request on user-side app, a notification is sent to all
the drivers who had allowed taking bookings on their apps. The first driver to confirm gets the booking and the contact information of the rider and the driver are displayed to each other so that they can interact smoothly.
a)User side booking screens. b)Driver side booking acceptance screens.
Finding the solution to this was one of the most challenging tasks during the sprint as we were not able to figure out how to make the users remember the e-rickshaw they rode on.
Upon much thinking, we thought of providing a permanent e-rick ID to each rickshaw and use this to track and maintain a database of driver details. Now to make riders aware of this e-rick ID, stickers of IDs will be present at highly visible locations within the rickshaw. This e-rick id can be used by a passenger to report a driver for misbehavior/ charging extra and can also use it to contact a driver to track down luggage lost in an e-rickshaw. Even if a rider misses the e-rick ID, the app will take details of lost luggage and send it along with the rider's details to the control room.
The driver-side screens were designed with big CTAs and minimal information, keeping in mind the less familiarity of e-rick drivers with tech.
My team comprised six members, with 3 of them having 2-3 years of experience in design and the rest of us were newbies. So working with them definitely helped me get to know about the various methods better. I actively participated in the discussions during the various phases of the sprint, bringing my ideas to the table(although only a few of them got accepted, Lol). I made the wireframes alongside the seniors, and I was assigned the task of designing the complete UI of the driver-side app.
Overall the sprint was a fun and insightful activity with each team striving hard to come up with the best solution. And guess what, the three teams came up with unique solutions for the above problem in just two days.
