Field Services solution
Cobli is an end-to-end fleet tracking solution. This is about how I helped build its Field Services product.
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.
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
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
Deep dive into the Design process
Communication channels, competitors analysis and user interviews made it possible to understand pain points
+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
Three rounds of user testing and remote testing though Maze to validate whether the designs would solve users problems
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.
Research
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
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.
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
Inputs
What are other companies' requirements - e.g., what did they need to input beyond the address?
Optimization
What's an optimized route look like at other products?
App
What can app users do? Mark an activity as done or failed and getting directions to an address were some options
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
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.
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
Architecture
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.
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.
Result
Comac
Board Solutions
Eletro universe
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
Takeaways
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!
