Challenges faced
Documenting a design system usually ends up being just as much work as building the system itself. Teams get stuck in this loop of creating pages for components, writing out guidelines, and setting up patterns before they can even get to the actual "documenting" part. It’s a repetitive grind where you're forced to rethink the hierarchy and layout every single time.
The problem is that existing tools are either focused only on the building phase or they give you generic templates that you still have to manually tear apart and restructure. It creates this annoying friction right when you should be focused on capturing knowledge. I realized there was a huge gap for a framework that’s ready to go from day one, something where teams can just drop in their content and have it live in a perfectly organized system immediately.
Solution
To take the pain out of documentation, I built Atom. It’s a plugin that sets up your entire design system structure for you, all based on the principles of atomic design. Instead of wasting hours manually building out pages and layouts, you get an organized framework for your atoms, components, and guidelines in an instant.
Atom basically shifts the focus from building the document to actually writing it. It gives you predefined sections so you can just paste in your content and keep everything clear, consistent, and easy to scale without all the initial setup.
Ideation & Research
The idea for ATOM came from a simple realization: design systems don’t usually fail because they’re missing a button or a checkbox, they fail because people don't understand how to use them. My research showed that while everyone from developers to leadership relies on documentation, it’s almost always the most neglected part of the process.
The real problem is that documentation usually lives somewhere else, far away from the actual design files. This creates "knowledge drift," where the reasoning behind a design decision gets lost over time, leading to total inconsistency.
I wanted to see what would happen if we treated the "why" just as importantly as the "what." ATOM explores the idea of embedding usage rules and intent directly into Figma at the very moment of creation. The goal was to capture those design decisions early and contextually, so the system keeps its "memory" as it grows. It’s about making sure design systems scale with clarity, instead of just getting more and more complex.
My design process
For ATOM, the design process started with a bit of a "slow down to speed up" approach. Before I even thought about writing plugin logic, I spent my time handcrafting the entire experience directly in Figma. I wanted to focus on the structural foundation, figuring out how a single frame could represent a unit of documentation and how to make hierarchy feel intuitive at a first glance. I mapped out every content block, spacing rule, and metadata field so that the documentation felt like a native part of the design workflow, not just some external layer slapped on top.
A huge part of this was obsessing over visual clarity. I spent a lot of time testing how information looked in both light and dark modes, defining typography scales and color roles that weren't just about "looking good," but about making guidance accessible. By designing every state and variation upfront, I created a set of predictable patterns that the plugin could eventually follow.
When it came time to actually build it, I used Cursor as my execution partner. I connected my Figma workspace to Cursor using the Figma MCP, which allowed the AI to interpret my designs as the "source of truth." This meant the plugin wasn't just guessing, it was implementing the exact layouts and behaviors I had already perfected in Figma. It ensured that ATOM wasn't just an engineered tool with a coat of paint, but a product where the original design intent drove every single line of code.
WORKING OF THE PLUGIN
Credits
Closing Thoughts
Atom is ultimately an exploration of how design systems can retain memory as they grow. The project highlights that clarity does not come from creating more components, but from preserving the reasoning behind them. By embedding documentation directly into the act of designing, ATOM shifts documentation from a delayed task to a continuous practice.
WORK INVOLVED
Product Design
Design Systems
User Research
Artificial Intelligence
API integration
Tools
Figma
Cursor
Claude Code
team
Design
Ishika Dixit
Motion
Ishika Dixit
Research
Ishika Dixit
Writing
Ishika Dixit
