Struct, a shared design system
The shared set of components, rules and colour tokens behind two enterprise products built by different teams, so the two look and behave like one thing. It was not designed up front. A re-skin turned into a rebuild. Other internal platforms are built from it now.
- Role
- Lead designer & maintainer
- Team
- Me, plus whoever was on the product
- Timeline
- From late 2024, ongoing
- Status
- In use while still unfinished
There was no brief. The client asked for a different look. A re-skin turned into a rebuild, and the rebuild turned into a system.
The first build used Material Design, because the client asked for it. After the first module shipped they said it felt dated and wanted something modern. That is a taste argument, which is hard to act on. Underneath it was a real mismatch. We had to build the second attempt instead of downloading one.
The evaluation and the choice of what to build on, the component set itself, most of it drawn from scratch rather than adapted, the tokens, the specialised components that had no equivalent anywhere, and the ongoing work of pulling two products’ worth of drift back into one library.
For long stretches this was one person’s job, and later mine plus designers early in their careers. A system does some of the mentoring. It answers questions a junior designer would otherwise have to ask. It also makes a disagreement about a control visible.
Everything on this page is a recreation. The client is not named; their branding, real identifiers, customer data and internal documents are replaced with fictional equivalents built for this portfolio. Figures appear only where they describe my own process, and anything commercially sensitive is left out.
The system spans two clients under separate agreements, so the components here are shown with fictional content and neither client’s branding.
Where it came from
Two enterprise products, started about eight months apart and overlapping for most of their lives: a dealership operations system and a licensing platform for a cloud reseller. Neither project had a design-system line item. Both needed the same forty or so components, and the second one was being drawn by copying the first.
Copying is what causes the trouble. A copied component drifts. Someone fixes a padding bug in one product and not the other. Someone adds a variant the original never had. In time there are two libraries that look related and behave differently.
Why the first one went
The dealership system was built on Material Design at the client’s request. After the first module shipped, the client said it felt dated and asked for something more modern. I did not argue. They were right, but not for the reason they gave.
The mismatch was not age. Material is built for consumer apps. This is a tool people sit in for eight hours. It puts heavy shadow on every surface. Its touch padding halves the number of rows you can see in a register. Its floating action button competes with the primary action already on the page. It animates things that happen hundreds of times a shift. All of that is right on a phone. In a dense table at work it gets in the way.
What we built on
We evaluated several directions and landed on a variation of shadcn/ui: plain, accessible building blocks with the styling left to you. We took the structure and left the look alone. It meant we stopped inventing a control from scratch every time one was needed, and still made the visual decisions ourselves.
In practice most components were drawn from scratch anyway. What we inherited was structure and behaviour: what states a combobox has, how a date range is expressed, where helper text and error text sit relative to a field. The look, the density and the vocabulary are ours.
The components you cannot get anywhere else are the reason to have a system. A record-level notes panel with pinning and tagging. A management-history log with an action filter. An entity dropdown for users who work across dozens of sites. Announcement records. Plugin connection cards. These come up in every enterprise tool I have worked on, and general-purpose libraries do not ship them.
One component, two products
The notes panel is the clearest case. It was built for a vehicle record and then needed on a client account, which is a different object with different metadata and a different audience. The three questions were the same: who said what, when, and whether it is still relevant.
Generalising it meant deciding what was essential and what was local. Authorship, timestamp, role, pinning and tags are essential. What the tags say is local. The component takes those as configuration, which is what keeps it one component.
Tokens, and their naming problem
Colour, type, spacing and radius are tokenised and applied, which is what made the compliance-style re-skins on other projects survivable. The families are numbered scales: four backgrounds, three borders, three text levels, five blues, plus two gradients.
Numbers are quick to write and hard to read later. “Border 2” tells you where it sits in a ramp and nothing about when to use it, so every new person guesses, and the guesses drift. Renaming them to roles, such as surface, control and emphasis, is the single largest piece of unfinished work in the system, and it is unfinished because renaming tokens in two products people are using costs time nobody has yet.
What is in it
The nine groups are what the two products needed. We did not work from a list of parts a system is meant to have.
Where it stands
People are using it, and it is not finished. The board below shows where it stands.
What I’d do differently
Two things I would do differently.
By the time we decided to make this a real system, two products had already diverged and the reconciliation work was larger than building it deliberately would have been. The moment to extract a system is the first time you copy a component between products, not the first time the drift becomes painful.
The case for a design system is usually made in speed and consistency, and I have neither figure. No build time before and after, no count of components reused versus redrawn, no audit of how far the two products agree today. Until that happens, nothing proves it works outside these two products.