Why one design system beats five
When I joined the Valmont project, there were five separate applications running in production. Each had its own set of buttons, its own colour palette, its own idea of what a table should look like. The users — field technicians and irrigation planners — had to learn five different interfaces to do their job. That is not a technology problem. That is a respect problem.
The first thing I did was not open Figma. I printed screenshots of all five apps and taped them on a wall. Side by side, the inconsistency was almost funny. Three different shades of blue for primary actions. Two apps had a save button at the top, three at the bottom. One app used checkboxes where another used toggles for the same setting.
A single design system solves this at the root. Not by making everything identical — that would be boring. But by giving every app the same foundational language. When a user moves from the dealer portal to the field planning tool, they should feel like they are in the same ecosystem. The cognitive load drops. Mistakes reduce. Training time shrinks.
We started small. Colours, typography, spacing — the boring stuff. Then buttons, inputs, tables. Then complex patterns like multi-step forms and data grids. Each piece was documented with usage guidelines, not just a component preview. The goal was: an engineer should be able to build a new screen without ever asking a designer what a primary button looks like.
Components are the easy part — governance is the real work
Anyone can make a button component. The hard part is making sure everyone actually uses it. Six months into building the design system, I found an engineer who had copy-pasted a button component and changed the border radius because 'it looked better.' That one change rippled into 40 screens before anyone caught it.
Governance is not about being the design police. It is about making the right thing the easy thing. We set up a Slack channel where anyone could request a new component or a variant. The rule was simple: if it already exists in the system, use it. If it does not, let us discuss whether we need it. Most requests were valid. Some were people trying to solve a one-off problem that did not need a system-level change.
We also invested in tooling. A Figma plugin that flagged components not from the library. A lint rule for the frontend that warned when a hex colour was used instead of a token. These small nudges built the habit over time. No meetings, no arguments — just the system quietly guiding behaviour.
Getting engineers on board without being annoying
I learned this the hard way: nobody likes a designer who shows up in a code review and says 'this padding is wrong.' Engineers have their own pressures, their own deadlines, their own pride in their craft. If you treat them like obstacles, they will treat your design system like extra homework.
What worked for us was making the system a shared asset, not a design deliverable. We ran a workshop where engineers mapped out the component hierarchy themselves. They named things. They suggested the API for each component. When they had ownership, consistency became their idea — not ours.
The other thing: show them the numbers. We tracked how long it took to build a new feature before and after the design system. For a typical form-heavy screen, the time dropped from three days to one. Engineers understand efficiency. Give them proof, not opinion.
What I would do differently
Looking back, we should have started with accessibility earlier. Colour contrast, keyboard navigation, screen reader labels — these are not add-ons. They are part of the component definition. Adding them retroactively was painful and doubled our workload.
I would also document the 'why' behind every decision, not just the 'what.' A design token like 'spacing-md: 16px' means nothing without explaining that we chose 16px because it hits the sweet spot for touch targets without feeling loose on desktop. Future designers and engineers should not have to reverse-engineer our thinking.
Finally, I would celebrate small wins more visibly. When an engineer shipped a screen that used 100% system components, we should have highlighted it in the team channel. Recognition builds momentum. Momentum builds adoption.