State of California DMV Department of Motor Vehicles

Designing a unified DMV platform for 27M+ California drivers

California's DMV services were spread across more than 15 disconnected applications, forcing drivers to navigate separate systems for licenses, vehicles, payments, and status updates.

I led the product design of MyDMV, a unified account experience that brought these services into one platform. The work included defining the dashboard asset management model, life cycle states, shared interaction patterns, and design system foundations needed to support millions of drivers over time.

Project Details


Lead Product Designer

Lead Product Strategy, Interaction Design, Prototyping, System Architecture, and Visual Design from Early Definition through Implementation.

Cross-functional Team:

UX research, product management, front-end and back-end engineering, accessibility, executive stakeholders

24 months

Phase one: 16 months of product definition, design, and development.
Phase two: continued feature expansion and platform optimization.

The Core Challenge

MyDMV had been designed around individual transactions: renew a license, register a vehicle, update an address. But drivers do not experience these tasks in isolation. They manage a collection of licenses, vehicles, notices, payments, and deadlines—each with its own status, urgency, and next action.

Because the services lived across more than 15 disconnected applications, users repeatedly entered the same information, lost visibility into transaction status, and struggled to understand what required attention.

The product challenge was not simply to redesign those services. It was to create a shared account model that could organize them into one understandable experience.

Why the Fragmentation Mattered

Only 23% of DMV users completed tasks digitally. Many abandoned online transactions or moved between channels because they could not confirm status, understand next steps, or recover from an incomplete process.

That fragmentation created consequences on both sides:

  • Drivers experienced repeated data entry, uncertainty, and preventable office visits.

  • DMV teams absorbed avoidable support calls and operational overhead.

  • Every new digital service introduced another disconnected workflow instead of strengthening a shared platform.

Our goal was to increase digital completion by making the system feel continuous, predictable, and trustworthy.

This better connects business impact to user experience.

System Constraints

MyDMV had to work with the DMV’s existing backend systems. Those systems had been built to support individual transactions, not a persistent account that could manage multiple assets and lifecycle states.

That constraint shaped the product strategy. We could not redesign every underlying service at once, so we created a shared experience layer that could:

  • Represent licenses, IDs, and vehicles consistently.

  • Translate backend states into language users could understand.

  • Surface urgent actions without overwhelming the dashboard.

  • Allow additional services to join the platform over time.

This turned a technical limitation into a clear product architecture.

Prioritizing the First Platform Capabilities

Working with research and product management, I reviewed the user stories across licenses, IDs, and vehicles and evaluated them by frequency, user impact, technical feasibility, and dependency.

Instead of treating each request as a separate feature, I looked for repeated needs across the platform: identity, status, deadlines, next actions, confirmation, and recovery. Those patterns helped us determine which capabilities belonged in the shared system and which could remain specific to an individual service.

This prioritization defined the first release and created a foundation that future DMV services could reuse.

Starting With the Most Complex Entry Point

We began with Add Vehicle because it represented the most complex entry point into the new account model. Unlike a license or ID, a vehicle could include multiple owners, different eligibility conditions, conflicting records, and several possible failure states.

I mapped the complete flow with product and engineering to identify where the system needed to validate information, prevent invalid records, explain errors, and preserve progress.

This work established the rules for how assets would enter MyDMV and gave the team a reusable model for future services.

Add / Remove Vehicle — Entry Flow into the Garage Card system

Pre-submission validation states that prevent invalid Garage Card creation

Turning Disconnected Vehicles Into a Manageable System

I designed My Garage as the central place for drivers to understand and manage their registered vehicles. Each Garage Card represents one asset and answers four immediate questions:

  • What is this vehicle?

  • What is its current status?

  • Does anything require attention?

  • What can I do next?

Rather than sending users back into separate transaction flows, the card keeps status, deadlines, notices, and actions together. This gave users a persistent mental model for managing multiple vehicles and created a structure that could scale as more services entered MyDMV.

Defining the Information Model Behind Each Asset

The Garage Card needed to support many combinations of identity, status, deadlines, warnings, and available actions without becoming visually inconsistent or difficult to scan.

I decomposed the experience into reusable pieces—registration identity, lifecycle status, notices, primary actions, secondary actions, and contextual links—but the goal was not component reuse alone. The structure ensured that every asset communicated the same hierarchy:

  1. Identify the asset.

  2. Explain its current state.

  3. Surface what requires attention.

  4. Provide the appropriate next action.

This model allowed the interface to remain predictable even when the underlying services and business rules differed.

Product Decision:

Where should asset status live?

Status could not belong only to the Garage Card. Licenses, ID cards, notices, and future assets all needed to communicate states such as pending, expiring, expired, suspended, or completed.

I defined a shared lifecycle model that separated:

  • The underlying business state.

  • The user-facing status label.

  • The visual treatment.

  • The actions available in that state.

This prevented each service from inventing its own interpretation and made status behavior consistent across the platform.

Registration identity component. A single component using a status collection to control states.

Making Lifecycle States Consistent Across the Product

Each lifecycle state needed to retain the same meaning wherever it appeared—on a Garage Card, an identity card, a dashboard task, or a confirmation message.

I worked with engineering to define shared state rules and connected those rules to design tokens for color, emphasis, messaging, and interaction. This reduced duplicated logic and ensured that users saw the same visual and behavioral cues across services.

Connecting Status to the Right Action

A status label is only useful when users understand what it means and what they can do about it.

For each lifecycle state, we defined:

  • The message shown to the user.

  • The level of urgency.

  • Whether an action was required.

  • Which action should be primary.

  • What happened when the user could not complete the task online.

These rules prevented contradictory experiences—for example, showing an asset as expired while still presenting an unavailable renewal action—and helped product and engineering teams handle edge cases consistently.

Prioritizing What Drivers Need to Do Next

The dashboard brings licenses, vehicles, notices, and active transactions into one actionable view. The design challenge was deciding how much to show without recreating the complexity of the underlying DMV ecosystem.

Research showed that users could have three to seven active tasks at once. Displaying all of them gave equal visual weight to urgent renewals, informational notices, and lower-priority actions.

I introduced a prioritization model based on urgency, deadline, and task status. The dashboard surfaces the highest-value actions first and uses progressive disclosure for the rest. This helped users understand what required immediate attention while keeping the overall account manageable.

Result: Reduced order-status support calls by over 30%.

Product Decision:

How many tasks should appear at once?

Showing every active task increased cognitive load and made routine information compete with urgent deadlines.

I prioritized tasks based on urgency and user impact, then used progressive disclosure to preserve access to lower-priority items. This created a stable dashboard hierarchy that could accommodate changing policies and account conditions without requiring a redesign.

Designing for Confidence in High-Stakes Moments

DMV tasks often involve deadlines, fees, identity documents, and legal requirements. A confusing status or missing confirmation can create genuine anxiety because users may not know whether they are compliant or whether a transaction succeeded.

I designed the experience to reduce that uncertainty through explicit status messaging, visible completion states, predictable next steps, and clear recovery paths. The goal was not to make the DMV feel playful. It was to make the experience feel calm, dependable, and complete.

Bringing Clarity and Humanity to a Government Product

Government products still need care, clarity, and visual quality. I used typography, spacing, restrained color, and focused illustrations to improve comprehension and reduce friction without distracting from the task.

Every visual decision supported a functional purpose: highlighting urgency, confirming success, separating information, or helping users recover when something went wrong.

This project changed how I think about platform design. The hardest problem was not creating individual DMV flows—it was defining the shared rules that allowed dozens of services to feel like one product.

The work required balancing user needs, policy constraints, legacy technology, accessibility, and long-term scalability. By treating status, identity, task prioritization, and asset management as platform capabilities, we created an experience that could expand without forcing users to relearn the system every time a new service was added.

The result was a more understandable digital DMV experience:

  • Digital adoption increased from 23% to 42% within six months for license and vehicle renewals.

  • Support calls related to order status decreased by more than 30%.

  • The platform now provides a unified experience for more than 27 million eligible California drivers.

This is more reflective of your actual product contribution than the current “design decisions ripple at scale” language.

Reflection

+42%

Digital adoption increased from 23% to 42% in the first 6 months for license/vehicle renewals

-30%

Support call volume decreased by over 30% for order status inquiries ("Where's my license/registration?"

27M+

The platform now serves 27M+ eligible California drivers with a unified experience

Next
Next

Starbucks