Work

About

Work

About

Building out a fleet management system

Nearly every company that runs a service has a fleet of vehicles or machinery at the helm of their operations.

SafetyCulture is a workplace operations app, best known for its inspection and task management features. It's loved by customers like Piccolina Gelateria who use it to handle icecream deliveries with their fleet of trucks, and Virgin Voyages, who ensure that their line of cruise ships are safe to set sail.

Company

Company

SafetyCulture

My role

My role

Product Designer

Timeline

Timeline

Aug 2023 to Jan 2024

Platform

Platform

Web app + mobile + IoT

The team

The team

2 Designers
12 Engineers
2 PMs

The opportunity

The success of SafetyCulture had largely been due to the flexibility of our platform being suitable for businesses across different industries. Our product was broad, but not deep. As our growth expanded, our business wanted to go deeper into verticals in order to capture more enterprise customers. During my time at SafetyCulture, we noticed many use cases in the fleet management sector popping up. While our product enabled our customers to conduct regular inspections and initiate actions against their fleet, there were key functionalities missing to effectively track, maintain, and forecast work with their fleet in SafetyCulture.

The solution

We formed a new team by merging two existing teams at SafetyCulture: the Assets team and the Sensors & IoT team. With the combined expertise and resources of these teams, we began researching and building a roadmap of features to facilitate preventative maintenance, utilisation reporting, and a workflow builder that pulls together features across our entire platform.

Some key challenges

As we moved towards providing deep solutions for verticals, how do we ensure a balance between a prescriptive versus a flexible offering?

  • Our teams were quite siloed and features weren't always working with each other. How could we contribute to pulling parts of the product together in a seamless way while making sure that the things we build didn't contribute to more "design debt"?

  • In a similar vein, many other teams were thinking about similar features. How could we all work together instead of duplicating, often inflexible, work?

  • The scope of the work was large, so we ran the risk of building lots of features that don't go deep enough to meaningfully solve our customers' problems.

The discovery process

  1. Evaluation our starting point

  1. Understanding our customers

  1. Understanding customers

  1. Visualising the insights

  1. Defining the problem

  1. Crafting the solutions

Evaluating our starting point

I'm determined to begin a project by understanding how we got to where we are (our current state), but also learning from adjacent and past projects, features and research. I believe that our past knowledge can help us get to future solutions faster while helping us stay cognisant of repeating old mistakes.

To begin, we gathered everything we already knew about this space:

  • We had just released a few product experiments as part of an initial telematics project. These included automated data capture of Odometer and Run time readings from third party integrations and a map view showing the live GPS location of vehicles. We had a small pool of customers to get direct feedback from.

  • We had began integrating with a number of third party asset management systems so that users can bring in their assets into our platform. We wanted to understand why our customers integrated with those apps and how their ecosystem of work works.

  • Existing UX patterns in the platform that could support a fleet management solution.

  • A library of customer interviews and feedback from early adopters of our Assets feature.

  • And, of course we had some cold, hard numbers to go off of.

Understanding the customer

My PM and I set out to speak to a small group of customers to begin to understand their pain points. I love speaking to customers because I find that assumptions I have in my head can often be wrong. At the same time, I gain a deeper understanding of how we fit into our customers' ecosystem of work. Some of our favourite methods:

  • Customer interviews

  • Site visits

  • Gathering feedback from Account Managers and Support Agents

  • Community forums

Understanding the customer

My PM and I set out to speak to a small group of customers to begin to understand their pain points. I love speaking to customers because I find that assumptions I have in my head can often be wrong. At the same time, I gain a deeper understanding of how we fit into our customers' ecosystem of work. Some of our favourite methods:

  • Customer interviews

  • Site visits

  • Gathering feedback from Account Managers and Support Agents

  • Community forums

Grouping our customers into functions

During the customer research phase, it was clear that the opportunity for fleet management was endless. There were so many pathways that we could go down including; preventative, inventory management, planning and predictive analysis, breakdowns, procurement, accounting, and more. Each of these features could be entire platforms in their own right, so we needed to be strategic about what we would tackle.

What would make the biggest impact to our customers tomorrow, while still set us up with a foundation to explore the rest of the opportunity space over a long period of time?

To answer this question I sorted the customers we spoke into business function personas. By seeing the spectrum of businesses we serve, we can get a better understanding of their unique requirements, common themes across business types and choose a strategic product solution that either;

  1. Begins with the requirements of one persona to keep us focused. It's always helpful to start small, nail a specific customer need and then go wider as we iterate. Or;

  2. Covers the ground of all different types of businesses. On the other end, flexibility is something we boast about, so we could go wide and ensure that we've addressed all the possibilities.

Why functional personas?

As an organisation, we had tried to do a good job of understanding personas based on user behaviour segmentation, I found that these were more useful for onboarding new users or when we were building out features for different archetypes, such as your administrator versus your end-user.

For this project, the crucial piece missing is our understanding of the types of businesses we serve and the type of work they needed to do.

Building for different kinds of business needs

When we build solutions, in the past we got into the trap for building for one kind of business model. This resulted in parts of our product working super well for those customers, but barely functional for others. When speaking to customers we heard so much conflicting feedback that we realised that our solution must be flexible enough for multiple types of business functions.

A visual map of customer insights

As we spoke to customers over the weeks, I began mapping out a journey. I wanted to use this artefact as a way to communicate how our customers' work, and where our product could fit into their ecosystem. This would help our team start to clarify our roadmap with a strong customer lens. I love to create rough journeys using whiteboarding tools such as Figjam. They become organic collaborative spaces where anyone can "pin" an interesting insight, whether it's a screenshot, photos from a site visit, images, statistics and quotes from customers.

Grouping our customers into functions

During the customer research phase, it was clear that the opportunity for fleet management was endless. There were so many pathways that we could go down including; preventative, inventory management, planning and predictive analysis, breakdowns, procurement, accounting, and more. Each of these features could be entire platforms in their own right, so we needed to be strategic about what we would tackle.

What would make the biggest impact to our customers tomorrow, while still set us up with a foundation to explore the rest of the opportunity space over a long period of time?

To answer this question I sorted the customers we spoke into business function personas. By seeing the spectrum of businesses we serve, we can get a better understanding of their unique requirements, common themes across business types and choose a strategic product solution that either;

  1. Begins with the requirements of one persona to keep us focused. It's always helpful to start small, nail a specific customer need and then go wider as we iterate. Or;

  2. Covers the ground of all different types of businesses. On the other end, flexibility is something we boast about, so we could go wide and ensure that we've addressed all the possibilities.

A visual map of customer insights

As we spoke to customers over the weeks, I began mapping out a journey. I wanted to use this artefact as a way to communicate how our customers' work, and where our product could fit into their ecosystem. This would help our team start to clarify our roadmap with a strong customer lens. I love to create rough journeys using whiteboarding tools such as Figjam. They become organic collaborative spaces where anyone can "pin" an interesting insight, whether it's a screenshot, photos from a site visit, images, statistics and quotes from customers.

Defining the problem and outcome

At the beginning of 2024, we got together as a team to facilitate a workshop to generate a roadmap for a fleet management packaged solution. Together with the insights generated from our customer research and my journey map, myself and our triad leadership team ran a workshop to define the key problem we were solving and where we wanted to be.

Using the lean UX canvas

Together as a team will used the Lean UX Canvas to build out a quick plan. It helps I found that a UX canvas helps our team get on the same page about what really matters: the user’s needs and the project's outcomes. It breaks down the process into clear steps, making it easier to move quickly, test ideas, and adjust based on learnings. I like using a modified canvas that focuses on a few key steps to keep things simple:

  • The current state business and customer problem

  • The ideal business and customer outcome; and

  • How we get from the current state to the ideal outcome

Once we had clarity around what the problem was and where we wanted to go, we could now start to build out our roadmap of solutions.

Communicating the solution

As a team, we all wrote down the features we would need to build in order to satisfy our business and customer outcomes. Then I put together some mixed-fidelity wireframes within the framework of a customer journey. These designs were intended as communication tools — to make sure that we were speaking the same language within our own team, and to illustrate the vision when we were speaking to external teams and stakeholders. They serve to communicate a concept, not to brief delivery.

What's next

Well, now we execute on the plan :) The vision was unfortunately years away in reality, so we needed to prioritise what we would build. We knew that certain pieces of the vision were foundational — they must be built first in order to 'unlock' an important part of the workflow. That's why we made the decision to begin delivering the first iteration of this project: meter readings. Collecting meter readings from inspections meant that we could then support triggering activities off specific data points. You can read more about the delivery in my other case study on meter readings.

Let's work together
to build the future

Email me at reeyanna@gmail.com

Upgrade your Web presence with Framer

Email me at reeyanna@gmail.com