I lead and maintain the design system for Talmud, the Ministry of Education’s platform for 900+ Torah institutions: 50+ components built on two layers of Figma variables. Building the components wasn’t the hard part. Keeping one system coherent was. The system started a year into the project, and every new screen brings a need it didn’t anticipate.
Role: Design system lead and owner
Scale: 50+ components · 2 variable layers
Status: In active use and maintenance
Talmud’s screens drew on two sources: the Ministry of Education’s design library, which we were required to follow, and custom components we built whenever a screen needed something the library didn’t offer, each approved by the Ministry’s design lead. Talmud had no single library of its own. Consistency depended on whoever designed the screen, and developers had no complete reference.
I started the system a year into the project, with many screens already designed. That meant building the library around existing work rather than ahead of it. This is the root of the coverage challenge described below.
The system follows a two-layer token architecture, which I implemented across the library. It separates values from meaning:
Hold raw values: colors, spacing, type sizes.
Give those values a role, such as an action color or a surface color.
Use semantic tokens only, so one change updates them all.
The Ministry’s library has no variables or tokens at all. This layer exists only in Talmud’s system.
I led the build and own the system today, with guidance from our design-team lead. I scoped and assigned work to a second designer, who organized the library visually and wrote the usage guidelines.
Changes are the easy part: I update a token or a main component, and the change carries through. Coverage is the real work. Because the system was built mid-project, not every screen and need was known in advance. Every new screen comes down to the same decision:
The AI exercise below made those gaps visible from a different angle.
For a new screen, I connected Claude Code to Figma through the Figma MCP server. I gave it a written brief (what the screen does, who uses it, and what they need from it) and a reference screen from another system, and asked it to build the screen from Talmud’s components only.
What worked: it built the screen from the library’s components.
What didn’t: it placed the page-title component but left the placeholder text inside unchanged, and it added chips and tags that don’t exist in the system. I corrected both by hand.
What it showed me: the model followed the system wherever the system had an answer, and improvised wherever it didn’t. Those were the same gaps I run into when maintaining it.
The two failures point to two different fixes. The unchanged placeholder is a documentation gap: nothing in the component tells anyone, human or model, that its text must be replaced. The invented chips and tags are a coverage gap: the system had no answer, so the model made one up.
Next: adding component descriptions and usage rules that a model can read, and filling the coverage gaps the exercise exposed, so the next run needs no manual correction.
The system is in active use, and I maintain it. It isn’t finished. The token layer covers buttons, field spacing and payment statuses, while many components still run on plain styles. And because developers don’t have Dev Mode, I can’t see whether the tokens reach code. Closing that link is my next step: first mapping what exists in code with the front-end lead, then testing whether the same MCP connection that built a screen from the system can also turn its tokens into code variables. The AI exercise made the case for it: the more of the system is defined, the less anyone building from it has to guess.