I recently had a fantastic chat with my friend Elleta—an incredible thinker in the design systems space—shortly after we both finished Vitaly Friedman's Smashing Workshop. We started trading notes on the realities of the modern UX-to-Dev handoff, and it made me realize how drastically my own workflow has shifted over the last six months.
I want to share my current process, not because it is perfect, but because we are all trying to level up and stay relevant in this rapidly changing landscape, and sharing our "messy middle" is the best way to do that.
The "Sloppy" Figma Phase
I no longer provide Figma files as a deliverable for code.
I attended Config 2026 and thought the new code layers were fascinating, but they currently only support React. I work in a strict Angular environment, so that's a non-starter. But honestly, even if it supported Angular, relying on a design tool to generate production code often feels like adding an unnecessary layer of obfuscation.
Today, I use Figma strictly for ideation. I create bare-bones, "sloppy" prototypes that I honestly would have been embarrassed to show a Product Manager six months ago (back when I used to waste hours perfecting the prototype to "tell the story"). Now, I show them the rough canvas, get their immediate feedback, make quick adjustments, and then jump directly into my IDE.
The Sandbox Problem
Once I am in my IDE (I use Kiro with the Claude 4.6 agent, which is phenomenal for front-end work), I build the interfaces using our Storybook components and mock JSON data.
During my conversation with Elleta, we hit on the biggest challenge of this methodology: How do you keep these little UI sandboxes from deviating from the main codebase?
If my sandbox drifts from our engineering standards, the code I hand off is useless. The developer will have to rewrite it anyway, completely defeating the purpose of a Design Engineer.
The Multi-Repo Architecture & Markdown Guardrails
To ensure my developers can pick up my code with zero friction, I had to architect a very specific workspace environment.
The Workspace Setup: My main active repository is my UI sandbox. However, I also add the actual production repo (where our Angular modules live) and the component library repo directly into the same Kiro workspace.
The Initial Groundwork: About six months ago, I spent a lot of time training Kiro on how to spin up these UI sandboxes appropriately. I taught it how to mimic the production environment and copy production code directly into the sandboxes so the foundation is identical.
The coding-standards.md File: This is a crucial piece. I maintain a strict markdown file detailing our exact engineering rules (e.g., forcing the use of specific Bootstrap versions). I audit against this file after every single AI session to ensure the agent hasn't hallucinated a deviation from our standards.
The wcag-analysis.md & Safari VoiceOver: One of the greatest benefits of this workflow is the accessibility pipeline. I keep a dedicated WCAG markdown file completely set up in the repo. Claude runs an automated check against it, but more importantly, it generates a clean manual checklist for items an AI simply cannot verify. I then take that checklist into Safari and use the built-in VoiceOver feature to test screen reader compliance manually before the final handoff.
How It Works in Practice
Recently, I was working on a page that utilized our standard card components. We needed to add functionality to toggle the view from cards to a table format.
Because of my workspace setup, I didn't just ask Claude to "build a table." I explicitly instructed the AI to research the production repository, analyze the existing schemas for the cards, and build the new table structure using the exact same data models. Then, we ran it through the WCAG markdown file.
It isn't just about making the UI look right; it is about making it act right for all users.
Because our software is a robust, legacy asset management tool, the backend business logic is incredibly complex. By ensuring my UI sandboxes are perfectly synced with production schemas and pre-audited for accessibility, my developers can seamlessly plug my front-end code into the application. It expedites the UI phase and allows them to focus their energy entirely on the heavy backend logic.
I am constantly tweaking this setup as the tools evolve, but bridging the gap between isolated design sandboxes and actual production architecture has been a massive step forward for my team.
#UXDesign #DesignSystems #Accessibility #Angular #KiroIDE #Claude #Frontend #Config2026