Design Sprint

13 November 2016

The Problems

During early October, my colleague went to a mobile usability course and in that course they demoed a usability test on Traveloka mobile app. He told me one of the task of the demo test is to book a round trip flight and a hotel on the app. It turns out that the current Traveloka app don’t have the capability to buy flight and hotel in the same checkout flow (or even if it’s possible it’s not obvious enough).

So in the current mobile app, user would have to input similar data, to book a hotel and flight in the app. Making frictions in the (ideally frictionless) booking process.

According to Google’s research, 54% of leisure travelers and 69% of business travelers say that mobile limitations or mobile usability are their main reasons for booking on another device.

But not only do Traveloka face travelers switching devices, Traveloka also risk losing customers to competitors. Because 88% of travelers with smartphones would switch to another site or app if an app doesn’t satisfy their needs

The Goal

Make it faster and more efficient for people to book flight and hotel on Traveloka Mobile App.

The goal of the improvement is to make it faster and more efficient for user to book flight and hotel on Traveloka’s mobile app

What I did

On 22 October 2016 I got the opportunity to attend a Design Sprint workshop from Borrys Hassian in Bandung. During the workshop I worked with 3 other people as my team member. Because I’ve already had some prior experience doing a Design Sprint in my company, I volunteered as a facilitator of the team.

So when on the Design Sprint workshop I suggested to do the sprint on Traveloka’s app, solving that problem.

What’s a design sprint? Jake Knapp from Google Ventures describes their design sprints:

Since we want to move fast and they want to move fast, we’ve optimized a process that gets us predictably good results in five days or less. We call it a product design sprint, and it’s great for getting unstuck or accelerating projects that are already in motion.

(Each phase name links to the original Google Ventures post.)

  1. Understand: Existing solutions and a user story.
  2. Diverge: Sketch. Sketch. Sketch. Crazy 8s and 3-panel storyboards.
  3. Decide: More sketching. User flows and detailed storyboards.
  4. Prototype: Build.
  5. Validate: What worked? How can we improve?

Day 1: Understand


Before we start, I prompted my team to list problems and assumptions that can be found in the app’s current state, we then turn those problems into question, turning negativity into curiosity:

  • How might we associate the Traveloka brand with Hotel? (not just flight)
  • How might we convince people buy both Flight and Hotel in Traveloka?
  • How might we convince people to book Hotel in Traveloka?
  • How might we convince people that Traveloka’s price is the cheapest?

User Journey Map

We then map the user’s journey when he/she is trying to book a flight and then hotel on the mobile app.

Traveloka's current user journey

Traveloka's current user journey

As you can see there’s some inefficiency in this journey. To book both flight and hotel, users would have to put these same data twice:

User needs to input similar information twice

User needs to input similar information twice

  • Destination
  • Departure & Check In Date
  • Return & Check Out Date
  • Total Passenger & Total Guest

Success Metric

Checkout speed for people that buy both flight and hotel on Traveloka’s mobile app to be decreased by 50%.

Day 2: Diverge

Lightning Demo

One exercise Google Ventures recommends is the lightning demo—a quick look at existing solutions. We can learn so much from this step because someone else has likely designed solutions to the same problems.




One of the team members suggested AirBnB with it’s focus on images to inspire and pull users to book.




Another team member suggested the app PegiPegi with its big and touch friendly user interface for inputting the flight search query.

Cheap Flight

Cheap Flight

Cheap Flight

The last team member suggested CheapFlight for a similar to PegiPegi, where the UI is big and uses the whole screen.

Crazy 8s

Crazy 8s is a fast-paced exercise. Each person takes his or her strongest ideas and rapidly sketches eight variations in eight minutes. Crazy 8s forces us to push past our first reasonable solutions and make them better, or at least consider alternatives. Each person begins Crazy 8s with a single sheet of letter-size paper. Fold the paper in half three times, so we had eight panels. We sketch an idea in 60 seconds then sketch another in 60 seconds until 8 ideas are sketched. A lot of the end results aren’t useful but it helps break through plateaus in creativity. Crazy 8s leads to a lot of ideas, not all of them good. But a little while after finishing there’s usually something useful that comes to mind. For whatever reason, iterating rapidly kicks off the right back burners for creativity. Here are me and my team’s sketches. As you can see, there’s a lot of good idea laying around.

Crazy 8s

Crazy 8s

Solution Sketch

The solution sketch is each person’s best idea, put down on paper in detail. Each one is an opinionated hypothesis for how to solve the challenge at hand.

Each sketch is a three to four panel storyboard (although there are exceptions) drawn on sticky notes , showing what your customers see as they interact with your product or service. Jake Knapp prefer this storyboard format because products and services are more like movies than snapshots. Customers don’t just appear in one freeze frame and then disappear in the next. Instead, they move through our solution like actors in a scene. Our solution has to move right along with them.

Solution Sketch 1
Solution Sketch 2
Solution Sketch 3
Solution Sketch 4

Day 3: Decide


Ideally, the sketches should remain anonymous with the person making the solution sketch not having any say about the sketch until the very end. This is done to make sure the best ideas win not the best presented. But because of the time limitation of the workshop, I opted to let everyone explain their sketches in their own words.

While the creator was explaining their sketch, as a facilitator I wrote down key points in the sketch on sticky notes.

Then everyone were given a different colored pen and were asked to vote silently by adding stars on the part that they like. Each member of the team got to have 3 votes.

Combining Ideas

After we voted, there are 3 sketches with votes and 1 sketch with no vote. Since the ideas are compatible with one another we decided to combine these sketches rather than pit them against one another.

Flight & Hotel

Based on the vote, we decided to make a new CTA in the homepage called “Flight & Hotel”.

Step-by-step header UI

Add a new steps header with the sequence of: Departure Flight > Hotel > Return Flight with a step-by-step header UI

Hotel Map UI

And also to display the hotels on a map view by default, showing hotels nearest from the airport.

The Design Sprint is great for testing risky ideas like the Departure > Hotel > Return sequence and showing map view of hotels by default. By the end of the testing phase, we’ll be able to see whether those ideas are good.

Detailed Storyboard

We then created the detailed storyboard to plan the prototype. Because if we start prototyping without a plan, we’ll get bogged down by small, unanswered questions. Pieces won’t fit together, and our prototype could fall apart.

Our prototype storyboard

We started at the home screen, finishing on the payment screen. This is the last activity me and my team did on the design sprint workshop.

Day 4: Prototype

After the workshop I continue to work on the sprint myself. I used Sketch and Invision for rapid prototyping. Recreated the sketch using bits of screenshot from Traveloka’s mobile app. I finished the prototype in about 2-3 hours in Sketch.

Day 5: Validate

Today, we test our prototype and learn which ideas worked, which didn’t, and what to do next. The exciting day, testing. While the success metric of this design is speed, it is quite hard to do a quantitative guerilla usability testing by myself for multitude of reason (e.g. time, participant, etc.). Thus I opted to do qualitative test by asking the tester to think out loud while using the prototype.

I asked the help of my friends and family who are frequent business travelers that have previously bought flight ticket and hotel booking online.

First iteration

First iteration

Second iteration

Second iteration

After 2 tester I found out that the sequence Departure>Hotel>Return is confusing to users, they both said that it’s quite different from their mental model of booking flights and hotel. So before I tested the 3rd participants I changed the sequence to Departure>Return>Hotel.

The result is immediate, the 3rd and 4th participant didn’t have any problem choosing their flights. But there’s still a problem. If you remember we also tried to take risk by showing the Hotel in a map view by default, with a toggle to switch to list view. This confuses users too.

One tester said that the UI remind him of Uber rather than a hotel booking, and it threw him off for a second. Another participant said that the proximity of the hotel from the airport is not that important for business travelers, where they might prefer a hotel closer to their client/meeting rather than the airport.

So for the 5th participant, I tweaked the prototype again to show the Hotel as a list view by default with a toggle to switch to map view.

Third iteration

Third iteration

By the 6th and 7th test, there were no glaring problem anymore and I concluded my testing for the day.

I also found an interesting trend during my testing. I asked the tester how disappointed they would be if this feature is not implemented (basically asking “would you use this” with less biased question) and it turns out that people don’t really care much because the don’t really see Traveloka as a place to book hotels. They usually buy hotels from Agoda, and aren’t sure that Traveloka have the cheapest price. So Traveloka’s image on hotels can still be researched and refined further.


It’s been a great fun learning about Design Sprint by making a real improvement on Traveloka’s mobile app. Given bigger resource I’d really like to do more than guerilla user testing and do controlled quantitative test to measure the speed and efficiency of this design.

Some of my tester suggested some good ideas like the ability to book multiple hotels in a single checkout flow, but the it still need more validation on whether or not this idea is really solving a real problem (though I suspect it is a real problem, and should at least be made into a design sprint).

*I don’t work for or am affiliated with Traveloka