Overview (TL;DR)
AndGo is a predictive fleet servicing product for emerging consumer fleets: a responsive web app paired with a team of mobile technicians. Operations users run the day-to-day in it, scheduling services, managing predictive settings and tracking what each vehicle needs.
As the fleet scaled, those users outgrew working one vehicle at a time and started building workarounds to act on many vehicles at once. I led the research and design for dynamic vehicle groups: a way to create groups, move vehicles between them, and take bulk actions on a whole group.
1
Research
Understand user needs, constraints, goals and current workarounds
4
Test
Check whether the wireframes meet the user need
2
Define
Map user journeys and information architecture
5
Finalize
High-fidelity designs for development hand-off
3
Wireframe
Ideate solutions in low fidelity
Problem
When AndGo was small, managing vehicles individually worked fine. We started to see higher bounce rates and more negative feedback as the fleet sizes started to scale up and users needed to manage many vehicles at once. We needed to figure out what was falling short for these users and come up with a plan to address it.
How might we support operations users manage hundreds of vehicles across the United States?
Team and constraints
My role
I owned the work end to end, from research through high-fidelity hand-off.
The team
Product manager, back-end engineer, front-end engineer, data scientist, QA
Small user pool
A very small user pool. Fewer than 50 operations users existed on the product, so this was never going to be a large study. I aimed for depth over breadth.
4 weeks
From problem identification to shipped solution
Large amounts of data
Some of these operations managers were in charge of hundreds to thousands of vehicles, and each vehicle had a significant amount of associated metadata
Discovery and research
Because of the existing limited pool of operations users and the tight timeline I was only able to confirm and schedule interviews with two users to participate. As a result, I decided it was best to pair two methods.
My thinking
With only two users, interviews alone could have given me what people say they do. The audit let me check that against what they had actually built.
Method 1
Product audit
I combed the system for the workarounds already in use. Users were grouping vehicles geographically and dividing those groups between operations users. Imperfect, but a clear picture of real behavior
My thinking
Workarounds are a signal. When users bend a system to do something it doesn't support, they're showing you the feature to build, so that's where I started.
Method 2
User interviews
An hour with two operations users, guided by three questions:
-
What actions do you want to perform on vehicles in bulk?
-
What are the limits of the current system?
-
How static are groups once they exist?
What I learned: The solution needs to enable users to...
-
create and manage different types of groups
-
move vehicles between groups
-
take actions on a group’s vehicles in bulk
-
see a group’s vehicles quickly
User Journey:
Once I had a solid understanding of the needs, I started mapping out the actions users would need to take in user journeys. I used this exercise to ensure I could clarify which steps needed to be taken, the order they would need to happen in, and the feedback loops required.
Information Architecture:
With the user journeys completed, I was able to then able to determine which existing pages in the site needed to be updated, as well as where we needed new pages created.
Explorations
I started with low-fidelity wireframes, aiming to make grouping information prominent and easy to manage. The key screens were the fleet management page, the vehicle details page and creating a new group. Here are some examples:
Options and trade offs
We also explored a few other structures, such as:
Smart grouping or automated presets.
We as a team chose this more manual option to start because of the complexities of building a more automated feature in this time, and because so far our research suggested the need for more individualized management than what we felt could intuitively be provided to everyone for this first pass.
Groups as just filters
We also explored just having the groups be custom filters in the management table, but we decided these were likely properties someone might want to be able to see while looking at a vehicles details page, or making other decisions about the vehicle. It made more sense to tie them to a property on the vehicle.
Testing the wireframes
I printed the wireframes and ran paper-prototype sessions with both users. They worked through three tasks: filter the vehicle list to a single group, create a new group, and find which groups a given vehicle belongs to.
My thinking
Paper was the right fidelity for a four-week timeline: cheap to build, easy to change in the room, and it let me test the flows before anyone wrote code.
Change 1
Creating or editing groups was hard to find, so I added an Edit section on the vehicle details page.
Change 2
Groups were presented differently from other filters, so I changed how they appear in fleet management to match the other metadata in the app's existing filters.
A quick note:
This design process happened before the wide use of AI tools. If I were to go through this again now, I would likely prototype with something like Claude Design (or Claude Code if we had the structure set up for it) and not the paper printouts.
Released solution
The first release covers the full group workflow. Each part answers one of the needs from research.
Create and many different types of groups
Create group flow
Move vehicles between groups
Edit groups per vehicle, from the vehicle details page
See a group’s vehicles quickly
Group filter in fleet management, consistent with the app’s other filters
Take actions on a group in bulk
Bulk add to group, bulk change group
Impact and result
High adoption rate with over 75% of vehicles added to groups over the next 3 months. We also received positive feedback from several users
Iteration: making it work on mobile
One thing I did not anticipate was how often users would want to access this admin feature on a mobile device. While the feature was designed to be fully responsive, two parts still needed rethinking: the table and the forms.
The Table
Selecting vehicles is central to groups, but on mobile users had to scroll across many columns, and the column they select from sat far from the information they were deciding on.
Before: open scroll
After: tabs with a locked first column
Replaced open horizontal scroll with tabs, so users always know where they are in the table.
Reordered columns and locked the first one, so users can select a vehicle from any column.
The forms
The desktop forms didn't translate to a small screen. I made two changes:
-
Enlarged touch targets. Some elements look the same but are much more forgiving to tap, like the dropdown selector.
-
Made the mobile modal fill more of the screen, so people see a fuller, less cluttered form.
Mobile Table
Mobile Form
My thinking
On a phone, the hard part wasn't the layout, it was keeping people oriented. Tabs and a locked column fix that.
Reflection and next steps
What I'd do differently
With only two users in my research pool I couldn't validate beyond a small sample. In ideal circumstances I would have included a wider group.
Additionally, with advances in current design technology I would lean more heavily on AI tools to speed up prototyping and iterating so I could put additional options in front of the few users we had access too (and perhaps be able to better send quick prototypes to users digitally, potentially increasing the number of users willing to participate.
Next Steps
-
Learn which groups operations users actually create
-
Establish a baseline for how they create and manage groups
-
Use that baseline to find where to improve