Embed Size (px)
Citation preview
Designs by Akhil Dakinedi03.19.15
CONTENTS
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
Designs by Akhil Dakinedi04.16.15
MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND01
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.
MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
02
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
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
MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
03
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.
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.
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.
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.
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.
MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
04
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
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
MakeMyTrip
APP FLOW
STRATEGY
WIREFRAMES
Checkout Funnel
User Flow
Iteration
Final
RESEARCH
BACKGROUND
05
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Designs by Akhil Dakinedi03.19.15
