GouBlue app

#ux #ui #ios #android

Project overview

GouBlue wanted to build an MVP of a new product. The challenge was to create, develop and release a carpooling mobile app from scratch in a timeframe of 3 months. The product was going to be targeted to enterprises and with a strong focused on sustainability—trying to reduce CO2 emissions produced by commuting while decreasing the number of parking spaces needed in offices outside of big cities. To incentivise the use of the app by the employees of the companies, each time an employee uses the app, they will receive BluePoints that they can exchange for benefits depending on the company. For example, a cheaper and better parking slot at the office because you are sharing your car with other coworkers.

Due to the fast release, the development team was going to use the Ionic framework. This was a limitation on the things that were possible to do and the final quality of them. The app is not public since it's a B2B business app, and GouBlue makes it available only after signing a contract.

My contributions

The project had very limited resources, and a small self-managed team consisted of two software engineers and one product designer—me.

I had the responsibility of translating the business objectives into the product, and I took part in the decision-making process to establish strategy, limits and scope of the app. I carried out all the activities related to design: I conducted team workshops, user interviews and user tests; I prototyped the app, creating the UX, UI and illustrations—the icons are part of the Ionic framework package; and I was part of the app's QA leading heuristic evaluations.

Understanding the problem

Due to the tight time to market, I decided to run personal interviews with two different kind of personas that were employees of large companies outside of big cities. People that were already going to work in his own car—Drivers—, and people who went to work by public transport but were interested in an alternative method—they are the probable users that will transition to be Riders with the release of the app. It was not possible to find people who were already sharing a car to go to work, that would have produced high valuable insights. After the interviews, I prepared a workshop with the team to further understand the problem. The output was two initial user scenarios—Driver and Rider—with which we were able to align, detect and discover some key problems, technical restrictions, solutions and ideas.

Learnings, discoveries, assumptions and decissions

One of the key business metrics for GouBlue and its customers is how much CO2 they can save when a car is being shared to commute. They also need to report it as part of its business model. Also, another important part of its business is to try to save as much space as possible in the parking dedicated to employees. Doing that, companies don't need to rent and maintain so much parking spaces, reducing their costs.

Therefore, it was necessary to build the best and most efficient trip routes while having all the available cars as full as possible. We decided to run the matching algorithm in one batch—at the end of the previous travel day—including all the people and trips booked. Analysing all this data, it was possible to assign to each user the most optimised route taking into account time, cost and how much CO2 they save.


One of the initial assumptions was that commuting usually happens at the same time every day, and people know at what time they will go to work the following day. This assumption was mostly confirmed, but some of the interviews also shown that some days, people go to work in a different hour. Either because one day of the week they have a special meeting or because they choose to leave the workplace earlier.

This brought the idea of having a recurring trip booking as a norm, but with the possibility of adding, editing or removing individual trips. From the initial two options to bring this to life—a calendar view and a timeline view—we tested and decided to continue with a timeline view. Not only it was more viable—technically speaking—but also a more detailed view of the days was needed. Something that was not possible to achieve with a simple calendar view. Due to the initial scope of the product, we allowed adding only two trips per day—going to work and going back home.

Misaligned user goals when booking a trip

When you go to work, the time you leave your house is important. But even more important is the time you arrive at work. Usually, you need to be at work at 9:00. The time you want to arrive at work defines when you leave your home. In the other side, the time you know you leave your workplace to go home defines when you arrive home. You know that you are leaving your work at 17:00.

This reversed logic in the user goals was something we had to include in the booking trip experience. At the same time, we had to deal with technical limitations in Google's API and time. Also, adding a different pattern in a UI component would have led to more time of development. We decided to do a trade-off and reuse the standard components we were using everywhere. Instead of selecting when the user wants to arrive to work, we show the time when the user arrives at work depending on the time he chooses to be picked up at his house. In this way, although not ideal, the user still has the information he needs.

Flexible roles to increase optimisation

I already mentioned GouBlue's objective of delivering the most efficient route. With that in mind, it was necessary to deal with a problem we were facing in the first tests of the algorithm. Depending on the number of Drivers and Riders, not only some routes could be highly inefficient or include empty seats, but in some cases, the Drivers or Riders wouldn't find anyone who shares the car with. We added flexible roles in the app for the users who add a car—and it is shown only when you have added it. They can choose between being only a Driver, only a Rider, or one of those two options but with the open possibility of being the other one.

Recurrent and consistent events

Already mentioned before, we needed to include a way to book recurrent trips to work that usually happen consistently. Also, because of this consistency in the trips, we decided to manage all the user addresses saving them in a reusable library automatically. In most of the cases the trips happen from home to one unique office—sometimes two—and they are not going to change often. This allows the user to use his addresses easily. We also prepared this library for eventually support trips between offices.

Onboarding and booking experience

The first time a user books a trip, he is guided through a wizard that helps him to set up his addresses, add a car and licence permit if he has, etc. Doing all these things is also possible from the Account tab, but many of the initial user tests pointed out that users were a little overwhelmed with all the available options. We created an onboarding flow to guide them. This flow also allowed us to simplify the booking trip screen for users that didn't have a car by removing some of the components in that screen—for example, the role component that only Drivers use.

Trip experience

To make official CO2 saving reports, it was necessary to track the position of everyone involved in the trip with GPS. The trips can also work offline, but in that case, they don't count as tracked and valid, and users don't get BluePoints either the company a report from the CO2 saved.

Dynamic cards to show trip information

The simple cards in the timeline transform themselves in a more detailed view of the trip once the matching algorithm has been run and the routes have been calculated and set. They show all the relevant information available, including a chat.

This always happens first in tomorrow's trip section. The following day, the same card will move to today's trip section in the timeline.

Temporary group chat as main space for all the trip updates

We knew that adding a chat was going to be necessary so that Riders could communicate with their Driver—many users were concerned about privacy, giving their contact numbers to other coworkers they may not know. With that in mind and trying to simplify the whole system, we use the same chat to give any update about every specific trip. Each trip has its own temporary chat, that is live only for one day. Examples of these updates include saying when is the time to prepare and leave your house to pick up the Riders or when to get ready to be picked up.

User account

In the Account tab was necessary to give relevance to how many BluePoints the user has and incentivised his usage. We also added the equivalent number of trees needed for cleaning the CO2 the user has saved using GouBlue app. This two elements demonstrated to build a stronger connection and relation between the user and GouBlue brand and vision, at the same time that incentivise the usage of the app.

Here, it is also possible to find, add or edit all the settings needed, although thanks to the onboarding wizard, they are not initially set up in this section of the app.

Personal Learnings

GouBlue app is a product that was born with a ton of constraints and limitations. But that push the team to be creative, resolutive and make a viable product fast. With limited time, limited resources and limited development capabilities, our solution had to include limited templates, logic and components and being as simple as possible. I'm sure that it could have done even more simple, but the result was an initial success given how users react, use the app and the feedback we received—sadly this project had to be frozen in next phases due to new Covid situation...

In this project, I personally enjoyed how we embraced the appetite concept from Basecamp work process instead of scope planning. That helped us to achieve our goals and deliver on time.

The success of the project was achieved thanks to clear and direct communication and collaboration of every stakeholder involved. Not only showing clear limitations and cutting down expectations in the project but also providing different feedback and ideas to it.


Since the project is an MVP, it is obvious that many things can be iterated and improved. Some examples are how the time to arrived to work is shown to the user, improved the explanation of how the app works so that users understand it better, and improve how the details of the trip are shown inside of the chat.

It would be a big impact for users also to allow to book last-minute trips like in many mobility apps, but without removing the daily batch so that better and more efficient routes are calculated. Having these last-minute bookings would be better than going alone with your own car.