Delivery
A separate analytics dashboard asks the user to stop, switch context, re-find the vehicle and interpret — while they are already looking at the listing in question.
Chrome extension
VINSAVVY · IN-CONTEXT INTELLIGENCE · SHARED DATA MODEL · SCALABLE DATA NORMALISATION
VinSavvy: Intelligence Where the Decision Happens
Designing a browser extension, dealer workspace and admin console on one vehicle-data model, for dealerships pricing against a live market.
My role: Product UX/UI design across all three surfaces: the shared scope model, interaction design and admin workflows. Engineering owned data collection, decoding and the normalisation pipeline.
Project status: Completed product design across three surfaces. Production implementation has not been independently verified for every feature described.
- Market intelligence designed for the competitor’s own page
- One scope model shared across three surfaces
- Per-dealership data normalisation designed as admin configuration
The 30-Second Version
VinSavvy aggregates and decodes vehicle data scraped from dealership websites so dealers can price against their local market. The backend handled collection; my design problem was delivery and comparability.
- Previous approachIntelligence in a separate dashboardDesign directionIn-context intelligence on the competitor’s page
- Previous approachSeparate tools with separate definitionsDesign directionThree connected surfaces, one scope model
- Previous approachRaw scraped labels, per-site vocabularyDesign directionCanonical data model via admin configuration
- Previous approachReporting where a vehicle ranksDesign directionTarget rank as input, required price as output
Aggregated data only becomes intelligence at the moment someone has to decide something.
What the Product Is
The product design spans three surfaces. The extension contains five tools; the workspace and admin console provide the supporting workflows.
SurfaceWho uses itWhat it does
Dealership sales and inventory staff, on any VDP
One surface holding five tools — VDP History, Watchlist, Stealth Mode, VIN Market, Price Action — overlaid on the page being viewed
Dealer workspace
Dealership users and managers
Depth behind the extension: saved vehicles, history, competitive sets, team, settings, multi-dealership switching
Admin console
VinSavvy platform administrators
The supply chain: regions, dealer groups, dealerships, moniker mapping, user licensing and subscription status
The Problem
A given vehicle configuration can be listed by several dealerships in the same metro region at different prices. The useful question for a dealer is not what a car is worth in the abstract, but where their price sits against the units a shopper would compare it to.
The data to answer that is spread across competitor websites, and VinSavvy’s backend collects and decodes it. Two problems stood between that data and a decision:
Comparability
Dealership websites do not share a vocabulary. What one site presents as a discount, another splits across rebates, add-ons and dealer fees. Scraped numbers are not comparable until something reconciles those labels.
Discovery & Constraints
No user research was conducted for this project. Four inputs informed the design, each of which also set a constraint.
Domain input
- Sessions with the founder, an automotive industry expert, on how dealers price against a market, what a competitive set means in practice, and which numbers carry weight on a sales floor
- Constraint (per founder input, not observed): the users are dealership staff working at pace rather than analysts, so numbers have to be readable at a glance and defensible in front of a customer
VDP structural analysis
- Analysis of real dealership VDPs across brands: where price components sit, how inconsistently they are labelled, and how much space an overlay can occupy without obstructing the page
- Constraint: the extension renders on pages I do not control, at unpredictable layouts and widths, and must be minimisable, movable and dismissible
Competitive audit
- Review of existing dealer inventory-pricing and market-intelligence products, including the browser-extension tools in that category, focused on three specific patterns: how each expresses a vehicle’s market position, how each defines the comparison set, and whether each exposes how much supply a comparison rests on. The first two are well-established conventions worth following; the third became an explicit requirement in this design: show supply counts per scope column rather than only a single market figure.
Engineering constraints
- Sessions on the scraping and decoding pipeline: what data arrives reliably, what arrives partially, and what the interface must therefore never present as complete
- Constraint: price component labels differ per dealership website, so comparability depends on a per-dealership mapping
- Constraint: a four-level hierarchy — metro region, dealer group, dealership, user — with permissions, seat licensing and subscription status attached at the dealership level
- Constraint: the same metrics appear in a narrow extension panel and a full-width workspace table, so one component and data language had to serve both
Three Explored Directions
Dashboard only
What it wasA conventional analytics workspace; the dealer looks up vehicles and pulls reports
Outcome and reasoningRejected — requires leaving the decision context and re-finding the vehicle. The data was already being collected; the unsolved problem was delivery.
Extension only
What it wasEverything inside the browser panel, no separate product
Outcome and reasoningRejected — a constrained panel cannot hold competitive-set configuration, saved history, team management, licensing or platform administration.
Extension + workspace + admin, one model
What it wasIn-context intelligence, backed by workspace depth and an admin data layer, sharing one scope model
Outcome and reasoningSelected — each surface does what it is structurally suited to, and shared scope keeps the numbers consistent across all three.
One Data Model, Three Lenses
The decision that holds the product together is the scope model. Every market metric in VinSavvy is expressed against the same three columns: My Inventory, Competitors, Region. Supply counts, price ranks, lowest and median and highest price — all read the same way in the extension’s VIN Market panel and in a full-width workspace table, because the entities behind them are the same objects.
Those entities flow in one direction. The admin console defines the dealership, its region, its group and its competitor pool. The workspace lets a user compose competitive sets from that pool and save vehicles against them. The extension reads both, and renders the result on whatever VDP the user is looking at.
My Inventory
Competitors
Region
Design principle, and what it is meant to produce
- Principle: one segmentation for all market metrics, defined once and reused. This is a property of the design and can be verified by inspecting the surfaces.
- Intended effects (hypotheses): that users learn the frame once rather than per screen, and that a new metric can be introduced without inventing a new segmentation.
Designing Price Action Backwards
The brief for this tool was market pricing data. How that data met the user was a design decision, and it went through two explorations.
The first followed the conventional pattern: show the vehicle’s current discount ranking alongside the market range, and let the user work out a new price from it. Laying that out exposed the problem — the screen answered a question the user had not asked and left the actual task undone, since they still had to pick a candidate price, work out the rank it would produce, and adjust.
The second inverted the inputs and outputs. The design hypothesis was that working backward from a target rank could be more useful than iterating through candidate prices. So the user sets the discount ranking they want, and the Optimum Pricing Metric returns the discount percentage, discount in dollars and sell price required to reach it — with the market context it was calculated against on the same screen: lowest, median and highest price, and supply across the three scope columns.
Report the rank, and the user still has to do the work. Take the rank as input, and the product does it.
Making the Data Problem an Interface Problem
The hardest design work in this project is not a screen a dealer ever sees.
Scraped price data is only comparable once the platform knows what each dealership website means by each number — which field is MSRP, which line is a genuine discount, which is an add-on. Automated inference could not be trusted as the sole source of truth here, because a wrong mapping silently corrupts every metric downstream.
Engineering owned the normalisation pipeline itself. What I designed is the configuration model and interface that feeds it: when an admin adds a dealership, they map that site’s vocabulary through moniker fields — an MSRP moniker, add-on monikers, custom entries — stored alongside the dealership’s region, group, brands, competitor set and subscription terms. The intent is that the per-site knowledge enters the system through an admin form rather than through code, so that adding a dealership does not require a development change. This case study shows the configuration design; its effect on production onboarding and engineering effort has not been measured.
Designing for Enterprise Reality
Four conditions shaped more of this product than any feature did:
Partial data
Retrieval is uneven, so supply counts are shown per scope column on every comparison. A thin comparison set stays visibly thin instead of being averaged into a single confident-looking market figure — the interface refuses to present more certainty than the data supports.
Large record sets
Competitor pools, inventory and history were designed to scale well beyond what fits on a screen, so tables, pagination, search and filtering are first-class components rather than afterthoughts. This was a design requirement from the data model, not an observed production volume.
Multi-dealership permissions
Access is defined across four levels, with seat licensing and subscription status at the dealership level, and staff can switch between dealerships without logging out — designed in response to the dealer-group structure described in domain sessions.
Extension constraints
The panel renders over pages of unknown layout and width. It is movable, minimisable and dismissible, sized to coexist with the host page’s own content rather than cover it, and every tool opens in a panel that can be closed back to the compact launcher.
Alongside these: designed empty states that name the next action, the full credential and invitation set, and transactional emails — since for an invited user the email is the first screen of the product.
Accessibility requirements
These requirements are part of the design specification. Production accessibility conformance has not been independently verified:
- Visible focus states across extension controls, tables, dialogs and the dealership switcher
- Contrast targets for blue on white and for white on the navy sidebar, including small numeric table text
- Status, ranking and selection never signalled by colour alone — always paired with a label or value
- Dense numeric tables legible at browser zoom and in the constrained extension width
- The extension panel dismissible and operable by keyboard, and never trapping focus on the host page
Business Rationale
Each architectural property below was chosen for a commercial reason. The property is inspectable in the design; the business effect is the intended outcome and has not been measured.
Architectural propertyIntended business effectStatus
Per-dealership vocabulary captured as admin configuration
Faster dealership onboarding, and onboarding pace not bound to the development queue
Design inspectable · effect unmeasured
Normalisation knowledge entered through a form rather than code
Reduced engineering dependency per customer added
Architectural hypothesis
Target rank as input, required price as output
Faster pricing decisions with fewer iterations per vehicle
Design inspectable · effect unmeasured
One scope model across all three surfaces
Consistent market data wherever a number appears, and no per-surface reconciliation
Design inspectable
Metrics expressed against a fixed segmentation
New capability enters existing components; reusable enterprise architecture
Design inspectable · effect unmeasured
Seat licensing and subscription status in the admin console
Account changes administered in-product rather than handled manually
Design inspectable
Outcome, Evidence & What Remains Unmeasured
Designed
Around 170 screens and states across the three surfaces. The number matters less than what it covers: not a feature set, but the full lifecycle of an enterprise data product — the primary tools, the four-level permission model, partial-data and empty states, credential recovery and invitation flows, and the admin configuration layer that makes the data comparable in the first place.
Implementation status
This case study documents the completed product design across the Chrome extension, dealer workspace and admin console. Production implementation has not been independently verified for every feature described.
Unmeasured hypotheses
- That in-context delivery earns more regular use than a separate dashboard
- That an inverted pricing interaction reduces the effort of setting a competitive price
- That configuration-based moniker mapping shortens dealership onboarding
- That showing supply counts leads users to weigh thin comparisons differently
What I would measure next
GroupMethodHypothesis it tests
Core value funnel
VDP visit → extension opened → market comparison viewed → pricing action taken, measured per user per week
Does the extension convert a page view into a pricing decision? This is the product’s central claim.
Delivery model
Extension sessions vs workspace sessions for the same task
Does in-context delivery win the recurring habit?
Pricing behaviour
Price Action uses per vehicle, iterations before settling, and whether a price change follows
Does the inverted interaction reduce effort and change decisions?
Scope comprehension
Task-based sessions: ask users what falls inside the Competitors column and why, then check against their configured set
Do users understand the scope model, rather than merely having used it?
Data trust
Present matched high-supply and low-supply comparisons in a moderated session and ask which they would price against, and why
Do users read supply counts as a confidence signal?
Onboarding cost
Time and engineering hours per dealership onboarded, before and after
Did moniker configuration remove the engineering dependency?
Reflection
In a data product, the interface decisions that matter most are often furthest from the user — an admin form no dealer will ever open determines whether every number the dealer does see can be trusted.
What I would do differently: get in front of dealership staff during design rather than relying on domain input alone. The in-context model and the inverted pricing interaction are both strong claims about behaviour that I designed without watching anyone work.
Data becomes a product at the moment it meets a decision. Everything before that is plumbing.
