How to Tackle a Design Interview Challenge

A framework I’ve used for a variety of design exercises

Chrysan Tung
Jun 2, 2017 · 11 min read
Image for post
Image for post

A Bit of Background

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

Think about who are the various types of users and the use-cases for who you are designing for.

My Approach

  1. Context: Problem/Goal, Constraints/Assumptions
  2. Understanding Users: Guerrilla User Research, Competitive Review
  3. Setting the Stage: Requirements, User Flow, Brainstorm
  4. Design: Wireframes, Interactions, Feedback Iterations
  5. Final considerations: Edge cases, Next Steps, Last Thoughts

And with that, let’s begin!

Problem/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.

Constraints/Technology

Assumptions

  1. 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.
  2. 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.
  3. 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

Image for post
Image for post

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.”

Image for post
Image for post

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.”

Image for post
Image for post

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.”

Image for post
Image for post

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

Image for post
Image for post
Starwood, Trivago, TripAdvisor, Airbnb, Kayak

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

Image for post
Image for post

Brainstorm

Image for post
Image for post
Separate View (Scrolling) Calendar
  • 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.
Image for post
Image for post
Accessible (Paging ) Calendar
  • 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

Image for post
Image for post
Initial Wireframes

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

Image for post
Image for post
Paging Calendar

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

Image for post
Image for post
Tuck Away Calendar

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

Image for post
Image for post

Scrolling Search Results

Image for post
Image for post
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

Image for post
Image for post
Tuck Away Calendar Interaction

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

Image for post
Image for post
Paging the Calendar

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

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:

  1. 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.
  2. 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?
  3. 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

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

Tradecraft

Stories about startups, technology, traction, and design…

Thanks to Debra Teo

Chrysan Tung

Written by

Product Designer @ Lyft. Previously @ WW, Weight Watchers Reimagined. — San Francisco, CA

Tradecraft

Stories about startups, technology, traction, and design from Tradecraft members

Chrysan Tung

Written by

Product Designer @ Lyft. Previously @ WW, Weight Watchers Reimagined. — San Francisco, CA

Tradecraft

Stories about startups, technology, traction, and design from Tradecraft members

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store