Case 06 · Design System

The foundation that became an AI spec

Role
design lead at the foundation · product and design leadership on the revival
Team
lean teams — 5–6 people in the sprint, 6 in the revival cycle
Arc
a 2-week sprint + a 4-month cycle — two years apart
Thesis
the foundation was built on how product gets built, not on a tool — and it became an AI spec with no rework

Act 1 — The foundation

The design system existed, but it had long been without an owner and without process: there was no definition of how to evolve it, of how squads would contribute, nor of what flow a change should travel.

I, then design lead, owned the plan, facilitated, and led the foundation initiative, working simultaneously with the design team and the front-end team, ensuring a clear goal for the sprint and technical decisions that adhered to that goal.

With no basis for evolution, every contribution to the DS was a case-by-case negotiation, and inconsistency grew along with the product.

The organization was in a moment of big initiatives prioritized; there was a short window and a lean team. The real choice was to use that window to build the structure for evolution (processes, agreements, flows) or to try producing components with no structure.

Foundation before production.

In the single sprint, the bet was to come out with the complete system for evolution, not with components: a contribution guide with working agreements, processes by type of change, and installation and publishing guides.

Design and engineering under the same goal: I led the design team and the front-end team simultaneously, and the flow we designed has both lanes integrated, from a squad’s proposal to publishing with a definition-of-done gate. Instead of a central team that does everything, a design system forum that refines, prioritizes, and guards the quality bar: squads contribute through the process, not by exception.

From zero to the complete system for evolution in 2 weeks, with a team of 5 to 6 people.

contribution guide·DoR/DoD·code review·versioning

The organization’s context shifted and the topic sat still for two years.

What connects the two acts is the foundation. It was built on beliefs about how the company’s design should be developed, not on a tool, and that’s why it stayed valid when the technology changed.

The foundation that became an AI specNothing was rewritten: the definitions from the foundation sprint became, two years later, the specs for the skills.The foundation that became an AI specNothing was rewritten: the definitions from the foundation sprint became, two years later, the specs for the skills.YEAR 1 · FOUNDATION SPRINTContribution guidetwo weeks · a small team · from scratchDefinition of Ready and Definition of DoneCode review and versioningRefinement with the design system forumA process per change type: component, token, feature, breaking change, bugfixInstall and release guides · design ↔ engineering handoffsWritten about how we work — not about the tool.two years later: compiled for AI, not rewrittenYEAR 3 · THE AI-READY CYCLEThe plugin's skill setthe foundation as the spec · AI as the interfaceFind a componentconsumer · the right component on the firsttryCreate an experienceconsumer · from idea to a prototypeconsistent by constructionCreate a componentbuilder · from tokens to all three platformsConsistency checkbuilder · validates against the guide's DoDPackage a contributionbuilder · from component to a PR ready tomerge, through the processFor any role in the squad — PM, design, engineering.relative timing · component names and internal tools omittedThe foundation that became an AI specNothing was rewritten: the definitions from the foundation sprint became, two years later, the specs for the skills.The foundation that became an AI specNothing was rewritten: the definitions from the foundationsprint became, two years later, the specs for the skills.YEAR 1 · FOUNDATION SPRINTContribution guidetwo weeks · a small team · from scratchDefinition of Ready and Definition of DoneCode review and versioningRefinement with the design system forumA process per change type: component, token,feature, breaking change, bugfixInstall and release guides · design ↔ engineeringhandoffsWritten about how we work — notabout the tool.two years later: compiled for AI, not rewrittenYEAR 3 · THE AI-READY CYCLEThe plugin's skill setthe foundation as the spec · AI as the interfaceFind a componentconsumer · the right component on the first tryCreate an experienceconsumer · from idea to a prototype consistent byconstructionCreate a componentbuilder · from tokens to all three platformsConsistency checkbuilder · validates against the guide's DoDPackage a contributionbuilder · from component to a PR ready to merge,through the processFor any role in the squad — PM,design, engineering.relative timing · component names and internal toolsomitted
What this diagram proves: the work from two years ago wasn't redone: it was compiled for the new technology. The contribution guide's definitions became directly the plugin's skill set.

Act 2 — The revival

Two years later, now in product and design leadership, I’m directing the revival of the topic in an AI context, with a group of six people across design, engineering, and product, in a four-month cycle.

AI changed the economics of the problem: the DS could stop being a catalog consumed by engineering and become a capability accessible to any function.

In business terms: speed with consistency. New experiences without a design and engineering queue at every surface change, without giving up the quality bar. The risk was over-engineering: packaging and distributing before proving real demand.

Capability before distribution.

First AI skills (lightweight files, zero infra cost, daily iteration) that teach the AI to run the DS workflows; then the plugin that packages them. I defined the objective trigger for the transition: at least one stable skill, used regularly by people outside the team. Before that, the plugin doesn’t ship.

And adoption became the definition of done: the success metric is squads creating consistent experiences without opening a question in the DS channel.

The foundation as spec: the definitions in the contribution guide (DoR, DoD, code review, versioning, publishing flows) went directly into the plugin’s skill set. The work from two years ago wasn’t redone: it was compiled for the new technology.

Capability before distributionSequencing against over-engineering: only package what has proven real demand.Capability before distributionSequencing against over-engineering: only package what has proven real demand.01 · STATION 1Skills — the capabilityV0 → stable, against real uselight files in the repo, zero infrastructurecostdaily iteration — changes in minutesdoubles as operational discovery: itreveals which questions actuallydominate the squads' daysonly what clears it moves onGATEAn objective criterionno "when it feels ready"≥ 1 stable skill — two weeks without achange≥ 3 people outside the team using itregularly02 · STATION 2Plugin — the distributiondistributes only what has proven its valuepackages the validated skill setatomic release: change a token and everyskill updates with itone-time install · contribution guideembedded as specreal criteria · skill and squad names omittedCapability before distributionSequencing against over-engineering: only package what has proven real demand.Capability before distributionSequencing against over-engineering: only package whathas proven real demand.01 · STATION 1Skills — the capabilityV0 → stable, against real uselight files in the repo, zero infrastructure costdaily iteration — changes in minutesdoubles as operational discovery: it reveals whichquestions actually dominate the squads' daysonly what clears it moves onGATEAn objective criterionno "when it feels ready"≥ 1 stable skill — two weeks without a change≥ 3 people outside the team using it regularly02 · STATION 2Plugin — the distributiondistributes only what has proven its valuepackages the validated skill setatomic release: change a token and every skill updateswith itone-time install · contribution guide embedded as specreal criteria · skill and squad names omitted
What this diagram proves: the skills → plugin transition has an objective gate, not a date: the criterion is written into the gate.

Two journeys to serve: those who build and those who consume.

I ran a structured worksession that mapped the process through the two personas (builder, who builds and publishes the design system; consumer, who consumes it to create experiences), generated the bank of candidate skills, and defined owners in owner + reviewer pairs, chosen by the group in the exercise. Autonomy with review built in.

Craft against an explicit baseline, not opinion: a V0 → stable rhythm with an objective criterion: a skill is only stable with two weeks without a change and three or more users outside the team, the same gate principle from the original contribution guide.

Two personas, one system — builder and consumerA map derived from the worksession with the group: the pain came from the squads, the skills cover the full cycle.Two personas, one system — builder and consumerA map derived from the worksession with the group: the pain came from the squads, the skills cover the full cycle.BUILDER · WHO BUILDS AND SHIPSThe design system team and engineeringCreate a componentfrom tokens to all three platformsConsistency checkvalidates against the contribution guidePackage a contributionfrom component to a PR ready to mergeContribute back without memorizing the checklist.one publishes, the other consumes — the same systemCONSUMER · WHO BUILDS EXPERIENCESPM, design and engineering across the squadsFind a componentthe right component on the first tryCreate an experiencefrom natural language to a prototypeConsistent by construction: official components and tokens only.success criterion: consistent experiences without a single question in the design system channelderived from the mapping worksession · names omittedTwo personas, one system — builder and consumerA map derived from the worksession with the group: the pain came from the squads, the skills cover the full cycle.Two personas, one system — builder andconsumerA map derived from the worksession with the group: thepain came from the squads, the skills cover the full cycle.BUILDER · WHO BUILDS ANDSHIPSThe design system team and engineeringCreate a componentfrom tokens to all three platformsConsistency checkvalidates against the contribution guidePackage a contributionfrom component to a PR ready to mergeContribute back without memorizingthe checklist.one publishes, the other consumes — the samesystemCONSUMER · WHO BUILDSEXPERIENCESPM, design and engineering across the squadsFind a componentthe right component on the first tryCreate an experiencefrom natural language to a prototypeConsistent by construction: officialcomponents and tokens only.success criterion: consistent experiences without asingle question in the design system channelderived from the mapping worksession · names omitted
What this diagram proves: the skills map came from the process's two personas, builder and consumer, not from a leadership list.
zerodefinitions rewritten on the revival
reused directly under the AI objective
that’s what made the revival cheap
  • That foundation isn’t the design system itself: it’s the working agreements and practices, the essential premises of how good work gets done, which stay valid regardless of how the technology evolves.
  • Signals from the current cycle: the first skills are already used by people outside the team; worksession held with a prioritized skill map and owners defined by the group; skills in evolution and testing covering the full builder/consumer cycle; contribution guide incorporated as the spec for the plugin’s skill set.
  • The criteria I hold myself to: squads creating consistent experiences without opening a question in the DS channel; skills published and tested by people outside the team, with active pilot squads; backlog components delivered on all three platforms, with complete DoD and discoverable via AI.

The DS stopped being a catalog that depended on engineering and became a capability for any function, because the foundation described how you work, not which tool you use.

06 — What I’d do differently

I’d have explicitly forced the conversation about the viability of continuity: what would need to be true for the topic to keep going, and who needed to hold that decision up. The two-year pause came from the organization’s context, not from a designed decision. The foundation survived because it was well built, and continuity deserved the same design care.

A well-built foundation doesn’t expire: what we defined as process became, two years later, a spec for AI, without rewriting what we believe about how product gets built.