Hire Us

"Uber" case study

In this showcase, we observe Uber's idea in a time when this service didn’t exist. We don’t know how actual founders organized the ideation process, but let’s see how we would run it with the BRIDGeS framework back then.

This approach should help us analyze Benefits, Risks, and Issues for the potential stakeholders to create a new mobility experience on the market. This is a great case to show how BRIDGeS is applied for complex contexts with multiple stakeholders, who have different needs and risks along with those in common.

To get familiar with the BRIDGeS framework, please check the step by step description page and the page with instructions on how to prepare for the BRIDGeS session.


Problem description

We start describing the problem by mentioning Subjects and their Descriptors (Benefits, Issues, Risks, Domain Knowledge, Goals). Our team members should have a deep understanding of the context to have a productive session and generate quality content for the right solution.

This is how the Problem Space should look after the problem description is done:


Uber Company

First, we define all Subjects, which represent stakeholders involved in the context — those who will benefit from the future Solution. The main stakeholders and users of the Uber service are the Passengers and Drivers. Our key stakeholder is the Uber company, which has the intention to identify the problem and resolve it.

We can diversify Subjects and go as deep into segmenting as a particular case requires - by geography, specific features, interests, etc. In this showcase, we will stick to three Subjects: Passengers, Drivers, and Uber Company.

According to the required color and shape coding, we denote Subjects as big green rectangles.


Each Subject is analyzed through Descriptors. We focus on the needs and current experience of the Passengers and Drivers. However, the main goals originate from the business, so we should also add some input about the company itself.


Here we mention the existing problems that result in a bad experience for the passengers:

  • Clunky ordering experience: raising one’s hand in the street or waiting on the line with a call center is far from being a great experience;
  • Price prediction: some taxis have counters, but you still struggle to guess the total price at the moment of your departure;
  • Price negotiation: you never know what the end price is;
  • Call center communications: staying on the line sometimes seems to last forever;
  • Rush hour busyness: in the rush hour, the prices go up, and a car is hard to find;
  • Precise meeting point: knowing the exact address can be rather challenging and still does not guarantee that a driver finds you.

We put this context on red cards and place them on the board next to the Passengers card. Since the card space is limited, messages must be short and readable.


Here we look for the potential needs of the passengers. What value can they get from the future Solution?

  • Predict time to destination point: a passenger does not know the route a driver will take or the traffic situation;
  • Predict the time of taxi arrival: operator can tell the approximate time of arrival, but one cannot predict it for sure;
  • Simple tip experience: difficulty finding cash for the tip; weird and outdated card readers;
  • Simple cancelation process: operator is hard to contact; slow operators;
  • Driver-Passenger communication: sometimes the call is not the best option;
  • Fair price, prices may be too high or variable based on distance and trip time;
  • Flawless payment process: need to prevent delays at the destination point.

Potential issues that passengers may experience in the future are:

  • Personal safety: passengers don't know the driver controlling the car, and drivers never know the passenger getting in the car;
  • Cash payments: neither drivers nor passengers know how much the fare will cost until the trip is done, so passengers might not be carrying the right amount of cash and drivers might not have appropriate change.
Domain knowledge

There are things to consider besides Benefits, Risks, and Issues: think about special conditions or additional information about the Subjects involved, as well as the general context. This is called Domain knowledge. For example, 75% of passengers are unhappy with the service - that’s a fact worth noting.
Domain knowledge can be crucial and have a significant influence on the final solution.

With that knowledge in mind, we continue moving forward through the process, carefully considering each Subject one by one and noting every Benefit, Risk, and Issue as we go. We note the findings next to the appropriate Subject: Driver or Uber Company.

  • Getting a taxi licence: not all drivers have appropriate licences, especially if being an Uber driver is not their primary job. It takes time and effort to obtain the licence;
  • Not enough rides while on duty: drivers never know how successful a day will be and how much money they'll earn in a shift.
  • Easy to join the service: drivers can register with minimal paperwork;
  • Quick money: some people consider ride-sharing as a temporary source of income while searching for a permanent job;
  • Car provided by a company: if drivers don't own a car, they can still drive a taxi;
  • Additional income source: drivers can earn extra money in addition to their primary job by working evenings or weekends.

Each Subject has its own descriptors. However, some apply to multiple Subjects. In our case, some of the Benefits, Risks, and Issues for Drivers also apply to Passengers. Some of these include driver-passenger communication, fair price, flawless payment process, call center communications, rush hour congestion, precise meeting point, and personal safety.

We place cards with common descriptors in between the Driver and Passenger cards. This is another perk when it comes to using cards and the board - you can manipulate the objects in any way, any time, throughout the whole BRIDGeS process.

Uber company

The Uber company is our key Subject which initiates the changes and has an intention to transform the taxi industry by creating a service with an exceptional user experience. The anticipated results of the future Solution - or Goals - are to serve 75% of the car-sharing market and Change the way taxi services work.

Conquering new locations and Minimizing support expenses would be the benefits for the Uber company. In terms of potential risks to the business, authorities will likely Require licences for taxi services.



Now that we have mentioned all Subjects and Descriptors, it’s time to set the proper focus for our further steps. We should prioritize all Risks, Issues, and Benefits in the Problem Space and set aside non-essential tasks. Applying MoSCoW prioritization technique, we simply go through each Benefit, Risk, and Issue and tag them with the relevant markers, defining what Must, Should, Could, or Won’t be done.

The descriptor type doesn’t influence the priority - a Benefit, for example, can still be of higher importance than an Issue or Risk. What does the “time prediction” feature matter to passengers? Considering the main reason passengers call a taxi is to get to their destination on time, having a feature to predict the length of their trip is a Must. Price negotiation is something that needs to be improved, but it’s less critical since it does not influence the choice to get a taxi. We mark the Price negotiation as Could.

The same way we mark each Benefit, Risk, and Issue for other Subjects in our Problem Space.


Solution variations

Universal Mobile App
Separate Mobile Apps
Web App

Now that everything is beautifully set up in the Problem Space, we are ready to head to our Solution Space and start brainstorming potential high-level solutions to address all prioritized Benefits, Risks, and Issues.

An app might be a solution to the issues, considering the needs of the passengers, drivers, and the business itself. Since these are different platforms, and audiences with different needs and goals, we can make separate mobile applications for passengers and drivers, a universal mobile app for both, or a web app.

We place the cards with our high-level Solutions on the board in the Solution Space. According to the BRIDGeS color-coding, these are big blue cards.


Solution breakdown

This is where the magic happens. Now that we have several high-level solutions, we split them into smaller semantical blocks, classified as epics and nested tasks.
We go through the Benefits, Risks, and Issues for the passengers and drivers in the Problem Space and cover each with "epics" or "tasks" in the Solution Space.

Considering all mentioned descriptors, we define the following epics: “Ride”, “Payment”, “Communications", “Security” and “Account”. Now color coding is different - each epic and its tasks should have its own color.

Then we depict our epics through the small tasks referring to the features an app should have. E.g.: “clunky ordering experience” - “ride request”, “precise meeting point - “map” etc.

Next, we go through each descriptor and make sure it is covered with a relevant task. A single task can cover several benefits, issues, and risks at a time, and vice versa — one descriptor can be addressed with multiple tasks.

Here is how it looks on the board:

It is possible that more Issues, Benefits, and Risks come to mind during the solution ideation process, and we end up adding more cards to the Problem Space. BRIDGeS framework gives flexibility, which allows being more creative.

After all of the epics and tasks are mapped on each and every descriptor, we prioritize them using MoSCoW framework. Often the priority level of the tasks is inherited from the descriptors they cover. However, we might have a situation where one task needs to be completed before the team can tackle another, even if the business value of the first task isn’t high. In that case, the priority goes up.


Now that we have a bunch of ideas, we need to decide where to begin. Our high-level solution, beautifully organized into epics and tasks, is just the beginning of the magic.

Now, we transform the epic stack into a roadmap view. We take epic cards for a colored legend and sequence tasks by priority, all while considering other factors like time of execution, resource availability, etc. With this, our team will be ready for product development in no time.

It looks just as simple as this:


This showcase is designed to show you how the BRIDGeS framework helps create a product. Now you should have a better understanding of its main components and the overall process.