Overview

One tool to run the whole platform

Cox Automotive operates a large portfolio of dealer-facing products — Dealertrack, VinSolutions, vAuto, Dealer.com, and more. Each one had grown up independently, with its own way of representing a dealership, its own admin interface, and its own support workflow.

That meant every time an implementation or support team member needed to set up or troubleshoot a dealer, they were bouncing between multiple tools, re-finding the same entity in each one, and manually reconciling data that should have been the same everywhere. There was no authoritative record of what a dealer looked like across Cox.

COAT (Commons Operations and Administration Tool) was built to fix that. It became the single entry point for understanding, setting up, and troubleshooting anything dealer-related on the OneCox platform. I owned the design from day one through years of iteration as new capabilities were added.

The Problem- No shared reality

Before COAT, there was no internal tool that understood a dealership as a whole. If you wanted to know which Cox products a dealer was using, what their account IDs were across those products, and how they fit into a dealer group hierarchy — you were piecing that together yourself.

"Setting up or troubleshooting a dealer for a composed solution is error prone and can take a significant amount of time, scaling up in cost the more products are involved."

The downstream effects were real: slow onboarding, inconsistent setups, duplicate records, and support teams spending significant time just locating the right data before they could actually solve a problem.

My Role

Full ownership, from blank page to shipped product

I was the only designer on this project for its entire lifespan. That meant working directly with product and engineering from the initial concept through launch and then years of continued iteration as new capabilities — new tabs, new flows, new tools from other teams — were integrated into COAT.

Because COAT is a host for other teams' tooling (Common Org, Common User/Bridge, Connected Customer, Common Vehicle Inventory), a big part of my work was establishing patterns and standards that each adopting team could build within. Designing the system, not just the screens.

The work spanned research, information architecture, interaction design, and working hands-on with engineers to ship. There were no handoffs to another designer. If something shipped, I designed it.

The decisions that mattered

Three areas in particular required the most design thinking — search, entity hierarchy, and org creation. Each one had significant complexity underneath the surface.

01 — Search

A search that works for power users

COAT's search needed to handle a large, complex dataset across tens of thousands of dealer entities. Simple name-matching wasn't enough. I designed around a full query language that supports wildcards, fuzzy matching, boolean operators, proximity search, and field-scoped queries — exposed through a progressive disclosure pattern so casual users see a clean search bar while advanced users can access the full documentation.

Results surface name, location, OEM relationships, linked solutions, and business status at a glance — reducing the need to drill into individual records just to orient yourself.

02 — Entity Overview

The full picture of a dealer, finally in one place

The overview page was the core design challenge: how do you show a dealer's complete identity across a dozen products without overwhelming the person reading it? The answer was a two-column layout — dealer facts on the left, business operation IDs organized by product on the right — so both sides of the question ("who is this dealer" and "what are they set up for") are answerable without scrolling back and forth.

The page also surfaces OEM associations, operational status, linked Common Org entities, and a full change history — giving support teams the context they need without requiring them to open another tool.

03 — Hierarchy View

Making dealer group structure legible

Dealer hierarchy is genuinely complicated. A dealer group can contain dozens of franchises across multiple states, each with their own entity IDs, OEM relationships, and operational status. Designing a hierarchy view that was scannable — and actionable — required a lot of iteration.

The solution uses an indented tree structure with inline address and status context, a hover panel that surfaces OEM details without requiring navigation, and quick-access Overview links for each node. The currently-viewed entity is highlighted in the tree so users always know where they are in the structure. It was technically one of the most complex views to build, and getting the information density right took multiple rounds.

04 — Org Creation

Turning a manual process into a guided flow

Creating a new Common Org entity was previously a manual, error-prone process. The org creation flow I designed bridges two systems: it lets users search Client Hierarchy (CACM) data to find the right source record, review the full details before committing, and then create the corresponding Common Org entity with the correct business operation ID mappings pre-populated.

The two-tab structure (Client Overview / Hierarchy) gives context at both the individual dealer level and the group level, so users can confirm they're working with the right entity before taking action. It was the flow I was most proud of — it took something that required deep institutional knowledge and made it something a new team member could do confidently.

Principles that shaped the work

Progressive disclosure over overwhelming completeness

COAT's users range from new implementation specialists to veteran support engineers. Rather than designing for the most complex use case, I layered complexity — clean surfaces for orientation, deeper detail on demand.

Context before action

Almost every flow in COAT involves acting on real dealer data. I consistently prioritized showing enough context — hierarchy, status, IDs, relationships — before any action UI appeared, so users weren't guessing.

Designing a system, not just screens

Because other teams integrated their tooling into COAT, I had to establish patterns that could scale. Tab structure, entity overview layout, search behavior — these became shared conventions that new modules could follow.

Density in service of speed

The users of this tool are professionals doing time-sensitive work. I designed for density — fitting more information into fewer pages — rather than the kind of whitespace-heavy simplicity that would've slowed them down.

What I took from it

COAT was unlike anything else I've worked on because it had no predecessor. There was no existing workflow to improve, no legacy UI to modernize. The process that existed before COAT was people figuring it out on their own, across too many tools, with no shared source of truth. That made every design decision feel high stakes — we were building the mental model from scratch.

Working across multiple years and multiple integrating teams also taught me a lot about designing for extensibility. Every pattern I established had to be something another team could build within. When a new module landed in COAT, I wanted the team building it to feel like they had a clear template, not a blank page.

The other thing I carried forward: internal tools deserve the same design rigor as external ones. The people using COAT were doing real work with real consequences. Ambiguous UI wasn't just annoying — it caused mistakes. That raised the bar on clarity in a way I found genuinely motivating.