How I work · The products need a system

Set standards other teams adopt

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

When this is the job
Several teams building the same components differently, and a product suite that shows it
How long it takes
Weeks to see what has been built twice, months to a foundation the teams use, and rules that keep it for years
What it asks of the team
One person who can settle what is shared when two teams disagree, a lead from each product team, and the codebases as they are, forks included
What it leaves behind
The shared components in use, the tokens underneath them in design and code, and the operating rules written for people and AI tools alike

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
  • About halffewer UI defects in production, quarter over quarter

That was a practice built over two years across forty apps, and the steps below are its moves in order: the inventory, the shared-or-local call, the foundation, and the rules that kept it adopted.

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 goes, 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 the team

  • One person 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 it is one of the other three

Questions people ask

How long does it take?
Weeks to inventory what exists and draw the shared-or-local line, months to build the foundation against the products most likely to reject it. Keeping it adopted is the part with no end date, which is what the operating rules are for.
Is this something you do alone?
No. A lead from each product team runs the inventory with me and makes the shared-or-local call, and the leads build the parts they will own alongside me. A foundation handed over finished is a folder of components nobody opens.
What does the team need to give?
One person 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 working session where the shared line gets drawn.
What does the team 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 has it worked?
Across 40+ SAP apps, where one style guide and one component library, with checks written into the release process, took about a third off the time from design to development and cut UI defects in production roughly in half. The case study carries the figures.
Is this a role or an engagement?
A role, first. I am looking for a senior product design role where this is the work, in-house and remote, with a team that can hire in Minnesota. I also take select independent engagements, where the same moves run at the size of one suite.

On a team

Whoever runs the inventory builds what it recommends, with the team’s engineers. The leads build the parts they will own alongside me, because a foundation the team cannot extend without me is rented, not built. And the rules are what keep it adopted after the build is over: who can change what, how a team proposes an addition, and which numbers say whether it is working.

If this is the job

I’m looking for a senior product design role where this is the work: in-house, hands-on, remote, with a team that can hire in Minnesota. A few sentences about your team and what it is building are enough to start. I also take select independent engagements.

Start a conversation

or write to adam@adamhickey.com