Unlearn, Then Build

The Business Problem

OnStar Vehicle Insights had been GM’s fleet management platform for years. It worked. But GM’s commercial division was undergoing a significant transformation — relaunching as GM Envolve, a one-stop B2B and B2G partner designed to bundle vehicles, connected technology, financing, and services under a single umbrella. The product needed to grow with that ambition.

The next generation of the platform had to serve a market GM’s existing tooling hadn’t fully addressed: smaller fleets, EV-forward operations, public service entities. Police departments. Municipal services. Regional delivery operations. These weren’t the 500-truck long-haul carriers that dominated enterprise fleet software. They were businesses with five to fifty vehicles that needed serious telematics without enterprise complexity.

My directive: reference what existed, understand it deeply — then reimagine it. Don’t copy it. That’s a harder brief than it sounds.

My Role

Product Designer (Contract, 8 months). I owned vehicle management and driver management surfaces end-to-end — from discovery through design handoff — embedded in a 4-in-the-box model alongside business, PM, and engineering lead.

Discovery: Mining What Already Existed

The most valuable early move was getting close to the PM on the existing OnStar Vehicle Insights product. Their development process had years of embedded user insight. I treated OVI as a research artifact rather than a starting point to ignore — what users had struggled with, what they’d asked for repeatedly, what workarounds they’d developed.

I partnered with our UX researcher to determine what we needed to test as we iterated. Stakeholder interviews were extensive — and not just within my immediate team. Our design group was newer inside the organization; I made it a priority to build relationships laterally, gleaning insight from anyone who touched the customer or the product. That served two purposes: it made the work better, and it expanded design’s footprint in a space where design hadn’t always had a seat.

Competitive analysis covered Fleetio, Samsara, and others — not to replicate their conventions, but to understand where the gaps were, particularly for the smaller fleet segment we were targeting.

I also co-chaired a Figma committee with another product designer, focused on workflow infrastructure — shortcuts, plugins, templates, shared libraries. In a team still building its design maturity, that kind of process investment compounds over time.

The Hard Problem: Unlearning

I spent five years at J.J. Keller designing fleet management software for the largest carriers in North America — XPO, Schneider, fleets running hundreds of semis across state lines. I knew that problem space deeply. Maybe too deeply.

GM Envolve was the inverse. Five vehicles, not five hundred. A city’s police fleet. A public works department retrofitting telematics into existing vehicles. A regional delivery operation transitioning to EVs. The scale was smaller, the user context was different, and the design patterns I’d spent five years internalizing didn’t transfer cleanly — and in some cases actively pointed me in the wrong direction.

The unlearning was intentional and uncomfortable. I had to hold my JJK instincts at arm’s length and ask what this user actually needed, in this context, at this scale. Giving myself permission to stay out of Figma until I genuinely understood the problem from zero was the discipline that made the work better.

The Product

Envolve was built around GM’s connected vehicle ecosystem — EVs with embedded ELDs, and retrofit kits for existing fleets. Telematics data surfaced directly in the product: vehicle health, location, driver behavior, fuel and EV charging data. This wasn’t generic fleet software pulling from a third-party feed — the GM hardware integration was a genuine differentiator.

Vehicle Management

The vehicle management surface served two distinct user contexts simultaneously: a fleet manager needing a macro view across their entire operation, and the operational reality of individual vehicle status, assignment, inspection history, and live telematics. For EV fleets specifically, charge state and range were designed as first-class data points — not buried in a detail drawer. Fleet managers running EVs have a fundamentally different operational cadence than ICE fleet managers. The UI had to reflect that.

Driver Management

Drivers in Envolve weren’t passive records — they logged hours, conducted pre- and post-trip inspections, and drove assigned routes. The surface had to work for the fleet manager assigning and monitoring and for the driver completing their workflow in the field. The thread that tied both contexts together was making the fleet manager’s view a live reflection of driver activity — not a static record updated after the fact.

Outcomes

The product launched as part of the GM Envolve umbrella — which has since been renamed GM Fleet. By the time I transitioned off the engagement, the platform was in active contract negotiations with multiple public service entities, with at least five customers migrated and live.

Feedback in customer sessions was consistent: ‘This makes more sense.’ When you’re evolving a product people already know, that’s the signal that matters most.

The Broader Context

GM’s commercial division went through multiple name changes in a short period — GM Fleet to GM Envolve and back to GM Fleet — which tells you something about the organizational velocity I was operating inside. Navigating that kind of flux while doing foundational product work requires a designer who can stay focused on user problems when the business context keeps shifting. That’s the muscle this engagement built.

What I’d Do Differently

Two things. First, I’d push harder for instrumentation from the start — defining what successful adoption looked like in measurable terms before design began. We had strong qualitative signal. A quantitative baseline would have made design’s impact more durable inside a large org still calibrating how much to trust it.

Second, I’d make the unlearning visible. The metacognitive work of recognizing my own domain bias and actively correcting for it was some of the most valuable design thinking on this engagement — and I mostly did it in my head. Making that process explicit would have modeled something worth repeating.