How to Tackle a Design Interview Challenge
A framework I’ve used for a variety of design exercises
A Bit of Background
I did this project as part of a product design interview (of which, I’m happy to report I got the job!). My intention of publishing this piece is to demonstrate a framework I’ve used that has worked for a variety of design interview challenges.
Full confession: I used to dread the design exercise portion of the interview process. You never knew what to expect! Some challenges would be super abstract (e.g. Design a way to travel through time… Also, your users are blind). Others would be an actual problem in the company (e.g. Our referral rates have been lower than expected. Redesign our referral flow to increase sign-ups).
And of course, they tell you to not spend too much time on it… ;)
Thankfully, after doing many challenges and researching others’ frameworks, I came up with my own approach. I realized that the goal is to be thorough enough in your design process, while being efficient with your time. It also made these projects more fun for me, more strategic, and ultimately helped me impress more hiring managers.
Check it out below—I hope it helps if you’re currently trying to improve your design challenge process as well!
The Challenge
Design a mobile calendar picker for choosing the dates to stay at a hotel for a new hotel app.
Think about who are the various types of users and the use-cases for who you are designing for.
My Approach
I approached the exercise in five parts:
- Context: Problem/Goal, Constraints/Assumptions
- Understanding Users: Guerrilla User Research, Competitive Review
- Setting the Stage: Requirements, User Flow, Brainstorm
- Design: Wireframes, Interactions, Feedback Iterations
- Final considerations: Edge cases, Next Steps, Last Thoughts
And with that, let’s begin!
Problem/Goal
Planning travel can be so fun! Yet so overwhelming. With an abundance of choices and prices that fluctuate every minute, travelers need a way to discover and book hotels efficiently, effectively and within their constraints.
The goal is to design a mobile check-in/check-out date picker that helps travelers successfully and efficiently complete their overall hotel booking experience.
Constraints/Technology
Hotel apps come in all shapes and sizes. I chose to design for a native iOS app and a third-party hotel app, in which users can search for a variety of hotels in a location. I decided to go down this route, hypothesizing that users are more inclined to download and use a mobile app with a database of multiple hotels, like Expedia, than a single brand app, like Hyatt.
Assumptions
- Assume that the process of choosing dates to stay at a hotel is part of a greater “planning travel” experience. Choosing dates may or may not occur during researching, browsing and booking flight travel and hotels.
- Assume that the users who would use a mobile hotel app are technologically savvy and familiar with existing patterns around popular travel apps. Conduct a quick audit of familiar travel app patterns.
- Assume that the hotel app makes money from bookings made from their app. Design should make the overall experience of booking as easy as possible and result in increased conversions.
- Assume that a business goal is retention. Design should make it rewarding for users come back and use the app again by reducing cognitive load (e.g. saved searches, meaningful defaults, pre-filled forms, etc.)
User Research
Listing assumptions uncovered some questions I needed to learn from users. For example, I assumed that most people were choosing dates after making concrete travel plans. But did they really? I quickly interviewed 3 people I knew who travel frequently and have used apps to plan their travel. Asking questions like, “Walk me through the last time you used a travel app or booked a trip,” I was able to nail down some user behaviors, needs, goals and synthesize them into user types below.
I came across three types of travelers: The Power Booker, The Researcher and The Spontaneous Traveler.
“The Power Booker”
“Once I’m ready to book the hotel, I’m already building an itinerary. At this point, I’ve approved the work trip, booked the flight. The more I book, the less and less flexible things get. I just want to get it done fast.”
The professional who travels solo and frequently for work and books last minute. Typically they’ve already booked their flight when booking hotels, so their dates are fixed. They need a highly functional and reliable booking experience, because they’re in a rushed and stressed state. They filter for quality and amenities — choosing dates is just a step to get out of the way.
Job Story: When users have a last minute work trip and they have already booked their flight, they want to open the hotel app and enter their dates as quickly as possible, so they can focus on finding a hotel based on other preferences like quality and reviews.
“The Researcher”
“I’ll use a mobile hotel app for initial research and I’ll save or favorite hotels. And then go to my laptop when I’m ready to book. I use the mobile app more to do initial research.”
Young professionals who travel for leisure and most times, are planning a group trip. They plan in advance, but dates are more flexible with sensitivity to price. They need the app to be flexible with search and discovery and manipulating dates. On mobile, they engage with filters for initial browsing, before moving to finally book on the computer once everything is confirmed.
Job Story: When users are beginning to research rooms in advance, and they need to secure hotel rooms for a group of people, users want to easily manipulate dates and other filters, so they can search and discover best prices before making a decision to book.
“The Spontaneous Traveler”
“My brother and I were road-tripping and spontaneously decided to stop and spend a night in LA. We googled places, found a hotel and booked through their mobile web browser.”
Tech-savvy adults who want a quick weekend getaway or just need a room for the night. They rely on a mobile app for the ease and on-the-go spontaneous use. They need convenience and a way to book immediately.
Job Story: When users need last minute places, users want to open the app and immediately be able to search for rooms available that night nearby (within 20 miles), so they can have a place to crash or get away for the night.
Competitive Review
I also took a quick look at some of the apps that users had mentioned:
A quick review of the competition gave me an inventory of existing mobile patterns, strengths and weaknesses to begin brainstorming designs for these different types of users.
Requirements / User Flows
I came up with a list of general requirements for a date picker and started to work through a user flow of booking a hotel.
Brainstorm
Working through the task flow, I began to see where each type of user converged and diverged in their path to book a hotel. Initial ideas began to form based on these needs:
- Idea 1: Scrolling Calendar in Separate View. The Power Booker needs to book hotels as easily and quickly as possible, while knowing fixed dates. A Power Booker may only input dates once. Provide a separate calendar view, in which the dates don’t encumber the search results.
- Idea 2: Paging Calendar in Same View. Researcher may need to access and re-access a calendar view before booking a hotel. An accessible calendar would be a priority.
- Idea 3: Speedy Defaults. The Spontaneous Traveler needs a room just for the night, so dates don’t require much deliberation. Dates could default to check-in today and check-out tomorrow.
Initial Wireframes
Initially, I created two wireframe flows based on two different calendar concepts: scrolling vs. paging. But eventually, I took parts from both these ideas to satisfy multiple user groups.
This wireframe flow allows the user to page between calendar months, while scrolling through search results. Swiping horizontally also preserves a look at search results below — ideal for the Researcher who wants to access results and the calendar easily to browse multiple hotels.
Choosing Dates Flow
By default, the check-in date is highlighted as today and the check-out date, as tomorrow. Selection colors are differentiated, so the user can view the length of their trip and recognize check-in vs. check-out dates. In order to select a different check-in date, the user taps on a future date. The user is unable to select a date that has passed. Dates are indicated using a lighter gray to show they are inactive.
Accessing the Calendar Flow
In order to access the calendar, the user taps on the date range bar from the Search Results screen. This interaction “tucks away” the calendar, while still providing easy access when the user wants to change dates.
Final Wireframes
I quickly iterated based on both user feedback and design critiques with Vlad and other designers. In this iteration, the focus was on the details and UI design. For example, users said, “Images are the first thing I look at and want to see.” The thumbnail icon before felt too small. In my final wireframes, the search results included wider image sizes with the CTA button to view the pricing located right beneath. Adding in real imagery also helped reassess UI decisions.
Scrolling Search Results
Instead of a form, the Nav bar now contains the major booking inputs to reduce cognitive load and additional screen. The Location defaults to current location, given the user has allowed location settings. The Room/Guest defaults to 1/1 to satisfy both the Power Booker and Spontaneous Traveler, who are usually booking solo.
Accessing the Calendar
The user accesses the calendar by tapping down the date range bar. Both the Researcher and Power Booker are able to focus on search results, given the calendar view “tucks away” and disappears upon a swipe / scrolling gesture to view search results. This serves both the need to access the calendar easily, but also have a rich browsing experience.
Choosing Dates
In the previous wireframe flow, users needed to tap a “Save” button in order to populate search results. However after critiquing this interaction, I felt that it was an unnecessary barrier between user actions and system feedback. In the final flow, users only need to tap the check-out date in order for search results to load. The “tuck away” gesture also solves the need to have another step required to access search results.
Next Steps
Errors, dead-ends, failures, oh my! Next steps would be to test again and see how these concepts fare in the hands of more users. I’d remind myself of the original goal:
The goal is to design a mobile check-in/check-out date picker that helps travelers successfully and efficiently complete their overall hotel booking experience
Testing for success and efficiency would be a usability test, which could measure how long it would take for users to book a hotel, how successful they are in choosing a specific date range or accessing the calendar.
Next iterations would also work through more edge cases. Some examples:
- Lengthy date ranges. What would happen for users who are selecting dates that are too long for hotel stay. Most hotels only allow for a stay up to about 10 nights. What is the error when a user selects? Perhaps certain dates after 10 dates after “Check-In” date are deactivated and unable to be selected.
- No vacancy at specific hotel. What if a specific hotel being searched is completely booked and there are zero available rooms for that date? Do we show comparative hotels below or prompt the user to select different dates?
- Empty search results. For example, if the user has selected an obscure location that has hardly any hotels. What would happen?
I’d be especially curious to see how the “tuck away” swiping gestures works for browsing and how frequently users are actually readjusting dates. My hypothesis is that scrolling through search results is an intuitive gesture and won’t require users to learn that the calendar is accessed in that way — but I might be wrong! I’d be keen to learn how much value that interaction actually provides users in searching for and discovering hotels… If it indeed would be worth the development cost.
Final Thoughts
I was surprised to learn that the users I interviewed honestly don’t use mobile apps to book travel. Booking trips and choosing dates — this behavior falls into a mental model of “planning.” Users in “planning” mode need to review information in detail, deliberate with other stakeholders, research over time. It makes sense why most users will defer to computer usage vs. apps.
Do mobile travel apps design for behavior change or not? That is the question! In this exercise, I chose to design for existing behaviors. I learned that the best value a mobile hotel app can provide currently is during the initial browsing and curation phase of a user’s entire trip planning experience. However, I’m excited to see how our needs may change as we develop new behaviors around planning travel in the future.
Thank you!
What did you think? I’d love to hear your thoughts on frameworks you’ve found successful in your design challenges. Feel free to reach out to me to chat or grab coffee if you’re in San Francisco.
—Chrysan Tung
Product Designer @ Weight Watchers | I like design that is compassionate, research-centered, and tells a good story. | chrysan.j.tung@gmail.com | chrysantung.com
