Haulmark · 2024
A design system built from a freight platform's densest screen
Tokens, components and an adoption model for a freight platform built by four teams, with 41 button styles and six separate tables.
- Client
- Haulmark
- Year
- 2024
- Role
- Design systems lead
- Duration
- 11 months
- Services
- Design system
- Component design
- Team enablement
The problem
Haulmark runs a freight brokerage platform used by dispatchers, carriers and shippers, built by four product teams over six years. An audit I ran across 212 production screens found 41 distinct button styles, 17 date pickers and six separate table implementations, two of which could not sort. Dispatchers spend eight hours a day in these screens, and the inconsistency had a measurable cost: support tagged 19% of tickets as 'couldn't find it' or 'clicked the wrong thing'.
Two earlier attempts at a system had stalled as Figma libraries nobody maintained. I interviewed eight engineers and five designers to understand why. The answer was ownership and fit: components had been drawn for spacious marketing-style pages, not for operational views where a dispatcher compares 60 loads at once. Any new system had to win on the hardest screens first, or teams would keep building their own.
Process
- 01
Started with the densest screen
Rather than beginning with buttons and colour tokens, I picked the load board, the screen with the most traffic and the most custom code. I rebuilt it with a minimal set of tokens and components and shadowed six dispatchers using it. Starting there postponed the marketing-friendly pieces by two months, which frustrated the growth team, but it proved the system could handle compact density, keyboard navigation and live updates.
- 02
Defined tokens with engineers
I paired with two front-end engineers to define tokens in code and Figma at the same time, using identical names in both. We chose three density modes (compact, default, comfortable) instead of one spacing scale, because carriers on tablets needed bigger targets than dispatchers on 27-inch monitors. Every component shipped with documented keyboard behaviour and a visual regression test before it reached the Figma library.
- 03
Made adoption the metric
We tracked adoption per screen in a simple dashboard showing how much of each page used system components. Teams got a migration day every second sprint and a contribution guide for proposing new components. I reviewed contributions for the first three months, then handed review to a rotating group of two designers and one engineer so the system would not depend on me.
Selected images
The load board went first, which is why dispatchers trusted everything that came after it.
Outcome
Eleven months in, 78% of production screens use system components, and the six table implementations became one data table with column pinning, saved views and bulk actions. Teams estimate new features now need about 30% less front-end time. Support tickets tagged as navigation or misclick problems fell from 19% to 8% of total volume.
- 78%
- of screens on the system
- 41 → 4
- button variants in production
- −58%
- misclick-related tickets
Keep reading
All work