Engagement 02 · The products need a system

Design System Foundation

Turn four versions of the same data table into one shared foundation your teams actually use, with the operating rules that keep it that way.

Start with a few sentences
Best for
Several teams building the same components differently, and a suite that shows it
Typical length
A three-week diagnostic at a fixed fee, then a build scoped from it, usually two to three months
Your team’s involvement
One sponsor, a lead from each product team, and one working session to settle what is shared
You leave with
The shared components in use, the tokens underneath in design and code, and the rules written for people and AI tools alike

Before you decide anything

Not sure this is the one? Start with a few sentences.

Tell me about your products and the teams behind them, in your own words: how many versions of the same data table there are, who owns which, where the last conversation about it stalled. No deck, no call to book. I will read it and tell you plainly whether this engagement fits, and if it does not, what would.

If the number that comes back is more than you have, say so. There is usually a smaller version — the diagnostic on its own, or one product area rather than the whole platform — and it is a different engagement rather than this one discounted.

Describe what is happening

or write to adam@adamhickey.com

The situation

The suite grew a product at a time, and it shows. Four teams have built the same data table four ways, nobody is sure which one is correct, and every new screen restarts a conversation that was settled somewhere else last year. The folder of patterns exists. Nobody opens it, because it was never built against the products the teams actually ship. And a third reader has arrived that cannot ask anyone which data table is right: the AI tools the teams now build with see four and generate a fifth.

Where it has worked

One practice where the shared foundation was the turn. Every figure is from the case study it sits beside.

SAP practice · 40+ enterprise apps

Nobody could say whether any of it was working, because nobody was measuring it.

Someone in the field might open four apps before lunch and relearn the layout every time. The work began by reviewing all of them, then building one style guide and one component library everyone worked from, with design and accessibility checks written into the release process rather than bolted on at the end. It kept working after I left.

  • About a thirdless time from design to development
  • More than halffewer UI defects in production, quarter over quarter

That was a practice built over two years across forty apps. This engagement is its opening moves at the size of one suite: the inventory, the shared foundation, and the rules that keep it alive.

More recently, Sprout, a design system for Cargill: the tokens live in the code and the Figma variables mirror them under a written sync contract, so drift is something an audit catches rather than a surprise. The whole system is also packaged as a Claude Code skill, so the team’s AI tools build from the same source of truth the people do.

The SAP enterprise platform: one style guide and one component library across a suite of apps.
The full account, with the screens →

How it works, step by step

Four steps, each with something to show for it. The example under each one is drawn from the same example company, so the four add up to one story: a manufacturer whose six internal operations apps were built by three teams over a decade, and now carry four different versions of the same data table.

  1. Inventory what already exists

    Every component, in every product, including the four versions of the same one, and the tokens, variables and documentation behind them, gaps included. Unglamorous, and the whole basis of the work: you cannot decide what should be shared until you can see what has been built twice.

    e.g.Nine date pickers, side by side for the first time. Four of them behave differently on the same keyboard.

    One of their designers at her desk on a one-to-one call with Adam, pointing a pen at a screen crowded with near-duplicate widgets.

  2. Decide what is shared and what stays local

    Not everything belongs in a system. Over-sharing produces a foundation every team resists, and the components teams resist are the ones they fork.

    e.g.The data table goes shared. The scheduling board stays local. The teams that argued for the board had good reasons.

    A laptop showing a shared screen on a call: two columns of component blocks, shared and local, with a strip of five call tiles along the bottom, Adam at the end.

  3. Build the foundation

    The shared components, the patterns that use them, and the tokens underneath: variables in the design file, custom properties in the code, mapped one to one so neither side drifts quietly. Documented so that a person and an AI assistant read the same rules. Built for the teams you have, not for an idealized team that reads the documentation first.

    e.g.Twelve components on one set of tokens. Built against the two apps most likely to reject them.

    A laptop screen showing the component library: rows of buttons, inputs and cards, a row of color swatches with one terracotta, and a type scale, with a printed spec sheet beside it.

  4. Set the operating rules

    Who can change what, how a team proposes an addition, how a change ships without breaking four products, and which numbers will say whether it is working. A system without governance is a folder of components that slowly diverges again.

    e.g.A standing half-hour for what the system is missing. Governance nobody can reach is how the forking restarts.

    Adam sitting beside one of their designers at a table, a single printed page of rules between them, his finger resting on one line and her pen on another.

What it asks of you

  • One sponsor who can settle what is shared when two teams disagree
  • A lead from each product team, for the inventory and the shared-or-local call
  • The codebases and design files as they are, forks included
  • One working session, about half a day, where the shared line gets drawn

When another engagement fits

Questions people ask

How long does Design System Foundation take?
A three-week diagnostic first, at a fixed fee. Then a build scoped from what the diagnostic finds, usually two to three months.
How is it priced?
The diagnostic is a fixed fee. The build is scoped and priced from what the diagnostic finds, so its size is known before it starts. Write to adam@adamhickey.com to start that conversation.
Who is it for?
Several teams building the same components differently, and a product suite that shows it: four versions of the same data table, and no rule for which one is right.
What does the team need to give?
One sponsor who can settle what is shared when two teams disagree, a lead from each product team for the inventory and the shared-or-local call, the codebases and design files as they are, forks included, and one half-day working session where the shared line gets drawn.
What do we leave with?
The shared components in use, the tokens underneath them in design and code, and the operating rules written for people and AI tools alike.
Where is the work done?
Adam Hickey is based in Minneapolis and works with teams across the United States, remotely and in person.

How I work

You talk to the person doing the work: whoever runs the inventory builds what it recommends, with your engineers or with engineering I bring in where you have none. The diagnostic ends in a written recommendation you can act on without me. Your leads build the parts they will own alongside me, because a foundation your team cannot extend without me is rented, not built.

Start here

A few sentences about your products and the teams behind them are enough to start. If a different engagement fits better, or none of them do, I will say so.

Describe what is happening

or write to adam@adamhickey.com

Next engagement · 03 Embedded Senior Product Design → Senior capacity, for a while