Khalid Al-Jaaidi — Product and design. based in Amsterdam, Netherlands

Destination Filter - Careem

Case study

Destination filter is a Captain app (drivers app) feature that allows Captains to select where they want to go, and match them with trips that are going in the same direction. This allows the Captains the flexibility of doing more trips when they would have otherwise driven on their personal time.

ForCareem RoleUX Design, Sprint facilitator
DateNovember 2017


Where do you want to go?

A question directed to Careem customers whenever they are booking a ride on the Careem app. However, it isn’t just consumers who want to go somewhere, there’s another consumer – A Captain that wants to go somewhere specific as well.

Captains had a need, and I’ll go through the process that I took with the team to build a way for Captains to select where they want to go and get matched with trips that are heading the same way. This allows Captains the opportunity to earn more when they would otherwise be driving on their personal time and expense.

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of Careem.

Where are you going, Captain?


When captains want to end their shift and go back home or need to go somewhere at a certain time, we don’t provide a solution for captains to get rides towards that destination. Captain end up either waiting for a booking and hoping it will take them to where they need to go which is probably unlikely and they end up somewhere else, or they offline on the platform because they don’t want to take the risk of ending up elsewhere, hence reducing supply available hours.

We want to provide a solution for captains to make Careem the preferred platform when they need to transport themselves to a certain area, and enable them additional earnings from receiving trips that are on the way to their desired destination.

In summary:

• Captains go offline when they want to go somewhere specific.
• Customers see higher time to arrivals.
• Careem loses the potential of trips and Captain availability.

Design Sprint – Challenge to concept validation in 4 days

With the challenge in hand, I led a design sprint with the cross-functional team, comprised of engineering, product, UX design and UX writer.

The Design Sprint approach over 4 days

Understanding and alignment

Long term goal, sprint questions, and a simple map

Long term goal

We began by exploring the challenge in-depth, reviewing the data we already had from past trips and Captain behaviour, and proceeded to write our long term goal, and themain questions or risks that we wanted to answer by the end of the sprint.

Our goal was:

Bringing flexibility to Captains work-life balance.

Creating a simple overall map

Next, we created a simple map consisting of the players involved in this story, in our case a customer, and a captain, and what’s necessary from both parties and where do they intersect, giving us all a quick glance at the process.

Identifying areas of opportunities

Next we voted on our biggest areas of opportunities that we collectively thought were the most impactful, through the "How Might We" notes we've been collecting throughout the sprint.

Top “How Might We” notes with votes

Diverge: 4-Step process to solutions

At this point, armed with a long term goal, a clear set of questions and risks that we will try to answer in our solutions, a direction in terms of where we can get the most impact, we were ready to start exploring solutions.

Work together, alone

One of the many ways we avoid bias, specially when working with a large group of people and avoiding ‘designing by committee’, is that we actually produce the first set of solutions individually.

Crazy 8 sketches

Crazy 8 sketches

Decide: Quality of solutions over quality of aesthetics

Once we have our individual concepts we proceeded to critique the solutions, ask questions and engage each solution one by one focusing on quality of solutions over aesthetics. After which we moved to deciding on the best parts by voting on ideas of entire concepts with the sticker dots.

Individual solutions, with votes

User test flow and storyboard

At this point, the concept direction begins to take shape, and we have our best ideas that we want to double down on. We proceed to creating a storyboard of what we will test. Here we began exploring how the final solution would come together, combining the best aspects of the ideas conceptualized earlier.


A prototype in a day

If you can fake it, you can test it

The day after the conceptualization process on the design sprint, is the prototyping day. Here we focused on time-boxing and prototyping our solution quickly, some of the reasons behind that, is to quickly answer your biggest questions and risk that were identified on the first sprint day, and also to avoid getting too attached to a solution too soon.

Since we were planning on user-testing the day after, the user test interview script was also being prepared, and the Captains were being booked and called in for their test slot.

First user testing version

User testing

Once we had our first prototype, we took it to a user test. In our case we decided to test in KSA, Riyadh due to market dynamics we identified when we started the project. I also designed and prepared the prototype in Arabic.

Remote user testing session in KSA

Iteration and final design

Based on the user test, we saw what worked, what didn’t, but most of all, we managed to answer our biggest questions in just a week, starting from the challenge.

We ended up simplifying a few things, removing unnecessary features that Captains didn’t find useful, fixed a few usability issues, and proceeded to create the final version. We tested the one more time with the final version and handed it over for development.

Final design


The introduction of a way for Captains to get matched with trips headed the same way they are, opened up the opportunities for Captains to be more flexible in those specific moments of their day. Whether they are going to work in the morning and earning a trip on the way during rush hours, or going home after a long day or doing errands over the weekend.

Some of the metrics affected that we’ve been monitoring:

• Captains were spending additional time available for trips on the platform, an average of 3.2 hours.

• The average estimated time to arrival to customers was 19% faster.

• The feature was used at least once a week by 77% of the Captains.

For confidentiality reasons, I have omitted the actual values for these metrics.