The document outlines the ideation and design process for a checkout flow in the MakeMyTrip app, focusing on enhancing user experience in hotel booking. It describes the research conducted on existing apps, the app flow strategy, various wireframe iterations, and the incorporation of culturally relevant features for the Indian market. The final wireframes received positive feedback from the client for their attention to detail and usability, despite the challenges posed by the lack of defined user stories.

1. Designs by Akhil Dakinedi
03.19.15

2. CONTENTS
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
Designs by Akhil Dakinedi
04.16.15

3. MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND01

4. BACKGROUND
• Client is one of India’s
largest travel agencies.
• Intrepid had 80% of the
designs already done.
• I was brought on to ideate
and conceptualize how
the checkout process
would work for the user
after they have selected a
hotel and wish to book it.
• We had little to no user
stories for checkout, so a
lot of assumptions had to
be made. Their website
was used heavily for
reference.
• Deliverables: A first pass
at high-fidelity Android
wireframes showing the
user flow through the
checkout process after
they have picked a hotel.

5. MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
02

6. RESEARCH
• In order to gain more
insight into how a checkout
process works, some
research was done to look
at how other apps handle it.
• Client specifically stated
that they wanted Material
Design incorporated into
their Android app, so a good
place to start was the
Google Play Store itself.
• The step-by-step manner in
which required text fields
revealed themselves was a
neat idea; it does not
overwhelm the user with a
long form field and saves
valuable real-estate on
mobile screens.
Alert dialogs layering
on top of each other
Built-in
error states
Sequential text fields appear
only when necessary by
expanding alert dialog
Asking for plenty of user action through
taps doesn’t seem to be a problem
Google Play Store

7. RESEARCH
• Expedia, a travel app, was
also researched to see how
they handle features
specific to hotel booking.
• Navigation is well
structured and laid out.
User has a clear sense of
what they have completed
and what is coming next.
• Filling in the “Checkout
Information” cells with user
input is good design.
• “Slide to Purchase” is a
deliberate action which
prevents accidental taps,
especially if there’s no
“Review Your Booking”
screen.
User flow splits
into two from here
Confirmation state
of Traveller Info
Sliding is a very intentional
action which doesn’t cause
any accidental purchases
Cost Summary is a nice redundancy;
can get overwhelming in edge-cases of
multiple bookings + multiple rooms
Expedia

8. MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
03

9. APP FLOW
• An app flow was
constructed to ensure
that I was capturing all
the required information
in all the screens.
• It was also crucial in
structuring my thought
process around all the
different scenarios and
possible user actions in
the flow.
• This was absolutely
essential for the design
process; it served as a
valuable constraint in
what could have
otherwise been a project
with a lot of scope creep.

10. APP FLOW
• As soon as the user has
selected a hotel and have
entered their information,
they would see the
“Booking Review” screen;
serves as a redundant
confirmation mechanism.
• After they have reviewed
that their booking is
correct, they would see the
“Cost Summary” screen,
which would break down
and itemize the total cost
of the booking.
• This is a crucial point
because it is where users
drop out of the funnel the
most. If they decide that
the cost is too much, they
may decide to not progress
any further.

11. APP FLOW
• After confirming the Cost
Summary, the user is
prompted for their details.
• Since this app will be used
in the Indian market, I tried
to stay as close as possible
to the cultural context (ex:
using “Surname” instead of
“Last Name”, spelling
“Traveller” in the British
manner with double L’s).
• This is a fairly
straightforward section, so
it was kept as minimal and
simple as possible.

12. APP FLOW
• After entering their name
and contact info, the user
is prompted for payment
options.
• MakeMyTrip has a “Net
Banking” payment option
in addition to the standard
credit/debit card checkout.
It takes the user out of the
app and into their banking
portal in a mobile browser.
• The other interesting
payment option is “Pay at
Hotel”, which allows the
user to call a number at the
hotel (which is never
picked up) and give a
missed call, which
confirms the booking. They
pay at the hotel when the
show up and the missed
call serves as proof that
they made the booking.

13. APP FLOW
• Finally, a screen appears
confirming to the user that
their booking was
successfully processed
and that they will receive a
confirmation email.
• If there was error in the
process (ex: unable to
process payment, someone
else booked the room while
this user was in the
checkout flow), a relevant
error message would
display, with a phone
number to call for
assistance or live booking.

14. MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
04

15. STRATEGY
• Before wireframing, I
brainstormed a lot with our
product strategist on what
made the most sense for a
user flow in a checkout
process.
• We cross-referenced our
app research heavily with
how MakeMyTrip currently
handles the checkout
process on their website.
• I made tons of sketches to
simulate how the user
would feel going through
the process (ex: whether or
not the order in which they
perform the tasks made
sense).
• These are very loose proof-
of-concept sketches and
some rough ideation
around user input.
User Flow

16. STRATEGY
• Our client had made it very
clear that had a lot of
challenges in getting
people to actually make
payments on mobile. We
wanted to ensure that we
solved this problem.
• We came up with a
finalized flow which shoots
for high visibility into what
is happening and ease-of-
use in terms of navigation.
• We wanted our users to
always be aware of where
they are in the flow and
how many steps they have
left to complete. We also
wanted them to be able to
edit the information
without taking them out of
the flow too much.
Checkout Funnel
REVIEW BOOKING
COST SUMMARY
TRAVELLER INFO
PAYMENT INFO
BOOKING CONFIRMED
1
2
3
4
5
Confirm Hotel Info
Edit Hotel Info
Confirm Cost
Cancel or change booking
Confirm Traveller Details
Choose Payment Method
Enter Payment Info

17. MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
05

18. WIREFRAMES
• My first instinct was to
simply make a screen for
each section in the flow.
• So I followed the Material
Design guidelines and
started laying out the
wireframes. Related
sections were grouped
together where appropriate.
• The further down I went this
road, the more it made
sense to not do this. It feels
a bit overwhelming that the
user is being taken to an
entirely new series of
screens in the app just to
make a payment.
• There’s also no clear way to
indicate progression here,
so I stopped doing this
pretty quickly and tried
something different.
Iteration - 1

19. WIREFRAMES
• I started toying with the
idea of a series of alert
dialogs layered on top of
each other.
• The benefit here is that the
user is not taken to an
entirely different screen.
The previous hotel details
screen is still in the
background, so it doesn’t
feel like an entirely new
section of the app. Plus,
alerts are a stronger call to
action than flat screens.
• The Google Play Store
seemed to pull it off pretty
well in its execution, so I
felt that this was worth a
shot in this case.
Iteration - 2

20. WIREFRAMES
• The idea is that as the user
keeps going, more alerts
would layer on top of each
other. This would give them
a sense of accomplishment
in that they are already so
far along in the process that
they might as well keep
going. However, it still
doesn’t signify “remaining
steps” well enough.
• It also seemed like a
slippery slope in that a
bunch of layered dialogs on
top of each other could feel
too cluttered and clunky.
• The Payment Method
screen has a lot of icons
verifying to the user that it
is safe to make mobile
payments. Our client
pushed very hard for some
indicator of security and
safety here.
Iteration - 2

21. WIREFRAMES
• The “Enter Card Details”
section is where this design
really starts to break down.
The concept is that it would
sequentially reveal text
fields when the user is ready
to input that information.
Expanding and collapsing
the dialog along with
displaying error messages
could get very tricky really
quickly.
• Even in the “Confirm
Booking” screen, the layered
dialogs feel cluttered. One
workaround to this is to limit
the layered background
dialogs to show only two
regardless of whether there
are three or five behind.
• I wanted to give another idea
a shot before finalizing the
wireframes.
Iteration - 2

22. WIREFRAMES
• This was another iteration,
where instead of layered
dialogs, the user simply
swipes left to advance to the
next dialog. The user can
also tap the “Proceed to
Checkout” or “Continue”
buttons to do the same
thing.
• I felt this was a much
cleaner and more elegant
design than cluttering the
screen with dialogs. The
user sees the previous
screen peeking out of the
side of the screen.
• In the first screen, the user
has swiped left from the
“Review Booking” screen to
land on “Cost Summary.” In
the second screen, they have
swiped once more to land on
“Primary Guest Details.”
Iteration - 3

23. WIREFRAMES
• There are a few usability
issues with this. We’d have
to disable swiping when the
“Continue” button is
inactive. The user can only
swipe forward when they
have filled out all the
required information.
• In this concept, the user can
also swipe back to go to the
previous screen. In this
example, the user has
progressed to the “Payment
Method” screen but then
swiped right to go back to
the “Primary Guest Details”
screen (still editable by
tapping on the text fields).
• I liked this iteration but felt
that the execution could be
better, especially with the
addition of a progress
indicator. This helped me
build the final concept.
Iteration - 3

24. WIREFRAMES
• In the final wireframes, the
swipe-alert dialogs were
preserved, but Next and
Back buttons were added for
more clarity and users not
familiar with swipe
mechanics.
• A progress indicator was
also added up top. The
current screen bubble would
have some sort of visual
indication (glow) and the
completed screens would
change to a different
highlight color.
• In this version, there are no
buttons in the dialogs
themselves. Tapping certain
fields in the dialog makes it
editable (ex: tap “5 guests”
to edit number of guests, or
“Add coupon code” to bring
up the keyboard and add it).
Final

25. WIREFRAMES
• If the user taps the “Apply
Coupon Code” text field in
the Cost Summary, it brings
up the keyboard and allows
the user to type in the
coupon code.
• Once they hit enter on the
keyboard, the coupon code
applies to the trip total and
deducts the discounted
amount right in the Cost
Summary. If it is an invalid
coupon code, an error
message would display on
this screen.
• In all these mockups, the
Indian Rupee is being shown
as the currency in order to
stay true to realism. The
amounts are also as close to
real as we could get, in order
to ensure that the necessary
amount of digits fit in the
given space.
Final

26. WIREFRAMES
• On the Cost Summary
screen, tapping the
“MyTripRewards” button at
the bottom-left of the dialog
would bring up another
dialog on top which details
the rewards program.
• This is one of the two
instances in the flow where
a dialog is layered on top of
the existing one.
• This was a feature that our
client specifically requested.
They wanted to inform the
user of all their available
options. Tapping any one of
the tiers takes the user to
the MakeMyTrip mobile site
where they can sign up for it.
The user dismisses the
dialog by simply hitting
“Done.”
Final

27. WIREFRAMES
• When the user gets to the
“Primary Guest Details”
page, the Next button is
initially disabled. The user
can activate a text field by
tapping on it.
• Once activated, the
placeholder text moves
upwards to make room for
the user input.
• As soon as the user commits
an entry, the system jumps
the user to the next text
field. Ex: As soon as the user
hits Enter after typing in
their First Name, the app
immediately activates the
Last Name text field.
• Our client decided to scrap
the “Surname” title and
replace it with “Last Name”
in order to accommodate a
global market.
Final

28. WIREFRAMES
• Error-checking is built right-
in. Once the app jumps the
user to the next text field, an
error message displays on
the previous text field in the
event that it was an invalid
entry. User cannot progress
through the flow without
fixing these errors.
• The second screen here
shows what a completed
“Primary Guest Details”
screen would look like. The
Next button is now active
and the user can progress to
the Payment Method screen.
• The scope of the project had
changed slightly by this
point in the project, so not
everything that was in the
App Flow is shown in these
wireframes.
Final

29. WIREFRAMES
• The Payment Method screen
tells the user the final
amount that they will be
paying and asks them to
pick a payment method.
“Pay at Hotel” was added
into the list of options at the
client’s request.
• In these mockups, the user
taps “Credit Card”, which
brings up the Enter Card
Details dialog. “Debit Card”
would trigger the same
dialog. “Net Banking” would
open the user’s bank portal
in a web browser, and “Pay
at Hotel” would take them
straight to the Confirm
Booking screen.
Final

30. WIREFRAMES
• As the user starts entering
their card number, the app
detects what card the user
has and saturates the icon
for that card, while making
the other cards disappear.
• After the user commits their
card number through the
keyboard, the expiration
date and the CVC fields
appear. User can pick
expiration date through a
date picker (placeholder text
would say MM / YY, each of
which can be individually
tapped) and then enter their
CVC.
• This sequential revealing of
text fields seemed to work
well on the Google Play
Store, so the design pattern
was borrowed and applied
here quite well.
Final

31. WIREFRAMES
• Once the user commits
their card details, it shrinks
down into a cell which can
be expanded again by
tapping the down arrow to
its right.
• More text fields are
revealed prompting the
user for input about their
credit card billing address.
The country field is a
dropdown of all countries.
• Once completed, there is
also a “Save card details”
checkbox in case the user
wishes to save their card
information the next time
they use the app to make a
booking. They would still
be prompted to enter the
CVC, as it won’t be saved in
the app.
Final

32. WIREFRAMES
• Finally, the Confirm
Booking dialog also has
actionable cells for
traveller info and payment
method.
• The first screen shows the
Credit Card booking
confirmation. A slide -to-
purchase is an intentional
motion to make a
purchase, preventing
accidental taps.
• The second screen shows
the Pay at Hotel booking
confirmation screen. The
user can slide to give the
hotel a missed call, thereby
confirming their booking.
• There are also weblinks to
legal documents, which
open up the web browser.
Final

33. WIREFRAMES
• Our client was extremely
pleased with this deck of
wireframes. They were
particularly impressed at
our attention-to-detail and
a lot of the edge cases that
we were able to capture.
• These were handed off to
another designer, where
they were all skinned with
the right colors and visuals.
• This was a good UX
challenge, given that there
were no defined user
stories; everything had to be
made up on-the-fly.
• It was also a great learning
experience jumping onto a
small (yet crucial) portion of
a project and building off of
a different designer’s work.
Final

34. Designs by Akhil Dakinedi
03.19.15