All work Product Design · Design Leadership · Ford

From initial-team designer to design lead on a $200M-impact platform

As an early product designer on Ford's initial CVDOS team, I helped shape the product from a blank-page stage into a system used by 1,000+ internal engineers — and grew the design practice around it.

Role

Early Product Designer → Design Lead

Team

Joined the initial team and helped grow a small design practice

Timeline

2020–2023

Platform

Connected Vehicle Data Operating System (internal Ford)

1,000+

engineers adopted

~$200M

annual cost savings

~20%

lift in conversion

from research-led fixes

50+

research participants

CVDOS guided request flow on the DID tab with progressive filters and developer notes — The guided request surface that made complex data selection understandable: progressive filters, visible choices, and notes that helped engineering implement edge cases correctly. (De-identified.)

The challenge

Enormous data, locked behind specialists.

There was no product yet — just a strategic bet that a platform could make customer-defined vehicle-data pipelines scalable and automated. I was the first designer on it.

Ford generates enormous volumes of connected-vehicle data, but turning that raw signal into usable insight was slow, bespoke, and locked behind specialists. Teams that needed vehicle data to make engineering and cost decisions had no consistent, self-serve way to request, manage, and receive it.

No self-serve path

Every data request went through specialists — slow, bespoke, and impossible to scale across teams.

No product to build on

A blank page: no flows, no IA, no patterns. The experience had to be defined from first principles.

Every need felt unique

Requestors each described their data need differently, yet the underlying process could be standardized.

Flexibility vs. automation

Users needed room to express intent while staying on rails the platform could actually automate.

Adoption was fragile

If defining a request felt like paperwork, engineers would route around the platform entirely.

Scaling scope

Patterns set early had to stay right as the platform — and the team — grew around them.

My role & approach

What was defined vs. what I defined.

This is where the work actually started — identifying what didn't exist yet and taking ownership of it.

Given: the strategic bet

Make vehicle-data pipelines scalable
Automate customer-defined requests
Serve internal engineering teams
Reduce reliance on specialists

I defined

Information architecture
Earliest end-to-end request & order flows
Reusable UI + interaction patterns
Research & usability test plan
The design practice & team as it scaled

Key insight

Adoption would live or die on the request experience — if defining a data request felt like paperwork, engineers would route around the platform. It had to feel like a tool, not a form.

Talking to requestors revealed the core tension: every team's data need felt unique, but the underlying process could be standardized. The design challenge was to give users enough flexibility to express their request while guiding them onto rails the platform could automate.

The solution

Not just screens — the system's foundations.

Every screen was a strategic decision, not just a deliverable. Here's the reasoning behind the core surfaces.

Feature 01

Data visualization that builds trust

Problem

Submitting a request was only half the job — teams also needed to understand whether data was arriving, whether deployment was healthy, and where issues were emerging.

Decision

Designed an order-health view that paired high-level status summaries with trend charts, so engineers could scan overall health first and then drill into details and filters only when needed.

Tradeoff

I prioritized fast interpretation over dense analytics on the main screen, using simple visual breakdowns and clear labels instead of overwhelming users with every possible metric at once.

Outcome

The platform made request health legible: VIN status, deployment status, and raw-data quality could be reviewed in one place, increasing user confidence in what the system was doing.

CVDOS order metrics dashboard with VIN status, deployment status, and order-health bar charts — Order health and trend visualization.

Feature 02

Request & order flow

Problem

Teams had no consistent way to define and place a data request — each one was bespoke and specialist-driven.

Decision

Designed the customer request and order flow from first principles — from early Sketch explorations through higher-fidelity iterations.

Tradeoff

Guiding users onto standardized rails meant constraining some free-form flexibility — resolved by progressive, guided steps.

Outcome

Became the request pattern the platform still uses — and the vocabulary later products, including CVDE, extended.

CVDOS data-elements selection page on the DID tab with developer notes for progressive guidance — Request / order flow with progressive guidance and dev notes.

Feature 03

Guided data definition

Problem

Every team's data need felt unique, so a rigid form would break — but total freedom couldn't be automated.

Decision

Built guided, additional-info steps that let users express intent while collecting exactly what the platform needed to automate delivery.

Tradeoff

More interaction steps up front, in exchange for requests the backend could fulfill without specialist intervention.

Outcome

Requests felt like a tool, not paperwork — the difference that kept engineers on the platform instead of routing around it.

CVDOS data-elements selection flow with developer annotation notes for edge cases — Guided flow with developer-facing notes for constraint handling.

Feature 04

A reusable component system

Problem

A growing platform needed repeatable building blocks — adding items, managing requests, tracking status — not one-off screens.

Decision

Established a visual and interaction language with reusable components and patterns the whole platform could grow from.

Tradeoff

Required upfront systems design instead of shipping screens faster — an investment that compounded as scope multiplied.

Outcome

The foundation later products — including CVDE — extended, keeping the experience coherent as the team scaled.

CVDOS reusable card components and interaction states — Reusable component patterns and states.

Outcome & impact

A platform 1,000+ engineers rely on.

1,000+

internal Ford engineers adopted the platform

~$200M

annual cost savings the platform contributed to

~20%

lift in conversion

from research-led improvements

50+

research participants across interviews & usability

Established the design foundation and team practice that later platforms — including CVDE — built on.
Set the flows and vocabulary the platform still uses today.
Turned a specialist-only process into a self-serve product engineers actually adopt.

Reflection

Designing for a system that doesn't exist yet.

CVDOS taught me to make decisions that stay right as scope multiplies — because on the initial team, every early pattern compounded.

Systems-first beats screen-first.

Being there from inception meant designing not just screens but the flows and vocabulary the platform still runs on.

Adoption is an experience problem.

The platform succeeded because defining a request felt like a tool, not a form — a bet I made early and defended.

The mindset carried forward.

That systems-first thinking is what I carried into CVDE and, eventually, into building AI tools on top of the same platform.