A shared system
Chalk was Thinkific’s design system. Toga, a legacy library, was still in use because some components existed only there, so the work was to close those gaps and bring teams onto Chalk.
Consumption across products
What I joined
Chalk was Thinkific’s design system, built in-house by Team Lego for a learning platform used by course creators and learners. An earlier library, built with an outside partner in 2022, mainly covered Admin components. Team Lego built Chalk from there, and the team also owned the front-end architecture that products were built on.
Teams got mixed signals about what they could use. Most of Chalk’s documentation lived in Storybook, written for engineers and focused on props. Designers had to work out whether a component was part of the public system or a private building block not meant to be changed. The Figma libraries and Storybook were only partly in sync, which made that question harder to answer.
Toga, the legacy library, was still in use. Some components existed only there, so teams that needed them kept building with Toga. Nobody was actively maintaining it, which created accessibility and upkeep risk, and it constrained newer design directions in the Admin experience. Dark mode was out of scope, partly because it depended on every product using Chalk’s tokens.
Defining success
We measured early success in growing Chalk against three criteria.
Adoption
Chalk’s share of component usage compared with Toga and custom components, tracked in Storybook.
Maturity
How many components sat in each lifecycle stage (experimental, new, stable, verified), plus recipes.
Documentation use
Views, AI queries, and helpfulness ratings in Zeroheight after launch.
Later, when AI became part of our tool stack, drift, alignment, and governance became part of our success model too.
Planning the roadmap
The first thing I built was a maturity model: a five-level scale from a UI kit to a public design system. It gave the team a shared answer to "what level are we at, and what would the next one take?" I paired it with a review of Storybook, Figma, and the live product, so the roadmap started from what teams actually used.
Three paths, one choice
Team Lego chose Build. Its strength was a complete core and clear usage guidance, so teams could build with Chalk instead of around it. Its risk was a slower start on adoption, which the plan answered with a migration timeline. Nine Toga components had no Chalk equivalent. Rebuilding them was estimated at about 18 weeks, with about 24 more to migrate existing usage.
Build
Core library and documentation first, then migration
Diversify
Work on every area at the same rate
Adoption
Migrate Toga and custom components now
Starting the work
The first months covered the work most design system teams do, plus a backlog cleanup. We cut the backlog from about 439 tickets to about 250 in two weeks. Many were done but never closed, and I made the design calls that let them close.
I restructured the Figma libraries so private parts were clearly separate from public components. Design and content guidance moved into Zeroheight, which became the home for documentation. Storybook stayed focused on component props.
Before
After
Shipping components with a quality gate
I designed, specced, and delivered 12 new or promoted components for web, including Avatar Group, Bottom Sheets, Color Field, Inline Alert, and Filter Select. Each was reviewed against its spec in Chromatic, which we used for design QA.
The company turns to AI
In the second quarter of 2026, the leadership structure changed, and the CEO became more directly involved in the organization’s priorities. Planning moved toward shorter cycles, and the question became what the company could deliver faster with AI. More designers and teams began building prototypes in Claude alongside Figma.
For Team Lego, the question changed too. The earlier question was how to make Chalk complete. The new one was how to keep quality high as more people built with AI. That meant building more high-quality components and frameworks, documenting props and rationale, and making the rules visible to tools.
This is where the Build path’s assumption was tested. Build argued that a complete core and clear guidance would let teams build with Chalk. AI prototyping made that concrete: a prototype either followed the system’s rules or drifted from them, and the drift showed up quickly.
Decision rules, not only descriptions
An AI tool choosing between component A and component B needs a clear rule for when to use each. I wrote "when to use" guidance for the components teams reached for most, so a tool could make the same call a designer would.
Rationale for every variant that stays
Over time, buttons and other components had picked up variants with no documented reason. I wrote the rationale for the variants that stayed, which gave people and tools the same basis for choosing.
A loop from drift to rule
When AI output drifted from Chalk, we turned the failure into a written rule, so the next build avoided it.
1
AI produces a bad pattern
2
We capture what went wrong
3
We document the pattern as a rule
4
The next AI query reads the rule
Connecting the MCPs and holding quality for learners
We connected three MCP servers: Storybook MCP for component props, Chalk MCP for the system itself, and Zeroheight MCP for design and content guidance. I focused on the Zeroheight integration, because design documentation held the largest share of the system’s content. Through it, Claude Code could read Chalk’s tokens, principles, and guidance on choosing between components. It became the main checkpoint for quality in the team’s shared prototyping repo.
Connecting the docs was not the last step. I opened pull requests in the prototyping repo to align designs with Chalk, and Chromatic checked new and updated components against their specs.
Outcomes
Zeroheight also showed us how the documentation was used. We could see visits and how often Claude Code pulled context from it, and the AI queries trended upward.
Reflection
The design team was the first audience for the documentation. Sharing it with the wider organization earlier would have reached more people. I also didn’t have admin access to library analytics, so we couldn’t measure code adoption or Figma detach rate. Both would be first in a future measurement plan, alongside a fixed test set from day one.