uber design case study

You are using an outdated browser. Please upgrade your browser to improve your experience.

Simon Pan is a Product Designer based in Brooklyn, NY

Perfecting the Pickup

In 2012, tapping a button to Uber across the city felt magical. By the start of 2016, this magic receded to a slew of disparate features that made the experience slow and complex to use.

I was part of an ambitious project to redesign the Uber pickup experience for the fastest growing startup in history.

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

Design by accretion

In just five years since 2011, Uber transformed from a black car service for 100 friends in San Francisco to a global transportation network. By 2016, Uber delivered over 3 million rides a day in over 400 cities across 70 countries.

The Rider app — designed in 2012, struggled to scale alongside the hyper-growth of the company. Fundamental usability was challenged. Disparate features and experiments competed for focus. App reliability and performance issues increased exponentially.

The Rider app had become the org chart.

The Challenge

Recapture the magic in 10 months.

Our goal for the project was to recapture the magic of the early days of Uber. The original premise was simple: tap a button, get a ride. However, we weren't trying to revert to a simple past. Our ambitions were to create a strong foundation that embraced a rapidly evolving business and more diverse user base.

Our high level goals were to:

• Make it fast and easy to use for everyone, everywhere.
• Give riders more control over their time and money.
• Create a platform for innovation and deeper engagement.

I led the design of the pickup experience between October 2015 and June 2016 and collaborated with two other designers on the Home screen, Search and On Trip features.

In addition, I worked alongside a Researcher, Prototyper, Content Strategist and 2 Product Managers.

I stopped working on the project during the detailed visual design phase as the app started to be built.

The app launched globally on November 2nd, 2016.

Picking up the pieces

At the outset of the project we didn’t have a clear mission or specific goals for the pickup experience. Without pre-existing insights, I partnered with our researcher Shruti to explore how Riders were getting around.

Early Insights from the Field

We tested the existing Uber app with 8 participants in the most problematic pickup areas in San Francisco. Our goals were to understand the challenges Riders and Drivers faced and the workarounds they employed.

Frequent contact to confirm or coordinate location

Riders were annoyed when they were contacted by their Driver to confirm the location. Riders expected Uber to do the work and didn't feel the need to reiterate.

Suboptimal routes given to Driver

Riders were frustrated with the specific routes that the Driver used in getting to their pickup location. Riders expected Uber routing to be smarter.

Unexpected arrival location

Often, Drivers did not arrive where the Rider expected. Riders would need to cross the road, backtrack on the block or negotiate an alternative pickup location.

Pin setters and button mashers

Riders behave in two distinct ways. Those who explicitly set a pickup location (via search or pin) and those that expected the Driver to arrive at their current location.

The Discovery

Rider expectations changed over time.

I was surprised by the issues we found. They felt like privileged San Francisco annoyances, rather than major problems faced by our global audience. But after some thinking, it became clearer that Riders expected the experience to just work with minimal effort. As Uber became more integral to their lives, their expectations evolved.

“Curiosity revealed an opportunity to perfect the pickup experience for everyone, everywhere.”

If power users with great reception, powerful phones and tech literacy were having trouble in our most mature marketplace, how bad was the pickup experience in our immature marketplaces with more challenging technological and environmental contexts? Curiosity revealed an opportunity to perfect the pickup experience for everyone, everywhere. This was the beginnings of a working north star.

Deeper Insights

Working backwards from perfect.

Before I could jump into designing, it was important to define success and understand the health of the pickup experience at scale.

Prior to the redesign, contact rate i.e the rate at which a phone call occurs during the pickup was the only proxy we had used to measure pickup quality.

I unpacked the concept of the perfect pickup and modeled for the dimensions of time, space and anxiety.

I partnered with our data scientist and used this framework to investigate the pickup health around the world.

Most pickups require additional physical or coordination effort

Digging into the data revealed some big insights into the pickup experience. Almost all trips involved some extra coordination effort such as a phone call to clarify the location and additional physical effort such as walking somewhere else to meet the driver, or the driver re-circling the block. This data showed that the experience was hardly the door-to-door magic Uber had been optimized for.

“In a city as busy as San Francisco, over $1 million was wasted per week because of problematic pickups.”

The time and energy spent recovering during problematic pickup situations was having a material impact on the business bottom line. Waiting time translates directly into network under-utilization and every phone call costs to anonymize.

In a city like San Francisco, over $1 million was wasted per week because of problematic pickups. Cities like Guangzhou and New Delhi were much worse.

I have intentionally omitted confidential data here.

No pickup specified

A large majority of Riders don’t explicitly set their pickup location. They rely on the default device location of the app. Half of all sessions are at least 100m inaccurate.

Requested location is often not the pickup

Only a small percentage of trips start within 20m of requested location. Where the Driver is sent and where the Rider is actually picked up is mismatched.

GPS updates ignored

A large number of sessions have an improved GPS accuracy by the time of request. Many of these sessions improve over 1000m in accuracy.

Some pickups just don’t make sense

Many trips are requested from within buildings. This can result in different pickup locations, depending on the operating system of the Driver.

Reframing the Problem

Poorly formed rendezvous plans cause downstream pickup problems.

The Rider app exacerbates the formation of problematic pickup plans between Riders and Drivers. Problematic pickup plans consist of inaccurate locations, ambiguous information and inefficient routes which causes confusion. Ancillary communication and additional physical effort is required from Riders and Drivers to recover, which leads to frustration and wasted time.

“...how might we help Riders and Drivers form a better pickup plan?”

This begged the question, how might we help Riders and Drivers form a better pickup plan? Our proposal was Rendezvous , a pickup plan created on behalf of Riders and Drivers.

The Pickup Redesign

Introducing rendezvous.

In an age where everything is demanding your time, Uber gives your time back by making pickups fast, effortless and calm. Uber makes sensible decisions for you erring on the side of protection— informing you in ways that are understandable and actionable.

Just request and we do the rest

Uber finds you the optimal meeting place based on who you are, where you are and where you’re going. Uber saves you time without you needing to select a pickup.

People-friendly walking instructions help you better understand and identify your meeting spot. No more nonsensical addresses.

Always Moving forward and faster

Sometimes there’s a faster way, that requires walking. Uber understands these situations and gives you an option to save time.

We've got your back

When Uber isn’t sure about your current location, you’ll be prompted to help. Over time Uber will learn more about you and your city, so your Ride will always start in the right place.

Flexibility and the final say

Sometimes your situation requires precise control over where to get picked up. Uber gives you complete control when you need it.

How we got there

Perfect the pickup for everyone, everywhere.

Three primary questions informed my design strategy:

• How do you design for everyone, everywhere?
• What contexts need to be considered?
• What’s the perfect pickup?

Early on, it was important to understand the different factors that may influence the Rider and Driver experience. I mapped all the possible concepts and translated this into the spectrums and situations framework.

A more inclusive design

The existing Uber app was poorly designed for users who weren’t reflections of people that work in the San Francisco Uber office. To move beyond the existing biases, I tried to educate the team with an approach to designing for everyone, everywhere.

The spectrums attempt to highlight the range of temporary or permanent challenges to consider when a person is interacting with Uber.

The situations attempt to highlight situational challenges that everyone experiences. A situation is a temporary context that affects the way any person interacts with Uber for a short time.

“Historically, Uber poorly empathised for users who weren’t reflections of people that work in the SF office.”

This framing was used to destroy any stereotypes that the team had about people and marketplaces. The goal was to create design solutions that scale and extend to any combination of these contexts from the outset.

Degradation to adaptation

I created this additional hierarchy of needs framework to reframe our conversations about quality and features.

Instead of starting with a San Francisco-centric design and degrading for what the team deemed as the other challenging marketplaces we needed to start with a minimum bar of quality to enable rides for people in all contexts.

The framework helped shift from unproductive questions like “How is this going to degrade for Nairobi?” to “How might we enable a destination first design for cities without a traditional addressing system?”

Working Backwards from Perfect

I reversed the polarity of the imperfect pickup to jumpstart creativity. Four key design challenges emerged:

• How might we better understand where the Rider is?
• How might we form a pickup plan that minimizes effort and saves time?
• How might we remove the need for a map entirely?
• How might we better adapt to the dynamic nature of cities and human mistakes?

From Inaccurate to Precise

Better understanding where the rider is.

A major reason problematic pickups occurred were because getting an Uber relied heavily on the Rider explicitly setting a precise pickup location to meet. Not doing so, causes the Driver to be sent to the default device location, which half the time is wildly inaccurate.

Our data revealed that:

• 50% of Riders globally don't explicitly set a pickup location.
• Half of all sessions are at least 100m inaccurate.
• 45% of sessions have an improved GPS accuracy by the time of request. We do nothing with this information.

Based on these insights, I proposed two key feature ideas Destination First and Live Locations to help better understand where the Rider is. Central to the features, were these key ideas:

• Stop relying on the Rider setting their pickup location. Do the heavy lifting on behalf of the Rider.
• Carve out more time for the GPS to warm up.
• Capitalize on GPS updates for as long as possible.

Starting at the end

In order to optimize the pickup experience, there was only one thing we needed to know—the Rider's destination.

Without much debate, the team agreed that asking “Where to?” upon app launch matched the mental model of the Rider. It was also useful in unlocking more advantages, such as providing the user with upfront fares, estimated arrival times and allowing more time for the device GPS to warm up to aid the pickup experience.

To compensate for the new speed bump, I designed the accelerators feature—a predictive set of shortcuts that gives the Rider 1-tap access to their most likely destinations at any given time.

De-risking the new flow

We feared that the new destination first experience would cause issues because it was more friction and a fundamentally different flow.

In order to de-risk some of our assumptions, we travelled to Bangalore, Delhi, Ahmedabad, Guangzhou and Shanghai to test an early prototype of the designs.

To our surprise, not a single participant noticed the different sequencing of the flow or had trouble with it. The destination accelerators resonated well with participants, confirming our intuition around designing for speed.

Live Locations

Live locations feature was born by questioning whether we needed to default to any pickup location at all.

Rather than lock on the Rider's location upon app launch (which roughly 12-15 seconds for an accurate fix), the app continues sensing, asynchronously updating as the GPS updates. The most accurate GPS location is obtained at the last possible moment—at the time of request.

This required a big design shift for the posture of the experience. The challenge was shifting from set your pickup to where and how do you want to go?

Inspiring confidence on the confirmation screen

If the new experience was to do the heavy lifting on behalf of the Rider, the confirmation screen needed to inspire confidence and show how the pickup experience was being taken care of.

A key design challenge was to consider how much emphasis should be given to this always sensing state.

The riskier design decisions I made was to obfuscate the pickup location entirely during the core app flow. The idea was to present the overview of the trip to persuade Riders to focus on selecting how they wanted to get there, rather on where to get picked up— since Uber would take care of that.

This meant the UI needed to inspire confidence for the majority, and those who wanted to assert control needed to know how to discover the feature. It also meant that when we couldn’t optimize on the users behalf, we needed to occasionally ask the user for help.

Over-designing for anxiety

The goal of these designs were to reveal the accuracy of the GPS location as it resolved. I assumed that transparency was the key to building Rider trust. After testing many iterations of this experience, we repeatedly observed that:

• Ambiguity and resolution concepts were mostly missed.
• Riders assumed that the app knew their current location and didn’t actively look to confirm.

Riders were not anxious or thinking about the GPS accuracy at all. My anxiety, further compounded by stakeholder feedback was being reflected in my designs. The GPS dot and location tooltips were loaded with this anxiety and I felt like I had exhausted all possibilities.

After the third round of poor testing, I killed the idea in favor of a more simplified and balanced interface that reflected what Riders were focussed on.

From Inefficient to Optimized / Immutable to Fluid

Giving riders and drivers back their time.

Knowing the Rider’s destination and the most accurate understanding of their location allowed us to do the heavy lifting and select the most optimal pickup location. The system needed to be smart enough to just work when it could, and humble enough to intervene when it couldn't. This system called adaptation was by far the most complex problem of this project.

Foundational to the adaptation framework were these concepts:

• A confidence score would determine whether to choose a spot on behalf of the user, or to disambiguate their location. How we calculated this confidence score would be an ongoing project to improve.
• We needed to respect Rider control and agency. Design patterns needed to allow for opting in, opting out or taking complete control.
• The system needed to be flexible enough to learn about Rider willingness. Don't design based on the assumption we will know the right answer.

Intelligent pickups

Making trips efficient required that we move beyond dispatching the closest car, to dispatching the most optimal* car. This presented several design challenges:

• Getting the Rider to walk to a nearby pickup location.
• Creating heuristics to decide the optimal spot.
• Adapting when we don’t know where the Rider is.
• Balancing smart defaults with choice and control.

*Optimal refers to the car with the fastest route to destination based on a set of nearby candidate pickup locations

Adaptation - a flexible architecture

I designed the flow based on the idea of a location confidence score. If Uber is confident of the Rider's location, it does all the heavy lifting. Otherwise, the app prompts the Rider to validate their location.

Instead of designing for the right answer, I designed a flexible system optimized for learning and optionality.

From Ambiguous to Obvious

Communicating location in a more intuitive way.

A critical part of the rendezvous experience is that Riders and Drivers have a clear understanding of where to meet and how to get there. The existing Uber app didn’t do a good job of supporting wayfinding, relying mostly on street addresses and the map.

During our research trip in India, we observed many wayfinding challenges. Limited street signage, intense traffic on the roads and sidewalks and poor GPS accuracy meant that the Riders and Drivers used POIs to coordinate their pickup location (in spite of what was formed in the app).

We found that there were structural patterns inherent in their communication, which inspired the Geotalker feature.

Geotalker is a place description framework that mirrors how the human mind organizes spatial knowledge. It works by using a set of heuristics to translate a reverse geocoded street address into a place description phrase to support wayfinding, spatial awareness and communication.

I started out by creating a concept model for wayfinding and spatial cognition. The exercise helped me come up with the idea that features of the urban environment could have different levels of salience, depending on the point of view of the Rider or Driver.

The larger vision was to create a system where place description leveraged the POI with the highest level of salience, based primarily on heading direction and other factors. The system would test different labels and self-optimize based on the quality of the pickup experience.

However, given the speculative nature of the idea and reliance on a quality location data set, we decided to experiment with a less intelligent version in the existing app.

Geotalker reduced ambiguity in the pickup experience

Early experiments resulted in significant decreases in the distance between pickup request location and actual pickup location and contact rate. We concluded that Geotalker helped to reduce ambiguity of the pickup location.

This was enough signal necessary to launch the idea in the redesign.

The Most Radical Update Since 2012

In the 5 months after my involvement on the project, the team continued to evolve and polish the visual design, as well as finesse the finer functional details as the app was being built. Although I was not part of this process, it was great to see most of my work brought to life.

On November 2nd, 2016 the new Rider app launched globally—an impressive achievement by the team, considering that it was a complete redesign and rebuild from scratch.

Positive results and much more to do

The redesign of the Uber Rider app on iOS and Android has had a positive impact on the pickup experience, at the time of writing (3 months since launch). However, contact rate has not been significantly decreased which means Riders and Drivers continue to contact each other to confirm or coordinate pickup details. I believe this to be a behavior change that will reveal over a longer period of time.

The error distance between requested pickup location and actual pickup location decreased by 34%

Driver wait-time decreased by 20%, high-precision pickup rates increased by 17%, multi-contact rate decreased by 3%.

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

Was this case study helpful?

Feel free to show your support by buying me a coffee.

Uber: Evaluative case study

Nishtha Jain

Assessing Uber’s ride-booking process for users who have a pending payment.

Note: This is a hypothetical situation and solution for a UX challenge

Okay, patience, buckle up your seats and let me drive you through my journey for the next few minutes.

Our goal was to evaluate the micro-flow of an app and create solution(s) to the problems discovered using the evaluative design thinking process within 48 hours (Trust me, 48 hours can also feel like 48 mins sometimes)

Uber users who want to book a new ride but haven’t paid for the last trip are given the payment reminder for the previous trip after they have completed 90% of the new ride booking flow. After completing payment, they are taken to the home page to book a ride again.

I had to divide my time wisely, so I started by setting priorities and listing the work for the case study. I split my time into four parts, analyzing situations and creating hypotheses, validating assumptions with secondary and some primary research, followed by ideating possible scenarios with solutions, and then creating the designs.

Plan of Action

Here’s my to-do list for the two days of this challenge.

• Understanding Flow
• Observing problem(s) with heuristic evaluation
• Ideating and building hypotheses
• Secondary and Primary research
• Validating the assumptions
• Define and Ideate
• Wireframing
• Mockup design and prototyping
• Usability Testing

Understanding the background

Let’s break down what we understand from the given statement.

• Analyze user behavior while booking a new ride.
• The user here is someone who is unable to complete or chose not to complete payment after the ride.
• The focus here is to increase the efficiency of app users for a particular edge case and the conversion rate.

I marked the flow that Uber users would follow for our use case and identified problems the user would face.

Heuristic Evaluation

I evaluated each screen as per the heuristic principles shared by Neilsen Norman Group to find usability issues and problems with current screens.

• In some cases, users need to remember the outstanding payment. When the app is reopened, the pending amount is not displayed on the home page , leaving the user unaware of the pending payment status.
• The absence of information about pending payments on the home screen forces users to recall it, which is only displayed two screens away from the home page (in previous trips and wallet) .
• Users on the ride options page are unaware of the pending payment and are only told how much money they will spend on the current booking .
• Users are taken to a pending payment page at the end of their ride search, which cannot be avoided in order to book a new one; this is not what the user expected.
• Users are taken to a pending payment page at the end of their ride search, which cannot be avoided to book a new one, leaving them with no choice.
• Following payment completion, users are redirected to the home page rather than the booking progress of the current trip, requiring the user to re-enter the information .

I came up with ideas and hypotheses for each screen and microflow after iterating on the problems.

• We believe that having a payment option on the home page will result in less confusion and easier navigation to the previous payment page.
• We believe that having a reminder for previous payment will help riders choose to pay for the previous ride.
• If we display wallet status (negative in this case) , it will help users navigate to the wallet of their account to pay easily.
• We believe that displaying the amount (on the third screen) to be paid will remind riders of their pending payment.
• If we show the riders a total of the current and previous amounts , they may gain an understanding of the pending payment as well.
• We believe that having a pay now option along with the amount (on the 3rd screen) will result in less confusion and easier navigation to the previous payment page.
• If the page includes a friendly message in the event of a previous payment failure , rider retention will improve.
• We believe that providing an option to pay along with the current booking might improve the flow for the users.
• We believe that saving the current booking as a draft for users to resume after payment will save the rider’s time and energy.

To get to the validation of my hypothesis I had to do some secondary research and primary research.

Insights from Secondary Research

• To gain users’ trust, it is good design practice to include elements of trust and faith in screens .
• Uber has published multiple articles emphasizing the importance of sending reminders to the user for better engagement.

Competitor Flow Analysis and Insights

• Ola does not allow users to have pending payments ; instead, when paying online, Ola requires the rider to pay within the time slot of the ride. If you fail, Ola will need you to pay the driver in cash.
• OLA has an option of OLA postpaid /OLA credit, which allows a credit of up to ₹25,000 to anyone who has set up a postpaid account with OLA.
• It takes longer to search for rides.
• Doesn’t have cab options. Have bikes and autos.
• The driver doesn’t end the trip until the payment status is complete.

Insights from Primary Research

For primary research, I got on a call with a few people to understand their behavior and aspirations around cab service and Uber in particular. Below are some of the questions and insights.

Validating hypothesis

After collecting data from primary and secondary sources, I checked whether my hypotheses stood true or not.

Greens: Validated

Red: Not validated or partially validated

Next, I brainstormed possible solutions by formulating ‘how might we’ statements and finding outcomes for each.

Next, I created a solution outline within the flow structure with the least number of changes possible that can be implemented in a short period of time but impactful enough to ensure an increase in the flow efficiency of our edge case.

Implementation

Firstly, I made quick paper wireframes.

Then, I used the flow of my edge case to determine whether the solutions needed to be implemented on each screen or if they could be worked out with the fewest changes.

This gave me reinforcement to go ahead with the solutions I had listed.

Low-fidelity wireframes

Hi-fidelity screens.

Changes: Search Sorting: Users can sort their search results and search for the most recent locations entered giving them access to the progress they made in booking a ride. Recent trip: Users will not get reminded of any pending payment at the home page itself and can also switch to the payment page from here.

Ride option page

Change: Payment bar: If skipped at the home screen, users can pay before proceeding with the current booking via the pay now CTA for user redressal, which also includes the amount.

Payment page

Change: Friendly message: The user at this point must be in a rush and providing empathy at this stage can be vital for customer retention.

Home page (after completing payment while booking the current trip)

Change: Sort option: As we talked about above, at this stage, the sort option can help the user access the previously entered locations to book the current ride.

How to measure success

• How many users pay at the home screen itself?
• How many users ignore the sorting option on the home page?
• How many users pay on the ride option page?
• How many users select the ‘account>wallet>pay now option’ to pay?

That’s all, Folks!

Feedback is highly appreciated!

Written by Nishtha Jain

Product designer

Text to speech

Get inspired by design stories

Monthly UX and product design case studies. Trusted by designers from companies like Apple, Google and Spotify. It's 100% free.

Uber Case Study Roundup: Driving UX Design Forward

UX has always been an essential part of Uber's design practice, as you will see in this case study roundup.

They've had their ups and downs, especially with the failed 2016 rebrand. Not to mention their internal struggle causing ripple effects, ultimately ending up loosing peoples trust.

Frances Frei was hired to work on the internal culture and to rebuild peoples trust . The next natural step was a rebrand, with the help of Wolff Olins.

It takes time to rebuild trust, and only time will tell if they've succeeded. The user experience certainly feels more complete and they've set them selves up for a bright future.

Weekly UX and product design case studies. Trusted by designers from companies like Apple, Google and Spotify. It's 100% free.

6 In-depth UX design case studies bbout Uber

6 in-depth ux design case studies about uber.

Uber Trip Sharing

Shuli Liu goes into detail about the process of designing the sharing feature in the Uber app. Be sure to check out all of the case studies in her portfolio. Inspiring work!

Read Case Study→

Uber Rebrand 2018

The Uber Brand Experience team presents the new rebrand in great detail. They got a few solid partners on board this time; Wolff Olins (Brand Agency) and Jeremy Mickel (Type Designer).

Under the Hood

Ueno presents their process of designing uber.design. This case study is based on the old brand but has later been revamped using the new rebrand.

Perfecting the Pickup

Complex design jobs require in-depth case studies. Simon Pan is a skilled storyteller and will make you want to keep on reading. He ends everything with how his design improved a various aspect of the experience, backed up with actual data.

Research on the Road

As close to as a "fly on the wall" as you could get. Uber researchers share their process of how they collect their data so that they can make better and informed decisions.

How Uber Design Growth

In recent years, designing for growth has turned into a new field. Growth designers balance both business and user experience. The growth team at Uber share their story starting out with just a few people to scaling up to over 300 people.

More from the journal

Adapting an outcome-centric mindset

Stop Trying to Fit in With Your Portfolio

Case Study Talk

Uber Brand Case Study

A tech startup turned global mobility platform in eight short years deserves a holistic brand system that’s instantly recognizable, works around the world, and is efficient to execute. Here’s a case study looking at the 2018 Uber rebrand.

About Uber Brand Case Study

• Category : Web Design
• Colors : Color Code #eeeeee Color Code #444422 Color Code #888844 Color Code #222222 Color Code #66cccc Color Code #cccccc Color Code #aaaaaa Color Code #000000
• ← Pesce
• Fully Studios →

Uber Design Case study

Earlier this year we worked closely with the Uber design team to put together a new Uber.design website. Here is a case study done for the latest uber app. More to come!

Also, we're hiring in Iceland, San Francisco and New York: ueno.co/careers

• For designers
• Hire talent
• Inspiration
• Advertising
• © 2024 Dribbble
• Freelancers

DesignPlayStore’s Newsletter

Uber Eats and Design Thinking

Creating the future of food delivery through design thinking.

The design team at UberEats is constantly accessing design thinking principles to fuse modern, state-of-art technology with the antiquated and fundamental act of enjoying a meal.  And it’s safe to say that they’ve had a pretty successful project. 

One thing that really stands out about the UberEats design team is their adherence to the design thinking process. They seek to empathize with their user’s experience so much that they’ve implemented The Walkabout Program—a quarterly event where UberEats designers are sent to a city to learn about its transportation infrastructure, delivery and restaurant industry, and its overall food culture. 

In addition to this immersive design technique, UberEats designers iterate quickly and innovate constantly. They participate in rapid field testing, where designers are interviewing and prototyping with the people who will be using the product the most: restaurant workers, delivery drivers, and meal recipients. 

The UberEats team also holds innovation workshops where team members from many disciplines gather to brainstorm possible improvements. These same designers also attend numerous out-of-office conferences, meetups, and talks related to the restaurant industry, cuisine trends, and food technology. 

Read the full story: How We Design on the UberEATS Team

Top reads in design thinking

How Creativity and Design Thinking Will Push India's Growth Story Forward

Why design thinking is marketing's best friend

Thank you for reading.

Shivani from DesignPlayStore.

Ready for more?

updated on:

Design Thinking Examples: Five Real Stories

min to read

Kateryna Mayka

Writer at Eleken

No other area of design requires such deep immersion in the client's world as UI/UX design. To create a user-friendly and practical product, it is necessary to understand the customers’ pains, needs, and expectations. This is what design thinking is all about.

Design thinking is a unique client-centered approach that helps businesses create innovative ideas using a human point of view instead of raw historical data. For example, our recent client, HandPrinter, based their project on a goal that is very important - to encourage people to protect the environment - which helped them become a company with an inimitable vision and no analogs around the globe. Interested in how they did it? Please, read further in our case study .

With the help of design thinking, you can help your clients solve their problems and create benefits for your business. Of course, in theory, using this approach seems just a piece of cake. But what about real life? I guess you are wondering if it is possible to efficiently apply design thinking in your business.

Want to innovate with a human-centered approach?

In this article, we will discuss five design thinking examples of real companies that actively use this approach as a part of their corporate strategy. So, get ready for your dose of inspiration!

Examples of companies that use design thinking

To show how resulting the design thinking can be we won't have to dig through the whole internet. What's more, I bet that you have not only heard about companies we're going to talk about but even use their products regularly!

Anyways, without further ado, let's analyze some cases when companies revolutionized the market using design thinking.

The first obvious choice to illustrate design thinking in action is Airbnb. Its founders, designers Brian Chesky and Joe Gebbia, studied together at the university and then rented an apartment in San Francisco. In 2007, a design conference took place, and hotel room prices skyrocketed. To make attending the conference more affordable for their colleagues, the two bought some air mattresses and created airbedandbreakfast.com to find guests.

It worked well enough, so Chesky and Gebbia wanted to continue developing the idea. As designers, they were familiar with the empathy method and used it to answer the following questions: "What do people do when they are traveling? How can they learn how to get from the airport to their lodging quickly? How can one recommend their favorite place to eat in the neighborhood?"

Answering these questions gave Chesky and Gebbia insights on the direction of further developing the website. The user can now rent an apartment, order breakfast, and communicate with their host to ask them for recommendations or local knowledge. The ability to leave feedback from both sides also allowed for a break in distrust between the host and the guest.

Now, every design team at Airbnb has a leader whose first priority is specifically to represent the customer and their needs.

• Start Small
• Fail Quickly

Netflix used these design thinking principles way back in 2011. It was not afraid to destroy its existing DVD delivery business in the wake of new tech trends, dropped the early streaming attempts once they failed, and grew rapidly thanks to the introduction of Netflix's original content. How did it come to this? In 2001, Netflix founder Reed Hastings spent $10 million a year on streaming technology research ( Forbes ) to better understand the market, the trends, and users.What makes Netflix's human-centered UX design so distinctive? Keep in mind: it goes further than digital design itself. It's all about the user experience from start to finish.

Interactive card design

Netflix's card design is a hallmark of its user interface, offering a visually engaging and intuitive way to browse content. Each card represents a movie or TV show, providing users with key visuals, such as posters or stills, that invite exploration and interaction. This design allows for an organized presentation of vast libraries, making it easier for users to scan and find content that appeals to them. Additionally, the card layout adapts to various screen sizes, ensuring a consistent and accessible user experience across devices.

AI-powered personalized recommendations

The AI-powered recommendations are another cornerstone of Netflix's design. By analyzing a user's viewing history, preferences, and even the time spent on specific titles, Netflix's algorithms curate a bespoke selection of content tailored to each viewer. This system not only enhances user satisfaction by reducing the time spent searching for something to watch but also introduces users to new content they might not have discovered otherwise.

Seamless cross-platform experience

Netflix offers a consistent user experience across various devices and platforms, including smart TVs, gaming consoles, smartphones, and tablets. This consistency ensures that users have a familiar interface, making it easy to switch between devices without relearning the navigation.

Efficient search functionality

The platform's highly optimized search feature allows users to find content by titles, actors, genres, or even specific keywords. This efficiency reduces users' time searching for content, enhancing their overall experience.

Personalized user profiles

Netflix allows the creation of multiple user profiles within a single account, each with its personalized recommendations, watch history, and content preferences. This feature is particularly useful for families or shared accounts, ensuring each user's experience is tailored to their tastes.

Smart download feature

Netflix introduced the 'Smart Downloads' feature for mobile users. This feature automatically downloads the next episode of a series you're watching and deletes the ones you've already watched. This feature is particularly useful for users who watch content on the go, ensuring they can always access their favorite shows without manual management.

High-quality thumbnails 

Netflix employs a unique strategy of using multiple, high-quality thumbnails for each title, which change dynamically. This approach is designed to capture the attention of different users based on their interests, making the content more appealing and increasing the likelihood of engagement.

Using design thinking to prioritize the customer has allowed Netflix to become a household name and an essential part of how we consume media.

Uber, with its global footprint spanning over 600 cities across 65 countries and serving more than 75 million users, stands as a testament to the transformative power of design thinking in creating innovative business models. The core of Uber's user experience excellence lies in its deep empathy for users, particularly addressing the universal disdain for waiting. This insight has been pivotal in shaping a service that is not just a ride-hailing app but a seamless part of modern urban mobility.

One of Uber's design thinking triumphs is the minimization of user inaction. Through engaging animations and interactive elements, Uber transforms passive waiting times into periods of engagement and information for its riders. This approach not only entertains but also keeps users informed about the status of their ride, effectively reducing the perceived wait time.

Transparency is another cornerstone of Uber's design strategy. By openly displaying key operational aspects, such as the dynamic calculation of arrival times, Uber fosters trust and appreciation among its users. This transparency ensures that users are not burdened with unnecessary technical details, yet they receive enough information to understand the efforts made to optimize their experience.

Additionally, Uber excels in setting and communicating clear expectations for the ride journey. By detailing each phase of the ride process, from car arrival to destination reach, Uber keeps users informed about their progress towards their goal, enhancing the overall experience and anticipation.

Moreover, Uber's design extends to features like safety protocols, real-time tracking, and easy payment options, which collectively contribute to a user-friendly, reliable, and efficient service. This holistic, user-centric design approach has not only solved practical transportation challenges but has also redefined the very fabric of urban mobility, making Uber an indispensable tool in daily life. Through design thinking, Uber has successfully transformed the concept of getting from point A to point B into an experience that users value and rely upon.

Bridget van Kralingen, senior vice president of IBM Global Business Services, recently told : “There’s no longer any real distinction between business strategy and the design of the user experience” and these words make a big difference.

IBM design has gone through many stages in its development (" good design is good business "), and now the company provides design services and invests $100 million in implementing principles of design thinking in their organization.

In 2014, IBM used design thinking when creating Bluemix (now IBM Cloud), a cloud platform for application development. IBM’s main goal was to help developers in big companies create cloud applications much faster.

Researching their target audience allowed IBM to create an easy-to-use and functional platform that attracted more than 1 000 000 developers.

Here are three main points why all these developers fall in love with Bluemix:

• Choice. Bluemix allows to build a consistent application that can run both on and off premise. It helps to reduce the cost and time developers spend on setting up infrastructure
• Extensive catalog with tools. Bluemix offers almost 150 tools and services that propels you months ahead in development (e.g. Internet of Things for secure data collection, Watson for cognitive computing services, etc.)

‍ Methodology. Using the DevOps tool chain allows to easily scale your projects.

That’s how identifying pains and needs of the target audience allowed IBM create a platform that helps developers quickly build applications.

Intuit is a global platform that helps its customers cope with financial issues (accounting, tax preparation, etc.).

Back in 2006, Scott Cook, the founder of Intuit decided that his accounting software company has to be more innovative. Inspired by an article about design thinking written by Roger Martin, Cook started thinking about how this approach can help to develop and improve his product.

First of all , Intuit’s team identified the problem. Most people hate spreadsheet-based personal finance tracking solutions, and they stop using them as soon as they start. The research of competitors helped to realize that existing solutions are suitable for professional accountants but difficult to use for an average person. Although there is a need for financial planning for individuals or small businesses as well.

The solution was to create an easy-to-use and consistent UX. When Intuit introduced its software to help people control their finances, there were 46 similar products on the market. At the beginning of the journey, they joked that at that moment they had the " 47th mover advantage . "

The basic version of Intuit offered only a third of all available features, but with a great design. Instead of spreadsheets, the program displays familiar images with check receipts on them.

Because of its extremely intuitive design, Intuit immediately became the market leader in personal finance software.

As a result, Intuit has shown software companies that good design is something every industry should care about. You can use empathy to create well-designed software that can both solve business problems and serve people.

Think of people and they will think about you

To make a successful product you need to put user needs at the center of your efforts focusing on designing usable, delightful, and efficient experiences. Design thinking helps you to understand real people’s needs and problems and uncovers ways of improving user experiences.

So, don’t hesitate to make design thinking a part of your company culture. It will promote creating products that deeply resonate with your customers — ultimately driving engagement and growth.

And if you need help in creating products that show how much you care about your customers, come to Eleken for a human-centered UI/UX design .

Senior content writer at Eleken UI/UX design agency. Kateryna has 4 years of experience translating complex design concepts into accessible content for SaaS businesses.

Brainwriting, brain-netting, roleplay, and many more- learn about these strategies to get the most out of brainstorming.

Learn about what is human-centered design and design thinking and how they differ. Discover examples of how companies apply both approaches.

Agile vs Design Thinking? Why not use them both? Read on to learn what differs Agile from design thinking and how they can work together.

Read how to go beyond brainstorming in your ideation and get real tools for getting those out-of-the-box ideas.

Have you heard of design thinking? Learn what it is, how it helps to hack the way to innovation, and what are the six design thinking steps you can implement.

Design thinking vs design sprint: still confused? Read on to learn the difference and know when to use each method.

On the road to great design, there are many iterations of good design. Let’s find out what iterative design is and wherein lies its power to make things better.

Learn how to look at your project from a different angle, highlight user problems and come up with ideas for solving them using the Double Diamond model.

Browser not supported

This probably isn't the experience you were expecting. Internet Explorer isn't supported on Uber.com. Try switching to a different browser to view our site.

Schedule rides in advance

Introducing Domain-Oriented Microservice Architecture

Introduction

Recently there has been substantial discussion around the downsides of service oriented architectures and microservice architectures in particular. While only a few years ago, many people readily adopted microservice architectures due to the numerous benefits they provide such as flexibility in the form of independent deployments, clear ownership, improvements in system stability, and better separation of concerns, in recent years people have begun to decry microservices for their tendency to greatly increase complexity, sometimes making even trivial features difficult to build.

As Uber has grown to around 2,200 critical microservices, we experienced these tradeoffs first hand. Over the last two years, Uber has attempted to reduce microservice complexity while still maintaining the benefits of a microservice architecture. With this blog post we hope to introduce our generalized approach to microservice architectures, which we refer to as “Domain-Oriented Microservice Architecture” (DOMA).

While it’s been popular in recent years to criticize microservice architectures because of these downsides, few people have advocated an outright rejection of microservice architectures. The operational benefits are too important, and it seems that there are no, or limited, alternatives. Our goal with DOMA is to provide a way forward for organizations that want to reduce overall system complexity while maintaining the flexibility associated with microservice architectures.

This piece explains DOMA, the concerns that led to the adoption of this architecture for Uber, its benefits for platform and product teams, and, finally, some advice for teams who want to adopt this architecture. 

What is a microservice?

Microservices are an extension of service oriented architectures. As opposed to the fairly large “services” of the 2000s, microservices are applications that represent a set of narrowly scoped functionality. These applications are hosted and available over the network and expose a well-defined interface. Other applications call this interface by making a “ remote procedure call ” (RPC).

The key characteristic of microservice architecture is the way in which code is hosted, called, and deployed. If we think about large, monolithic applications, they are generally split into encapsulated components with well-defined interfaces. These interfaces would then be called directly in-process as opposed to over the network. In this way, we can start to think of a microservice as a library with a performance hit (network I/O and serialization / deserialization) in order to call any of its functions.

When we think about microservices this way, we might question why we would adopt a microservice architecture at all. The answer is often independent deployments and scaling . With a large, monolithic application, an organization is forced to deploy or release all of their code at once. Each new version of an application can involve numerous changes. Deployments become risky and time consuming. Anyone can bring the whole system down. 

In other words, organizations adopt microservices for an operational benefit at the expense of performance . Organizations also must take on the cost to maintain the infrastructure necessary to support microservices. In many situations, it turns out, this trade-off makes a lot of sense, but it is also a strong argument against a premature adoption of a microservice architecture.

Motivations

At Uber, we adopted a microservice architecture because we had (circa 2012-2013) primarily two monolithic services and ran into many of the operational issues that microservices solve.

• Availability Risks. A single regression within a monolithic code base can bring the whole system (in this case, all of Uber) down.
• Risky, expensive deployments. These were painful and time consuming to perform with the frequent need for rollbacks.
• Poor separation of concerns. It was difficult to maintain good separations of concerns with a huge code base. In an exponential growth environment, expediency sometimes led to poor boundaries between logic and components.
• Inefficient execution. These issues combined made it difficult for teams to execute autonomously or independently.

In other words, as Uber grew from 10s to 100s of engineers with multiple teams owning pieces of the tech stack, the monolithic architecture tied the fate of teams together and made it difficult to operate independently.

As a result, we adopted a microservice architecture. Ultimately our systems became more flexible , which allowed teams to be more autonomous.

• System reliability. Overall system reliability goes up in a microservice architecture. A single service can go down (and be rolled back) without taking down the whole system.
• Separation of concerns. Architecturally, microservice architectures force you to ask the question “why does this service exist?” more clearly defining the roles of different components.
• Clear Ownership. It becomes much clearer who owned what code. Services are typically owned at the individual, team, or org level enabling faster growth.
• Autonomous execution. Independent deployments + clearer lines of ownership unlock autonomous execution by various product and platform teams.
• Developer Velocity. Teams can deploy their code independently, which enables them to execute at their own pace.

It’s not an exaggeration to say that Uber would not have been able to accomplish the scale and quality of execution that we maintain today without a microservice architecture.

However, as the company grew even larger, 100s of engineers to 1000s, we began to notice a set of issues associated with greatly increased system complexity . With a microservice architecture one trades a single monolithic code base for black boxes whose functionality can change at any time and easily cause unexpected behavior.

For instance, engineers had to work through around 50 services across 12 different teams in order to investigate the root cause of the problem.

Understanding dependencies between services can become quite difficult, as calls between services can go many layers deep. A latency spike in the nth dependency can cause a cascade of issues upstream. Visibility into what’s actually happening is impossible without the right tools, making debugging difficult.

In order to build a simple feature an engineer often has to work across multiple services, all of which are owned by different individuals and teams. This requires extensive collaboration with time spent on meetings, design, and code review. The earlier promise of clear lines of service ownership is compromised as teams build code within each other’s services, modify each other’s data models, and even perform deployments on behalf of service owners. Networked monoliths can form, where services that appear to be independent all have to be deployed together to safely perform any change.

The result is a slower developer experience, instability for service owners, more painful migrations, etc. For organizations that have already adopted a microservice architecture there is no turning back. It becomes a case of “ can’t live with them, can’t live without them .” 

Domain-Oriented Microservice Architecture

If we can think of microservices as I/O bound libraries and a “microservice architecture” as a large, distributed application then we can use well understood architectures to think about how to organize our code. 

“Domain-Oriented Microservice Architecture” thus draws heavily from established ways to organize code such as Domain-driven Design , Clean Architecture , Service-Oriented Architecture , and object- and interface-oriented design patterns. We think of DOMA as innovative only insofar as it is a relatively novel way to leverage established design principles in large distributed systems in large organizations.

The core principles and terminology associated with DOMA are as follows:

• Instead of orienting around single microservices, we oriented around collections of related microservices. We call these domains.
• We further create collections of domains which we call layers. The layer that the domain belongs to establishes what dependencies the microservices within that domain are allowed to take on. We call this layer design.
• We provide clean interfaces for domains that we treat as a single point of entry into the collection. We call these gateways.
• Finally, we establish that each domain should be agnostic to other domains, which is to say, a domain shouldn’t have logic related to another domain hard coded inside of its code base or data models. Since frequently teams do need to include logic in another team’s domain (for example, custom validation logic or some meta context on a data model), we provide an extension architecture to support well defined extension points within the domain.

In other words, by providing a systematic architecture, domain gateways, and predefined extension points, DOMA intends to transform microservice architectures from something complex to something comprehensible: a structured set of flexible, reusable, and layered components. 

The rest of this post digs into Uber’s implementation of DOMA, the benefits we’ve seen, and practical advice for companies which might want to adopt this approach.

Uber’s Implementation

Uber domains represent a collection of one or more microservices tied to a logical grouping of functionality. A common question in designing a domain is “how big should a domain be?” We give no guidance here. Some domains can include tens of services, some domains only a single service. The important task is to think carefully about the logical role of each collection. For instance, our map search services constitute a domain, fare services are a domain, matching platform (matching riders and drivers) are a domain. These also don’t always follow company org structure. The Uber Maps org itself is split into three domains, with 80 microservices behind 3 different gateways.

Layer Design

Layer design answers the question of “what service can call what other service?” within Uber’s microservice architecture. As a result, we can think of layer design as “separation of concerns at scale.” Alternatively, we can think of layer design as “dependency management at scale.” 

Layer design describes a mechanism for thinking about failure blast radius and product specificity across service dependencies at Uber. As domains move from the bottom layer to the top layer, they impact fewer services in the case of an outage and represent more specific product use cases. Conversely, functionality at the bottom layers have more dependents and as a result tend to have a larger blast radius and represent a more general set of business functionality. The figure below illustrates this concept.

One can think of the top layers as specific user experiences (such as mobile features), and the bottom layers as generalized business functionality (such as account management or marketplace trips). Layers only depend on the layers under them, which gives us a useful heuristic to think about questions like blast radius and domain integration.

It’s worth noting that functionality often moves “down” this chart from specific to more general. One can imagine a simple feature that eventually becomes more and more of a platform as requirements evolve. In fact, this sort of migration downward is expected, and many of Uber’s core business platforms started as rider or driver specific functionality that became more generalized as we developed more lines of business and they took on more dependencies (such as Uber Eats or Uber Freight).

Within Uber, we established the following five layers.

• Infrastructure layer. Provides functionality that any engineering organization could use. It’s Uber’s answer to the big engineering questions, such as storage or networking.
• Business layer. Provides functionality that Uber as an organization could use, but that is not specific to a particular product category or line of business (LOB) such as Rides, Eats, or Freight.
• Product layer. Provides functionality that relates to a particular product category or LOB, but is agnostic to the mobile application, such as the “request a ride” logic which is leveraged by multiple Rides facing applications (Rider, Rider “Lite”, m.uber.com, etc).
• Presentation. Provide functionality that directly relates to features that exist within a consumer-facing application (mobile/web). 
• Edge Layer. Safely exposes Uber services to the outside world. This layer is also mobile application aware.

As you can see, each subsequent layer represents an increasingly specific grouping of functionality, and has a smaller and smaller blast radius (or, in other words, less components depend on the functionality within that layer). 

The term “Gateway API” is already a broadly established concept within microservice architectures. Our definition does not vary greatly from the established definition, except that we tend to think of gateways exclusively as a single entry-point into a collection of underlying services, which we call a domain. The success of a gateway relies on the success of the API design.

Since upstream consumers only operate on a single service, gateways provide numerous benefits in terms of future migrations, discoverability, and overall reduction in system complexity with upstream services only taking a single dependency as opposed to dependencies on several downstream services that might exist within a domain. If we think about gateways in the sense of OO design, they are interface definitions, which enable us to do whatever we want in terms of the underlying “implementation” (in this case the collection of underlying microservices).

Extensions represent a mechanism to extend domains. The basic definition of an extension is that it provides a mechanism for extending the functionality of an underlying service without changing the actual implementation of that service and without impacting its overall reliability. At Uber we provide two different extension models: logic extensions and data extensions . The concept of extensions has allowed us to scale our architecture to multiple teams being able to work independently of each other.

Logic Extensions

Logic extensions provide a mechanism for extending the underlying logic of a service. For logic extensions we use a variation of a provider or plugin pattern with an interface defined on a service-by-service basis. This makes it so that extending teams can implement extension logic in an interface-driven way without modifying the core code of the underlying platform.

For example, a driver goes online. Typically, we make various checks to ensure that a driver is allowed to go online (safety checks, compliance, etc.). Each of these is owned by an individual team. One way to implement this would be to have each team write logic in the same endpoint, but this can introduce complexity. Each check would require custom, and entirely unrelated, logic. 

In the case of logic extensions, the “go online” endpoint would define an interface that they expect each extension to conform to with a predefined request type and a response. Each team would register an extension that would be responsible for the execution of this logic. In this case, they might simply take some context about the driver and return a bool, saying if the driver can go online or not. The go online endpoint would simply iterate through these responses, and determine if any of them are false.

This decouples the core code from each extension, and provides isolation between extensions, which don’t know what other logic is executing. It’s easy to build up more functionality around this, such as observability or feature flagging. 

Data Extensions

Data extensions provide a mechanism for attaching arbitrary data to an interface to avoid bloat in core platform data models. For data extensions, we leverage Protobuf’s Any functionality so that teams can add arbitrary data to requests. Services will often store this data or pass it to a logic extension so that the core platform is never responsible for deserializing (and thus “knowing about”) this arbitrary context. Protobuf’s Any implementation comes with some infrastructure overhead in exchange for stronger typing. For a simpler implementation, one could just as easily use a JSON string to represent arbitrary data.

Outside of logic and data extensions, many teams at Uber have introduced their own extension patterns that are appropriate for their domain. For example, much of the integrations tied to our presentation architecture uses DAG based task execution logic.

Almost every major domain at Uber has been influenced on some level by DOMA. Over the last year, we have focused primarily on Uber’s business layer which provides generalized logic for each of our various lines of business. 

DOMA is still young at Uber, and we are excited to share more data and in-depth examples of our architecture in the future. However, early signs have been extremely positive in terms of a simplified developer experience and a reduction in overall system complexity.

Products & Platforms

DOMA was the result of a consensus effort across product and platform teams at Uber. Platform support costs often dropped an order of magnitude. Product teams benefited from guard rails and accelerated development. For example, an early platform consumer of our extensions architecture was able to drop the time to prioritize and integrate a new feature from three days to three hours by adopting an extension architecture with reduced time for code review, planning, and learning curve for consumers.

Reduced Complexity

Previously product teams would have to call numerous downstream services to leverage a domain; they now have to call just one. By reducing the number of touchpoints to onboard a new feature, platforms were able to reduce onboarding time by 25-50%. Furthermore, we were able to classify 2200 microservices into 70 domains. Roughly 50% of which have been implemented, and most of which have some plan for future adoption.

Future Migrations 

At Uber, we calculated that the half-life of a microservice was 1.5 years, which means that every 1.5 years 50% of our microservices churn. Without gateways it’s easy for a microservice architecture to fall into a “migration hell” as a result of this churn. Ever changing microservices constantly require upstream migrations. Gateways enable teams to avoid dependencies on the underlying domain services, which means those services can change without forcing an upstream migration. 

Two of Uber’s largest platform rewrites in the last year happened behind gateways. These platforms had hundreds of services that depended on them that would have had to migrate existing consumers. The cost of migration in these cases would have been extremely high, making a complete platform rewrite infeasible.

New Lines of Business & Products

Platforms designed using DOMA have proven to be much more extensible and easier to maintain. Most teams at Uber who adopted DOMA did so because supporting new lines of business had become too expensive.

Practical Advice

This section provides some practical advice for companies that might want to adopt DOMA. The guiding principle here is that in our experience a mature and thoughtful microservice architecture stems from quiet nudges in the right direction at the right time. The reality is that a true “rewrite” is never possible for one’s entire microservice architecture.

As a result, we think of evolving a microservice architecture more like “trimming a hedge” so that it eventually grows correctly, rather than a top-down or one-time architecture (or re-architecture) effort. It’s a dynamic and progressive process.

The driving questions should be “when should we adopt a microservice architecture?” and “does it make sense for our organization?” As we’ve seen above, while microservices provide an operational benefit to organizations with a large number of engineers, this trades off with an increase in complexity that can make features more difficult to build.

In small organizations, the operational benefit likely does not offset the increase in architectural complexity. Furthermore, microservice architectures often require dedicated engineering resources to support which may be out of budget for an early stage company or else suboptimal from a prioritization perspective. 

With this in mind, it isn’t unreasonable to hold off on microservices altogether for some time. If an organization does choose to adopt microservices, it should think about the “microservice as large distributed application” analogy, and the separation of concerns between microservices it wants to build. Also, recognize that the first microservices will likely be the most important and longest lasting as they truly describe the core of the business.

Once a company becomes midsized with multiple teams and the clear separation of concerns becomes hazy between different features and platforms, microservice architectures become more obviously useful.

It’s at this stage that one can begin to think about hierarchies between microservices. Dependency management may become more important, as some services begin to become more obviously critical to business operation, and more and more teams rely on them. 

Early investment in platformization may pay dividends down the road. There is the possibility to avoid tech debt here if one can create completely product agnostic business platforms and avoid arbitrary product logic in core platform services. It might make sense to adopt extensions at this point to accomplish that goal.

Given that the number of microservices is likely still quite low, it may not make sense to cluster them together. However, it’s worth noting here that a domain in the context of Uber’s DOMA implementation can contain a single service, so it may still be useful to think in a “domain-oriented” way.

Larger engineering organizations may have hundreds of engineers and microservices and several dependencies. At this point DOMA reaches its full usefulness. There will likely be obvious clusters of microservices that can be easily grouped together into domains with a gateway in front of them. Legacy services often begin to need to be refactored or rewritten and then migrated, which means that gateways will soon begin to provide value in terms of ease of migration if they are already in place.

Clear hierarchy will also become increasingly important with some services operating as “product” services for particular features or grouping of features, and other services will increasingly support multiple products and be thought of as “platforms.” It’s critical at this stage to keep arbitrary product logic decoupled from platforms, so as to avoid a heavy operational burden on platform teams as well as system-wide instability.

Final Thoughts

We are still actively evolving DOMA as more and more teams at Uber come to adopt it. The critical insight of DOMA is that a microservice architecture is really just one, large, distributed program and you can apply the same principles to its evolution that you would apply to any piece of software. DOMA is simply an approach for thinking about these principles in practice. We hope others find it useful and we look forward to feedback!

DOMA itself was the result of a cross-functional effort, which involved nearly 60 engineers across every org at Uber. Some particular acknowledgements, for people who invested heavily into this effort over the last 2 years…

Alex Zylman, Alexandre Wilhelm, Allen Lu, Ankit Srivastava, Anthony Tran, Anupam Dikshit, Anurag Biyani, Daniel Wolf, Davide D’Agostino, Deepti Chedda, Dmitriy Bryndin, Gaurav Tungatkar, Jacob Greenleaf, Jaikumar Ganesh, Jennie Ngyuen, Joe McCabe, Joshua Shinavier, Julia Law, Kusha Kapoor, Linda Fu, Madan Thangavelu, Nimish Sheth, Parth Shah, Shawn Burke, Simon Newton, Steve Sherwood, Uday Kiran Medisetty, and Waleed Kadous 

Acknowledgements:

This work brings multiple existing design patterns in the industry to solve problems at Uber while also suggesting new patterns like extensions. We are thankful to the industry for the work on them. We are also thankful to the engineers at Linkedin who worked on Superblocks , who spoke to us about their experiences.

Adam Gluck is a Sr. Software Engineer II at Uber. He spent his first 3.5 years at Uber fleshing out our Driver Platform team and helping to scale our driver product. More recently, he’s been a part of Uber’s engineering strategy team, focused on high level system architecture and Uber-wide platformization efforts.

Posted by Adam Gluck

Related articles

Pinot for Low-Latency Offline Table Analytics

August 29 / Global

Continuous deployment for large monorepos

August 26 / Global

Shifting E2E Testing Left at Uber

August 22 / Global

Sparkle: Standardizing Modular ETL at Uber

August 15 / Global

Upgrading Uber’s MySQL Fleet  to version 8.0

August 8 / Global

Most popular

Revolutionizing the rider experience: insights from Uber’s Global Head of Transit Partnerships

Evolving partnerships: how Uber and Brightline rapidly innovate with flexible tech

Odin: Uber’s Stateful Platform

Resources for driving and delivering with Uber

Experiences and information for people on the move

Ordering meals for delivery is just the beginning with Uber Eats

Putting stores within reach of a world of customers

Transforming the way companies move and feed their people

Taking shipping logistics in a new direction

Moving care forward together with medical providers

Expanding the reach of public transportation

Explore how Uber employees from around the globe are helping us drive the world forward at work and beyond

Engineering

The technology behind Uber Engineering

Community support

Doing the right thing for cities and communities globally

Uber news and updates in your country

Product, how-to, and policy content—and more

Sign up to drive

Sign up to ride.

Design Thinking Case Study Index

How the UberEATS Team uses Design Thinking

About Stanford GSB

• The Leadership
• Dean’s Updates
• School News & History
• Commencement
• Business, Government & Society
• Centers & Institutes
• Center for Entrepreneurial Studies
• Center for Social Innovation
• Stanford Seed

About the Experience

• Learning at Stanford GSB
• Experiential Learning
• Guest Speakers
• Entrepreneurship
• Social Innovation
• Communication
• Life at Stanford GSB
• Collaborative Environment
• Activities & Organizations
• Student Services
• Housing Options
• International Students

Full-Time Degree Programs

• Why Stanford MBA
• Academic Experience
• Financial Aid
• Why Stanford MSx
• Research Fellows Program
• See All Programs

Non-Degree & Certificate Programs

• Executive Education
• Stanford Executive Program
• Programs for Organizations
• The Difference
• Online Programs
• Stanford LEAD
• Seed Transformation Program
• Aspire Program
• Seed Spark Program
• Faculty Profiles
• Academic Areas
• Awards & Honors
• Conferences

Faculty Research

• Publications
• Working Papers
• Case Studies

Research Hub

• Research Labs & Initiatives
• Business Library
• Data, Analytics & Research Computing
• Behavioral Lab

Research Labs

• Cities, Housing & Society Lab
• Golub Capital Social Impact Lab

Research Initiatives

• Corporate Governance Research Initiative
• Corporations and Society Initiative
• Policy and Innovation Initiative
• Rapid Decarbonization Initiative
• Stanford Latino Entrepreneurship Initiative
• Value Chain Innovation Initiative
• Venture Capital Initiative
• Career & Success
• Climate & Sustainability
• Corporate Governance
• Culture & Society
• Finance & Investing
• Government & Politics
• Leadership & Management
• Markets and Trade
• Operations & Logistics
• Opportunity & Access
• Technology & AI
• Opinion & Analysis
• Email Newsletter

Welcome, Alumni

• Communities
• Digital Communities & Tools
• Regional Chapters
• Women’s Programs
• Identity Chapters
• Find Your Reunion
• Career Resources
• Job Search Resources
• Career & Life Transitions
• Programs & Webinars
• Career Video Library
• Alumni Education
• Research Resources
• Volunteering
• Alumni News
• Class Notes
• Alumni Voices
• Contact Alumni Relations
• Upcoming Events

Admission Events & Information Sessions

• MBA Program
• MSx Program
• PhD Program
• Alumni Events
• All Other Events
• Operations, Information & Technology
• Organizational Behavior
• Political Economy
• Classical Liberalism
• The Eddie Lunch
• Accounting Summer Camp
• California Econometrics Conference
• California Quantitative Marketing PhD Conference
• California School Conference
• China India Insights Conference
• Homo economicus, Evolving
• Political Economics (2023–24)
• Scaling Geologic Storage of CO2 (2023–24)
• A Resilient Pacific: Building Connections, Envisioning Solutions
• Adaptation and Innovation
• Changing Climate
• Civil Society
• Climate Impact Summit
• Climate Science
• Corporate Carbon Disclosures
• Earth’s Seafloor
• Environmental Justice
• Operations and Information Technology
• Organizations
• Sustainability Reporting and Control
• Taking the Pulse of the Planet
• Urban Infrastructure
• Watershed Restoration
• Junior Faculty Workshop on Financial Regulation and Banking
• Ken Singleton Celebration
• Marketing Camp
• Quantitative Marketing PhD Alumni Conference
• Presentations
• Theory and Inference in Accounting Research
• Stanford Closer Look Series
• Quick Guides
• Core Concepts
• Journal Articles
• Glossary of Terms
• Faculty & Staff
• Researchers & Students
• Research Approach
• Charitable Giving
• Financial Health
• Government Services
• Workers & Careers
• Short Course
• Adaptive & Iterative Experimentation
• Incentive Design
• Social Sciences & Behavioral Nudges
• Bandit Experiment Application
• Conferences & Events
• Get Involved
• Reading Materials
• Teaching & Curriculum
• Energy Entrepreneurship
• Faculty & Affiliates
• SOLE Report
• Responsible Supply Chains
• Current Study Usage
• Pre-Registration Information
• Participate in a Study

Uber in 2024: From Industry Disruption to Creating Value For All Stakeholders

Dara Khosrowshahi became the CEO of Uber in August 2017, following internal turbulence and serious headwinds related to the company’s governance and reputation. Five short years later, Uber was clearly back on course, building on the success of its technology platform to reach 150 million monthly active platform users—and a market cap of $125 billion by the end of 2023.

This case study traces the remarkable transformation of Uber from its early innovation as a ride-hailing pioneer in a handful of cities, to the global expansion of Uber mobility services that required close attention to local operational and regulatory practices, to solving the complex technical challenges to drive Uber’s food delivery services forward. Interviews with Uber leadership reveals the strategic approach to work on the engineering, data science, product management, and product design challenges involved in building and maintaining a customer-friendly app and create an optimized user experience—and scale this on a global basis while factoring in local conditions and practices.

Key to this success was a culture reboot within Uber, and a renewed focus on collaboration and value creation for all stakeholders. The company that had found its initial footing by disrupting and transforming the taxi industry, more than a decade earlier, now faced a future where artificial intelligence and autonomous vehicles would likely disrupt the mobility sector once again—but Uber was preparing intensively for what the future might bring.

Learning Objective

• See the Current DEI Report
• Supporting Data
• Research & Insights
• Share Your Thoughts
• Search Fund Primer
• Affiliated Faculty
• Faculty Advisors
• Louis W. Foster Resource Center
• Defining Social Innovation
• Impact Compass
• Global Health Innovation Insights
• Faculty Affiliates
• Student Awards & Certificates
• Changemakers
• Dean Jonathan Levin
• Dean Garth Saloner
• Dean Robert Joss
• Dean Michael Spence
• Dean Robert Jaedicke
• Dean Rene McPherson
• Dean Arjay Miller
• Dean Ernest Arbuckle
• Dean Jacob Hugh Jackson
• Dean Willard Hotchkiss
• Faculty in Memoriam
• Stanford GSB Firsts
• Annual Alumni Dinner
• Class of 2024 Candidates
• Certificate & Award Recipients
• Dean’s Remarks
• Keynote Address
• Teaching Approach
• Analysis and Measurement of Impact
• The Corporate Entrepreneur: Startup in a Grown-Up Enterprise
• Data-Driven Impact
• Designing Experiments for Impact
• Digital Marketing
• The Founder’s Right Hand
• Marketing for Measurable Change
• Product Management
• Public Policy Lab: Financial Challenges Facing US Cities
• Public Policy Lab: Homelessness in California
• Lab Features
• Curricular Integration
• View From The Top
• Formation of New Ventures
• Managing Growing Enterprises
• Startup Garage
• Explore Beyond the Classroom
• Stanford Venture Studio
• Summer Program
• Workshops & Events
• The Five Lenses of Entrepreneurship
• Leadership Labs
• Executive Challenge
• Arbuckle Leadership Fellows Program
• Selection Process
• Training Schedule
• Time Commitment
• Learning Expectations
• Post-Training Opportunities
• Who Should Apply
• Introductory T-Groups
• Leadership for Society Program
• Certificate
• 2024 Awardees
• 2023 Awardees
• 2022 Awardees
• 2021 Awardees
• 2020 Awardees
• 2019 Awardees
• 2018 Awardees
• Social Management Immersion Fund
• Stanford Impact Founder Fellowships
• Stanford Impact Leader Prizes
• Social Entrepreneurship
• Stanford GSB Impact Fund
• Economic Development
• Energy & Environment
• Stanford GSB Residences
• Environmental Leadership
• Stanford GSB Artwork
• A Closer Look
• California & the Bay Area
• Voices of Stanford GSB
• Business & Beneficial Technology
• Business & Sustainability
• Business & Free Markets
• Business, Government, and Society Forum
• Second Year
• Global Experiences
• JD/MBA Joint Degree
• MA Education/MBA Joint Degree
• MD/MBA Dual Degree
• MPP/MBA Joint Degree
• MS Computer Science/MBA Joint Degree
• MS Electrical Engineering/MBA Joint Degree
• MS Environment and Resources (E-IPER)/MBA Joint Degree
• Academic Calendar
• Clubs & Activities
• LGBTQ+ Students
• Military Veterans
• Minorities & People of Color
• Partners & Families
• Students with Disabilities
• Student Support
• Residential Life
• Student Voices
• MBA Alumni Voices
• A Week in the Life
• Career Support
• Employment Outcomes
• Cost of Attendance
• Knight-Hennessy Scholars Program
• Yellow Ribbon Program
• BOLD Fellows Fund
• Application Process
• Loan Forgiveness
• Contact the Financial Aid Office
• Evaluation Criteria
• GMAT & GRE
• English Language Proficiency
• Personal Information, Activities & Awards
• Professional Experience
• Letters of Recommendation
• Optional Short Answer Questions
• Application Fee
• Reapplication
• Deferred Enrollment
• Joint & Dual Degrees
• Entering Class Profile
• Event Schedule
• Ambassadors
• New & Noteworthy
• Ask a Question
• See Why Stanford MSx
• Is MSx Right for You?
• MSx Stories
• Leadership Development
• How You Will Learn
• Admission Events
• Personal Information
• GMAT, GRE & EA
• English Proficiency Tests
• Career Change
• Career Advancement
• Career Support and Resources
• Daycare, Schools & Camps
• U.S. Citizens and Permanent Residents
• Requirements
• Requirements: Behavioral
• Requirements: Quantitative
• Requirements: Macro
• Requirements: Micro
• Annual Evaluations
• Field Examination
• Research Activities
• Research Papers
• Dissertation
• Oral Examination
• Current Students
• Education & CV
• International Applicants
• Statement of Purpose
• Reapplicants
• Application Fee Waiver
• Deadline & Decisions
• Job Market Candidates
• Academic Placements
• Stay in Touch
• Faculty Mentors
• Current Fellows
• Standard Track
• Fellowship & Benefits
• Group Enrollment
• Program Formats
• Developing a Program
• Diversity & Inclusion
• Strategic Transformation
• Program Experience
• Contact Client Services
• Campus Experience
• Live Online Experience
• Silicon Valley & Bay Area
• Digital Credentials
• Faculty Spotlights
• Participant Spotlights
• Eligibility
• International Participants
• Stanford Ignite
• Frequently Asked Questions
• Founding Donors
• Location Information
• Participant Profile
• Network Membership
• Program Impact
• Collaborators
• Entrepreneur Profiles
• Company Spotlights
• Seed Transformation Network
• Responsibilities
• Current Coaches
• How to Apply
• Meet the Consultants
• Meet the Interns
• Intern Profiles
• Collaborate
• Research Library
• News & Insights
• Program Contacts
• Databases & Datasets
• Research Guides
• Consultations
• Research Workshops
• Career Research
• Research Data Services
• Course Reserves
• Course Research Guides
• Material Loan Periods
• Fines & Other Charges
• Document Delivery
• Interlibrary Loan
• Equipment Checkout
• Print & Scan
• MBA & MSx Students
• PhD Students
• Other Stanford Students
• Faculty Assistants
• Research Assistants
• Stanford GSB Alumni
• Telling Our Story
• Staff Directory
• Site Registration
• Alumni Directory
• Alumni Email
• Privacy Settings & My Profile
• Event Registration Help
• Success Stories
• The Story of Circles
• Support Women’s Circles
• Stanford Women on Boards Initiative
• Alumnae Spotlights
• Insights & Research
• Industry & Professional
• Entrepreneurial Commitment Group
• Recent Alumni
• Half-Century Club
• Fall Reunions
• Spring Reunions
• MBA 25th Reunion
• Half-Century Club Reunion
• Faculty Lectures
• Ernest C. Arbuckle Award
• Alison Elliott Exceptional Achievement Award
• ENCORE Award
• Excellence in Leadership Award
• John W. Gardner Volunteer Leadership Award
• Robert K. Jaedicke Faculty Award
• Jack McDonald Military Service Appreciation Award
• Jerry I. Porras Latino Leadership Award
• Tapestry Award
• Student & Alumni Events
• Executive Recruiters
• Interviewing
• Land the Perfect Job with LinkedIn
• Negotiating
• Elevator Pitch
• Email Best Practices
• Resumes & Cover Letters
• Self-Assessment
• Whitney Birdwell Ball
• Margaret Brooks
• Bryn Panee Burkhart
• Margaret Chan
• Ricki Frankel
• Peter Gandolfo
• Cindy W. Greig
• Natalie Guillen
• Carly Janson
• Sloan Klein
• Sherri Appel Lassila
• Stuart Meyer
• Tanisha Parrish
• Virginia Roberson
• Philippe Taieb
• Michael Takagawa
• Terra Winston
• Johanna Wise
• Debbie Wolter
• Rebecca Zucker
• Complimentary Coaching
• Changing Careers
• Work-Life Integration
• Career Breaks
• Flexible Work
• Encore Careers
• Join a Board
• D&B Hoovers
• Data Axle (ReferenceUSA)
• EBSCO Business Source
• Global Newsstream
• Market Share Reporter
• ProQuest One Business
• RKMA Market Research Handbook Series
• Student Clubs
• Entrepreneurial Students
• Stanford GSB Trust
• Alumni Community
• How to Volunteer
• Springboard Sessions
• Consulting Projects
• 2020 – 2029
• 2010 – 2019
• 2000 – 2009
• 1990 – 1999
• 1980 – 1989
• 1970 – 1979
• 1960 – 1969
• 1950 – 1959
• 1940 – 1949
• Service Areas
• ACT History
• ACT Awards Celebration
• ACT Governance Structure
• Building Leadership for ACT
• Individual Leadership Positions
• Leadership Role Overview
• Purpose of the ACT Management Board
• Contact ACT
• Business & Nonprofit Communities
• Reunion Volunteers
• Ways to Give
• Fiscal Year Report
• Business School Fund Leadership Council
• Planned Giving Options
• Planned Giving Benefits
• Planned Gifts and Reunions
• Legacy Partners
• Giving News & Stories
• Giving Deadlines
• Development Staff
• Submit Class Notes
• Class Secretaries
• Board of Directors
• Health Care
• Sustainability
• Class Takeaways
• All Else Equal: Making Better Decisions
• If/Then: Business, Leadership, Society
• Grit & Growth
• Think Fast, Talk Smart
• Spring 2022
• Spring 2021
• Autumn 2020
• Summer 2020
• Winter 2020
• In the Media
• For Journalists
• DCI Fellows
• Other Auditors
• Academic Calendar & Deadlines
• Course Materials
• Entrepreneurial Resources
• Campus Drive Grove
• Campus Drive Lawn
• CEMEX Auditorium
• King Community Court
• Seawell Family Boardroom
• Stanford GSB Bowl
• Stanford Investors Common
• Town Square
• Vidalakis Courtyard
• Vidalakis Dining Hall
• Catering Services
• Policies & Guidelines
• Reservations
• Contact Faculty Recruiting
• Lecturer Positions
• Postdoctoral Positions
• Accommodations
• CMC-Managed Interviews
• Recruiter-Managed Interviews
• Virtual Interviews
• Campus & Virtual
• Search for Candidates
• Think Globally
• Recruiting Calendar
• Recruiting Policies
• Full-Time Employment
• Summer Employment
• Entrepreneurial Summer Program
• Global Management Immersion Experience
• Social-Purpose Summer Internships
• Process Overview
• Project Types
• Client Eligibility Criteria
• Client Screening
• ACT Leadership
• Social Innovation & Nonprofit Management Resources
• Develop Your Organization’s Talent
• Centers & Initiatives
• Student Fellowships

Uber UX Case Study

Manish Prajapati

People book cabs closest and faster on Uber.

1. Introduction to How I take up the challenge of UX design.

I am always learning new things in the design field because every day, something new emerges in this field, and I have always been curious about it, learning, practicing, and applying it in my work. I know UX design is totally different from UI design, and I learn and read blogs related to UX design, but I often think about something that is missing in my knowledge about UX design. Whenever I create any product design, I understand its fundamental use, but I do not feel confident as a designer, and I have not used the titles of UX/UI designer.

Therefore, I joined UX Anudeep 2-week Kickstarter Workshop to learn UX Design. In this workshop, I learned a lot of new things about UX Design, such as UX Design Fundamental Principles, Nielsen’s 10 Heuristic principles. Although I know Figma very well, UX Anudeep provided us with guidance on how to build a UI in Figma, and I also learned animation.

After that, UX Anudeep gave us one task and promised, “whenever you guys complete this task I will be sure your mind is very sure you become a UX Designer to solve any product problem.” Personally, these two exercises, Making Existing Products Better and the UX Kickstarter Design Challenge, changed my mind and unlocked something that was missing as a Designer.

2. My final solution.

In this section, I talk about comparing the original screen and redesigned the screens before and after usability testing.

Here, I discuss how redesign benefits the user.

In the final solution, I gave the Nearest Tab button with miles and hours because users can easily find the nearest and fastest cab.

Here, I discuss how redesign benefits the Business.

Here, use the active user's metrics principle because increase users, that means This feature helps the business with more and more users using the app daily.

3. I selected the app and the screens/flow.

In this exercise, I learn that the main point is to observe any mobile app or website and find my own perspective by thinking and answering questions. I learned to understand User Experience Design in layman’s terms.

I have used the same method in this app, such as an observer app, to find pain points, jot down all my questions, and try to solve those questions in my own way.

In this exercise, I learned about the Business Impact of UX Design and understood how I can create and enhance screens to maximize business impact. This exercise taught me how to impact businesses by creating a measurable impact through design.

I selected these screens because they enable users to interact with the app more flexibly and efficiently. As a result, users can engage with the app more frequently, which helps the business attract more daily users.

4. How did I evaluate the app screens, and what were the problems I identified?

In this exercise, I Learned user centric design from existing UX Design. I started thinking and jotting down common sense answering questions. I used and applied the heuristic principle in the cab selection screen.

Heuristic principles are a set of thumb that humans often use to make decisions or solve problems in a more efficient manner.

Here I found Problems in this screen identified through Heuristic principles.

Problem identified:

1 On this screen the user can’t change the route. Heuristic — Flexibility and efficiency of use.

2 Users are unable to see the distance/kilometers between two locations through a route. Heuristic — Visibility of system status.

3 User cannot click and select among the available cab drivers on this map area, they cannot access the driver profile card or see the cab cost.

5. How did I come up with ideas, and what solutions should be given priority?

Here I mentioned three common sense ideas, and then I had discussed with my colleagues and improvise those ideas.

Idea 1: In this screen, the local user can change route because Users' knowledge of the area can take shortcuts and rides a particular route and save time.

Idea 2: Can we Provide a click and section options each cab image on the map so User can select own chooses a vehicle driver?

Idea 3: Provide a nearest button so Users can Select nearest cab driver.

Based on the conversation I had with my colleagues, I decided to go ahead with Idea. Idea 3: Provide a nearest button so Users can Select nearest cab driver. I selected idea no. 3 because the user mainly thing the book cab and reached the selected location. I want to give the users an easy option that can save them time and get them where they need to go quickly such as by booking the nearest cab.

6. I did my ideas into low-fidelity prototypes.

How did I learn from the “Low-fidelity Prototyping” workbook I used.

When I selected idea no 3 and then I started to create a low fidelity wireframe on the paper. After that I clicked a photo drawing of the wireframe and uploaded in Figma then I created low-fidelity paper prototypes using the Figma desktop app.

7. I designed a high-fidelity prototype in real time.

Already I know User interface design very well, I do, so it is not difficult to create real time world high fidelity User interface design and Prototyping. I added the nearest tab button on the redesign screen so users can click this button and show all nearest cab or vehicle list view on the screen.

How it benefits the user?

Write according to the fundamental UX principles: Users can easily find a car from the nearest location and book it. Currently, lifestyle is so fast and this is the reason users find the nearest taxi on the location because, Users Hurry up, reach out target location and when he/she booked cab normally there is mention can arrive in 5 to 10 min but it is not possible and users can frustrate and waiting until the cab is not coming at the location. That’s why I have added the Nearest Tab button because users can easily find the nearest cab. The nearest Tab button option will give users the Flexibility and efficiency to Cab Book faster and nearest location.

8. Usability testing.

I have completed my final UI designs, and the screen is ready; therefore, after I went to meet my peer and colleague and asked him to please test my final high-fidelity wireframe and give me feedback on it, they gave me some points so I could understand their points and work on anything that could be improved in.

Insights got from Usability Testing:

1 The user is able to understand the Newarest button.

2 The user is able to determine which taxi will arrive at my destination the quickest or closest.

9. After Usability Testing redesign and improved designs.

I added the nearest tab button on the redesign screen so users can click this button and show all nearest cab or vehicle list view on the screen. In this design I added two details such as Km and Time adobe the rupee text.

9. Key Learnings.

I have completed the course of 2 weeks Kickstarter Workshops, and I passed through these 2 weeks of amazing. I have also gained valuable opportunities to enhance my skills, gain knowledge, and explore new areas of UX Design. This is possible because of UX Anudeep’s Kickstarter workshop.

Thank you 😊

Written by Manish Prajapati

I love to create beautiful things, I mainly work on UI/UX designing of Web and Mobile applications creating interfaces, products, and campaigns.

Text to speech