Published on | Prototyping: From UX to Front End — Medium Vineet Arora

A product design case study

This is a case study of a personal project I recently worked on. The aim was to build a basic app flow for a leisure-bicycle renting service called Giri.

The problem statement

Giri is a leisure-bicycle renting service which has a few bicycles placed across Bangalore at some designated spots. People are required to pick-up and drop bicycles at these spots for which they would be charged by the hour. The hourly rates also depend on the kind of bike and the riding gear that the person rents along with it.

We required an app to help people explore, decide and book a bicycle that they could pick up and use for the booked time.

Why is this case study useful to you?

In this case study, I will take you along my thought process and show you how I made design decisions at every step.

This case study may be useful to you because:

if you are a beginner, you can use this as an example case study to refer to while working on your design projects.
if you are an expert, you can help me improve with your feedback in the comments.

This case study will cover three fundamental steps of the core experience:

Discovery — Showcasing various bicycles and options available
Decision — Helping the users make an informed choice
Booking/Pickup — Helping users book and pick-up the bicycle from the designated spot

What you will not find here:

The research part i.e. how I constructed the User Persona. We’ll assume the persona as a given here.
Flows like user onboarding, signup/login, bicycle drop or booking history etc. I will focus only on the core flow.

So, let’s get started:

Defining the target user

I defined the target user as a young leisure biking enthusiast in Bangalore.

User persona

Similar companies in the market

Although there are many popular bicycle renting services in Bangalore, renting bicycles, for many of them, is just one part of their business models which include renting motorbikes, scooters, and sometimes, everything.

There are the ones which focus only on bicycles but then the mobile app is not their core means of interaction. This is where Giri fits in. I decided to design Giri for iOS users (primarily because I wanted to explore designing for iOS). You don’t get such a luxury of choice in real life.

Breaking down the task

To break down the task, I drafted a story of a user called Arun who booked his bike through Giri.

Arun is a leisure biking enthusiast in Bangalore. He decided to book a bike for a weekend trip with his friends to Nandi hills. He used Giri to book a bike with some accessories. Then he went to the pickup location on his pickup time to pick up the bike. After his trip, he returned the bike back to the pickup location.

I found that Arun’s journey could be broken into 8 steps:

Decide to book a bike
Define where to pick the bike up from, time of booking and type of bike
Select a bike
Add accessories
Choose a pickup location
Pay
Pickup the bike and go for a trip
Drop off the bike

Out of these steps, the app would provide the core experience for step 2–6 and would complement step 7–8.

Defining the required engagement level

As Giri was to be designed to perform a task, I decided to design it with a task completion approach. For example, consider YouTube vs Uber; which app tries to keep you engaged all the time?

Detailing the task

To decide what all information would I need to seek from Arun and what all information would I need to provide to help him make a more informed decision, I decided to draft a detailed conversation between Arun and Giri.

As this approach forced me to personify Giri as a human, it helped me in getting a lot more clarity on how to make the experience more humane. Here is the link to the story. You may skip reading this conversation considering that it is a bit lengthy.

So, the final task flow of the Arun turned out to be this:

Task flow (Original photo here)

Deciding the layout

Before designing the layout of the app, I decided that I would design for ease of use with the thumbs because that would cover both the kinds of users–those who use thumbs and those who use index fingers (Read this amazing article on Reachability by Alex Kirhenstein). The implication of this decision was that all the primary action buttons would be concentrated in the bottom half of the screen where they could be easily accessed and all the major informative elements would be placed in the top half where they could be read more easily.

Now, for iOS, there were two ways I could define the layout of the app:

Two options available for navigation

As I was designing the app with a task completion approach rather than an engagement approach, bottom nav was not the primary part of core experience. Thus, I omitted the bottom nav.

I chose collapsed nav over bottom nav as navigation is not a part of the core experience.

Wireframing

Using these decisions and the conversation between Arun and Giri, I designed the low fidelity wireframes.

Home screen: Enter pickup, dates for renting, and bike type
Initially, I designed the screen this way

Home screen wireframe

However, after feedback from Agniva Si on Dribbble (yes, a few people do give feedback other than “wow”, “good work”, “loving it”, etc. on Dribbble), I realized that having I could use the real estate being consumed by the calendar to show bike types instead. So, I modified the wireframe and resulted with this:

Home screen wireframe with feedback incorporated

2. “Select a bike” lists all the available bicycles and shows the chosen options to keep Arun assured that he has entered the right details

For this page, I had two listing options i.e. List view and Thumbnail view

My aim here was to let Arun compare different models which could be done better by placing the items along a single dimension (vertical or horizontal). Given the number of items and the device width, vertical view was more suited for my case. Hence I chose it.

3. Bike details page to help Arun make an informed choice

4. Adding accessories.

5. “Review cart” page shows all the items and the details of the booking. The map in the end shows the locations near Arun’s entered pickup.

6. Choose payment option

7. Booking success page

8. Home screen after a booking is made and a trip is upcoming

Defining the UI style

To identify what all UI elements I needed to design, I listed them down in a doc.

As the app targets leisure biking enthusiasts who love adventure and energy, the UI of the app needed to reflect energy and adventure. Styles were supposed to be dynamic and the colors vibrant to complement the user experience.

Color choice

I decided to use Tomato (#FF6347) as the app’s primary color as it represents the warmth and energy of Orange.

As thoughtco.com puts it: “Use this shade of red to gain attention and infuse a page with energy without being overly stimulating.”

However, when I actually used the color and tested the experience on my phone, I found the color to be overly vibrant thus making it difficult to focus on the content. Thus, I reduced its saturation and ended up with (#FF7961) as the primary color.

Font selection

Although the core of the app is freedom and energy, I abstained from using freehand fonts because the app aimed for task completion and was supposed to provide maximum readability. The font needed not be too straight and pointy but should also not be too rounded. I proactively avoided serif fonts as they represent sophistication which was not the core idea here.

On googling Google fonts, the font combination that seemed to fit the requirements best was Sintony as display font and Open Sans as body font. Where Sintony’s freely cut edges and slightly square structure represent ease and freedom, a perfect combination to represent youth, Open Sans has a neutral and friendly appearance, and was thus good for the body font.

UI design

With all the wireframes decided and styles in place, I designed the UI of the app.

And using Invision, I compiled all the screens into a presentable prototype.

Click here to view the project `Giri-Bike rent`

Pointers for further thinking

Although it appears that this was a lot of work (and it indeed WAS a lot of work), we are just scratching the surface here. While designing this app, I made a number of assumptions (e.g. Arun can be trusted enough that we don’t need him to deposit a security amount before taking the bike), and omitted a number of cases (e.g. what if Arun gets late in dropping off the bike). You can use these loopholes to build further on this design.

Also, one of my goals these days is to deepen my thinking skills. This exercise is an attempt towards that. I would love to know your thoughts on how I can design better experiences.

I was able to complete this project only because a few people were there to help whenever I was stuck. So, I’ll thank them for their efforts here:

Thank you, Vasudha for motivating me to complete this project when I was stuck. Thank you, Supriyo, Agniva Si, Nikhil Yadav, Akshay Kumawat, and Amish Bedi for your valuable feedback that helped me improve the app experience. And last but not the least, thanks to Dhruv Bhanushali who once again took care of my grammar and vocabulary.

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

Giri: Bike renting app was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Giri: Bike renting app

Cool stuff, every week

More Articles