Custom video request
Redesigning how fleet managers find and request vehicle camera footage — from a spec that couldn't work to the most-used feature among dual-camera customers.
- My role
- Sole Product Designer partnering with Product, Engineering, Legal, Customer Success, and leadership. Led workflow definition, interaction design, stakeholder alignment, and implementation through launch.
- Product
- OnStar Vehicle Insights
- Outcome
- Shipped in OnStar Vehicle Insights, carried into the consolidated platform
Footage only existed if the system decided something happened.
OnStar Vehicle Insights gave fleet managers visibility into their vehicles, but access to video was limited to clips the system automatically captured when it detected an event — a hard brake, a collision, or another predefined trigger. If nothing triggered an event, there was no way to retrieve footage, even though fleet managers regularly needed to review moments the system couldn't anticipate.
The spec asked for the one thing a fleet manager couldn't give.
The original requirement asked for the opposite of what a fleet manager could realistically provide: an exact timestamp, with no other context, in exchange for a single 30-second video clip. In practice, that meant already knowing — to the second — when something had happened, at which point there was rarely much left to learn from the footage.
I brought two versions to the first design review after kickoff: the one the requirements described, and an alternative built from patterns already in the product. Instead of requiring an exact timestamp, a manager could narrow by location using the trip snapshot markers already on the map.
Product chose the original specification. The “creepy factor” label had come out of Legal's response to an earlier attempt at the problem and was still in the air, and Product was adding friction pre-emptively rather than spend the argument later. My alternatives stayed deliberately inside components and patterns OVI already had, which I thought made them easy to say yes to. Anything past the PRD was going to get the same answer. I disagreed and said so, but was directed to stay within the confines of the PRD to keep the project moving — so I built the requested version properly.
The version written to the PRD was approved by the product manager and his manager, and moved forward on that basis. It wasn't until it was shown to the VP of Cloud & AI / Digital Experiences that it stalled — he didn't buy the solution, for exactly the reason I'd flagged from the beginning: the friction to find footage was still too high for fleet managers to get what they needed. That pushback became the opportunity to solve the real problem instead of the original specification.
Rethinking the problem.
Because I had raised the concern early and brought alternative thinking with me, I was given room to design without technical or business constraints — not just to land on the ideal experience, but to solve the problem for our dual-camera customers: identify the ideal experience first, then work backward toward something feasible.
My first concept assumed infrastructure the platform didn't yet have, including live video streaming. While it wasn't immediately buildable, it clarified something important: users didn't need live video — they needed multiple ways to narrow down a specific moment in time. That insight became the foundation for the rest of the experience.
Designing the experience.
I worked with Product and Engineering to evolve the ideal concept into something that could realistically ship, bringing the director, the VP, and the engineering leads along as it took shape. The final workflow allows a fleet manager to select a vehicle, narrow the search by date and time, cross-reference the trip on a map to identify the correct location, and preview a still image before requesting footage.
The simplest implementation stored every requested clip in one centralized page, disconnected from the vehicle it belonged to. I pushed for a different approach: every vehicle received its own Clips page, using the existing vehicle list as the primary way to browse, search, and filter footage — matching how fleet managers already thought about their vehicles instead of forcing them into a separate organizational model.
Requesting a clip wakes the vehicle's camera, which can take up to two minutes if it's asleep. Rather than leaving users waiting on a loading state, the experience relies on cached trip data so users can immediately browse trips and identify the moment they need. Trips without available video are flagged up front, and the camera wake-up happens in parallel while users select a date, trip, and location. In many cases, the camera is ready by the time they've made a selection — if not, users can still submit a request without a preview when they already know the exact moment they need.
The design I brought to Legal did more of what they had objected to, not less.
By the time it reached Legal, the design had approval from Product, Engineering, my director, and the VP. It also went further than the version that had drawn the “creepy factor” label: time, location, and still images from both the road-facing and in-cabin cameras, all available before a manager requested any video. The objection was never the map itself — it was that the product kept adding ways to watch the driver. Legal pushed back on the same grounds.
Rather than debating opinions, I reframed the conversation by asking whether there was an actual legal or regulatory requirement preventing it. If there was, I'd design around it. If not, we could focus on mitigating the concerns instead of removing the capability altogether.
I also shifted the discussion toward the business problem we were solving. This wasn't simply about tracking drivers — it was about protecting company-owned vehicles worth $50,000–100,000 that could cause significant damage if misused.
- Every video request would generate an email notification.
- Every request would be recorded in an audit log.
- Video requests would be limited to four minutes of footage.
Separating hard requirements from subjective concerns, combined with stronger business framing and meaningful safeguards, ultimately earned approval for the experience.
The full decision flow, worked out before a single screen got built.
Vehicle states, camera availability, and request outcomes — resolved on the board first, so the interface only had to express decisions that were already made.
Reference — timeline and scrubber interactions
A single 30-second clip request became a new way to search, request, and manage footage.
The workflow shipped in OnStar Vehicle Insights and was later adapted into GM's new consolidated commercial platform, demonstrating that the interaction model held up well beyond the original product.
“This is an OVI feature worth the wait.”
Customer Success ManagerAdapted into the new consolidated platform
