Field Services solution

Cobli is an end-to-end fleet tracking solution. This is about how I helped build its Field Services product.

Mockup screens

Project overview

Cobli is a fleet management solution that analyzes IoT data, providing visibility, security, and control of physical operations. I was part of the team responsible for developing its Field Service product.

The goal was to boost fleet productivity with GPS tracking and dispatching, protect their drivers, and keep end customers informed.
From the business side, the team's goal what to increase Average Revenue Per User (ARPU), one of the company's OKRs.

140+ users
~32% adoption rate

Role & process

I've used the Double Diamond Theory as a basis, understanding that design frameworks aren't linear and don’t guarantee results.
As the only Product Designer in the squad, I led the end-to-end design process.


Product Designers
Addie Meira

Product Management

Anna Lima, Thiago Victorino


Adalberto Hoffman, Arthur Passos, Bruno Scholl, Caio Scalon, Leonardo Gajardo, Matheus Cunha, Rodrigo Midea, Rômulo Moraes


Chief Product Officer
Diego Pereira

Chief Technology Officer

Lucas Brunialti

Design Director
Nathalia Albar

1 Designer, 2 PMs, 8 EngineersProduct features: route planning, tracking & analysis, driver's appDesign framework

Deep dive into the Design process


Communication channels, competitors analysis and user interviews made it possible to understand pain points

Problem framing

+30 job stories written and prioritized together with Product Manager and Tech Lead using the "dotmocracy" framework


User flows, trade-offs, wireframing and cross-collaboration to provide the best experience

User testing

Three rounds of user testing and remote testing though Maze to validate whether the designs would solve users problems

QA & Metrics

Reviewing pull requests on Github and creating Mixpanel events with Product Manager to wrap the product

Field Services at a glance

Cobli's Field Services product allows users to plan their fleets' shortest, fastest, and most efficient routes. Accurate driver's ETAs enable end customers to know precisely when they can expect their delivery. In the end, drives can share instant proof of service with fleet managers to validate work.



To understand how to improve the user experience while creating routes at Cobli's dashboard, the Product Manager and I got to interview +30 fleet managers from different areas via Google Meets. Some of the findings were

Poor version
Cobli's route planner feature was designed for a specific use case, so most customers couldn't use it

Route types
Users wanted to manually plan their route instead of having an optimized one.

After this, I talked to 05 drivers via WhatsApp, which made me understand that

Map view is the most important thing to the driver
Since getting to the customer is vital to do the service, knowing how to get to it is what matters to the driver, and the map is the best tool to do it.

ETA matters
ETA helps drivers understand fleet manager expectations

Desk research

At this step, I looked for past user research while looking for user feedback through Slack channels. All this material was used as a basis for my CSD Matrix, gathering Certainties (what is already known), Suppositions (hypotheses raised), and Doubts (what is still unknown but needs to be investigated) about the product we were creating. 

At this step, I've what key insights such as: 

We knew what kind of data fleet managers needed to track

We were unsure about what fleet managers wanted to while using the product

We needed to find out how fleet managers reacted during unexpected events.

Market analysis

It was time to see what the market was doing. What do big players like Samsara, OnFleet, and Keep Trucking do to give their users the best field services experience? 
Some of my questions were

What are other companies' requirements - e.g., what did they need to input beyond the address?

What's an optimized route look like at other products?

What can app users do? Mark an activity as done or failed and getting directions to an address were some options

Insight: Job Stories

I've gathered with the Product Manager and the Tech Lead so together we could define user tasks at the product, taking into account technical viability, product goals, and user needs. 

After writing +30 job stories, we used the "dotmocracy" framework to prioritize ten.
Some of the reasons why we worked with job stories were

The user is right up front
Job stories make you work with users' motivation and context

Focus on the WHY
Job stories give as much importance to who, how, and why.

Next, the Product Manager and I ran a survey through Typeform to understand which job stories were more important to the users. The most voted would have priority at both the design and development stages.

In less than a week, we got 80 replies that made us realize that what matters are

Real time data
+80% of users preferred to see information in real-time and on an individual level (by route or driver)

Planned vs. Executed
Users want to have a comparison between planned and executed routes

Users requestsFleet sizesFleet segmentsJob stories examples

Flow & architectue

I must admit that at this point, I only structured user flows after developing the visual design, which got me in a lot of trouble! I think it's important to acknowledge mistakes, and that is why I even wrote an article on Medium about this experience:

→ "Não deixe o fluxo para trás" (pt-br)

Okay, so after going back a few steps and doing user flows, I designed user flows for both MVP and the final product. The team could see everything we wanted and what we could do in the period.

I've worked on some agreements with Engineering and Product teams, such as:

The MVP needed
To allow the fleet manager to match the right driver to the correct route with centralized visibility into service details.

The MVP didn't need
To create recurring routes due to technical complexity.

When route status is in progress
Users can check it in both lists and map view - and, while in list view, the screen must display the route's name, progress, the vehicle associated, and date of execution.

When route status is planned
Users can delete it, associate a vehicle to it and check its details.

Route planning flowDriver's App flow

Wireframing the solution

I mocked up some wireframes on Figma, giving shape to the project and defining the visual hierarchy. 

Then, I gathered feedback from the Engineering, Design, and Product teams. Together we walked through the product's structure without getting sidetracked by design elements such as colors and images. 

This step gave me insightful insights, such a

Route's type is what determines which information needs to be requested from the user

Use cases
I've designed two proposals for the route viewer: one separating the routes of the day and all the rest and the other dividing the routes into past, present, and future. It helped me understand better the job stories of each use case.

Dashboard <> App
To increase Driver's App adoption, the product must remind the fleet manager to associate a vehicle with each and every route

Validating the Design

I conducted three rounds of usability testing sessions, talking to 15+ users to validate whether the designs would solve their problems. 

During the session via Google Meets, I observed how they interacted with the prototype. It helped me understand what was going wrong and what we needed to change. Some of the learning was:

Visual Design: Date picker over tabs
Users prefer a date picker when checking for their routes instead of having a tab for each moment (present, future, past)

Content Design: "Delayed" and "Planned"
These route statuses needed to be clarified for all (!) of the participants

After analyzing the results, I got to redesign the screens. Then, I used Maze to run three more usability tests with +50 users in just a few days.

User testing screenshot 1User testing screenshot 2User testing screenshot 3
Notion screenshot with Mixpanel eventsGithub example

Handoff, QA & Metrics

After finalizing the designs, I created all the documents required for the development team to bring the product to life, ensuring all the details and assets were available. Some of the reasons I believe why the handoff was so smooth are

Communication between Design and Engineering was clear and frequent
Every new project stage was aligned with developers through regular design reviews, slack channels, shared screenshots, and Figma notes

The solution was built together
Development challenges were taken into account while I was designing the solution

I also structured a list of Mixpanel events and metrics with the PM to check user behavior and analyze the product's success.

Mockup screens
Total amount of users
Routes created
Adoption Rate
Events in the App
"Driver's productivity increased a lot!"
"My main benefit is knowing for sure if the delivery is being done"
Board Solutions
"Perfect and super beneficial for my company"
Eletro universe
"Better than other products - even though it's just an MVP"
jf fishing

Next steps

What users do
Checking how the first users interacted with the product already gave us insights into what could be improved, such as comparing planned with what was accomplished through the map view and the possibility of changing the route's start time

Develop more features
The rounds of research created a backlog for the non MVP version of the product, such as import spreadsheet and route editing


Get to know your user
It was the first time in the company that a designer conducted research and a usability session with drivers, the company's secondary user. It allowed me to have a lot of insights into things that can be done to increase Driver's App adoption

... and your colleagues!

Knowing who your colleagues are as people and what's going on in their lives can make a massive difference in project development.

Nothing great is built alone

If you have an idea in mind or just want to make a new friend, feel free to ping me!