Self-initiated · Tool
Guidance Builder
Guidance Builder was a self-initiated project to address dissonance in SFE's documentation process, where guidance drifted out of sync between Figma and Storybook. Beyond fixing that inconsistency, it cut the time needed to populate both surfaces, adding value for design and engineering alike.
Problem
Since 2024, Design supplied Figma guidance in a template built to mirror how it would eventually appear in Storybook. Engineers would copy that guidance by hand once components were published in the repo, but publishing could happen months after guidance was finalized. In that gap, formatting changed, naming conventions shifted, and the two versions often drifted apart, with manual transcription introducing further error on top of it. In Figma, the canvas is a strength for granular visual decisions, but a poor fit for repetitive, formatted text entry, a friction Design felt regularly and Engineering felt worse, since Figma wasn't part of their daily workflow. When SFE began prioritizing AI-native efficiencies, that gap became an obvious place to build.
Process
Scoping the right solution. The first version I imagined was more ambitious: a plugin that would generate the entire Figma template from scratch, built out of utility components and infilled directly from form data. While attempting to build it, I realized that approach solved a problem nobody had. A designer would always need to go back into the generated file to add example imagery and annotation blocks by hand, so full generation added complexity without removing the actual bottleneck. I pivoted to a simpler, more durable approach: standardize the template's layer structure and naming so a lighter plugin could hydrate it directly with content from the form.
Building the form UI. I built a lightweight, web-based form UI that could flexibly expand for variable content, like additional subcomponent sections or multiple lines of screen-reader annotation, and output a structured artifact that both Storybook and the Figma plugin could read.
Building the hydration layer. I reformatted the standard guidance template so its layer names and structure matched the form's export schema, letting the plugin hydrate an empty template automatically. Visually, the template stayed identical to its Storybook counterpart; only the underlying naming and structure changed. That meant a designer who preferred to work manually could still do so with almost no adjustment.
Socializing and iterating with the team. I shared the proposal broadly with SFE's design and engineering team, who were actively looking for process improvements at the time. The response was strong: eliminating the manual copy-paste step from Figma to Storybook was a consistently cited pain point from engineering, and removing it also removed a recurring source of transcription error. Based on additional feedback, I added the ability to upload an existing JSON file back into the form UI, so guidance could be stored on our team SharePoint rather than requiring the tool to host or archive files itself, and edited quickly whenever updates were needed.
Adaptation
In July 2026, I was laid off as part of a large-scale restructuring within Microsoft. This project was still in progress at the time, and losing that access meant the asset libraries and corporate resources it depended on were no longer available to me.
Identifying what changed. I audited the project to determine exactly what I'd lost access to. The authoring UI and JSON schema were self-contained and worked exactly as before. Only the Figma half was compromised, because the original template file and supporting libraries were now inaccessible.
Treating the plugin as a spec. Rather than trying to recreate the original Figma environment from memory, I worked with agents to reverse-engineer the plugin and form UI logic, identifying what it actually required: extensive design system resources, technical specifications, and the outline guidance content in the correct order. The plugin itself became the spec for what the new template needed to provide. Because the original template was structured to resemble Storybook in code, I was able to extrapolate a surprisingly high-fidelity scaffold for the new iteration.
Creating tools to create tools. While reconstructing the template and testing it with the hydrator plugin, I found myself repeatedly describing the file's layer structure back to my agent in plain text, a slow and error-prone way to communicate something inherently structural. To solve that, I built a small companion tool, a Tree Exporter plugin that reads a selection's layer structure in Figma and outputs it as a labeled tree with exact names intact. That output became something I could hand back to my agent to tune exactly which layers the hydrator plugin should target, turning a manual description problem into a precise, repeatable solution.
Restoring the loop. With the new template in place, the original workflow ran end to end again: form input, JSON export, and Figma hydration, all working as designed, and running on my own infrastructure. Both the hydrator and the Tree Exporter are now published in the Figma Community, available to anyone facing the same problem.
Outcome & Reflection
I started this project with a fairly fixed idea of what it should become, and I'm glad it didn't end up there. Working solo meant no PM validating the problem before I started building, which was freeing, but it also meant more of the early groundwork fell to me: understanding the actual shape of the problem, not just the one I assumed going in. The result is something that evolved into what it needed to be rather than what I originally pictured, which feels like the right outcome even though it wasn't the plan.
One thing I didn't expect: solving one narrow problem produced tools with a much wider reach. The Tree Exporter, built to solve a specific annotation headache, will likely see more use on its own than the guidance system that prompted it. I also came away with a real appreciation for orchestrating multiple AI agents toward a single goal, closer to managing a small team than writing code alone, and a skill I expect to keep developing.
As a proof of concept, I'm confident some version of this would have shipped on SFE in the near term if I were still there. The longer-term vision was more ambitious: a plugin flexible enough to build guidance and populate example imagery directly from published components, a step toward moving fully away from Figma as the system's source of truth. By the time I left, that shift was already underway. The team's own view, mine included, was that Figma would stay valuable for ideation and granular exploration, but that component building itself was headed toward becoming a fully in-code practice, with designers increasingly prototyping there directly.
Losing access to the system I'd helped build for years also gave me a clearer view of it than I had while I was still inside it. It's easy to lose sight of how much infrastructure a mature design system represents when you're using it every day. I didn't fully appreciate what SFE had built until I suddenly couldn't use it anymore.
Solving one problem produced tools with a much wider reach.