Figma is often used as a digital canvas, but treating it like Photoshop can cripple a design system. This post explores why we must move the source of truth into code to ensure responsiveness, consistency, and AI readiness.
In recent months, my work has focused heavily on the architecture of a robust design system for a complex product. While Figma has undoubtedly revolutionised the way designers and developers collaborate, it has also introduced a set of unique challenges that often stem from a fundamental misunderstanding of what a design system actually is. It is not merely a collection of static layouts; it is a living, breathing framework of rules and components.
One of the primary hurdles we have encountered is the tendency for Figma to be treated like its predecessor, Photoshop. We often see high-fidelity, pixel-perfect representations of a desktop site at exactly 1440px wide. While these mocks look beautiful, they frequently fail to account for the fluid nature of the modern web. Converting these static artboards into modular, reusable, and dynamic components that behave predictably across all screen and device types is where the real work begins.
The Photoshop Trap: Static Layouts vs. Dynamic Components
When a design is created as a static canvas, it encourages a mindset of fixed positioning and hard-coded values. This is what I call the Photoshop Trap. In a design system, we do not just build a header; we build a responsive navigation container that must handle varying content lengths, internationalisation, and viewport constraints. When developers receive a Figma file that only shows the happy path on a desktop screen, we are forced to make assumptions about how elements should wrap, shrink, or stack on a tablet or a mobile device.
To overcome this, we have had to shift our workflow toward component-driven development. This involves breaking down those pixel-perfect mocks into their atomic parts. We ask questions like: How does this padding change on mobile? Is this width a percentage or a fixed pixel value? By treating Figma as a conceptual guide rather than a blueprint, we can focus on building components that are truly agnostic of their parent container. This ensures that the system remains scalable, whether we are building a simple landing page or a complex dashboard like the one I developed for the AI Powered Event Management CMS.
The Limitations of Figma Tokens
Design tokens are intended to be the DNA of a design system - the smallest building blocks like colours, typography, and spacing. Figma has made strides with its Variables feature, but it still feels like a layer on top of a drawing tool rather than a data-driven system. The current token system in Figma often lacks the logic and inheritance capabilities required for advanced implementations.
For instance, managing multi-brand themes or complex dark mode transitions within Figma can quickly become a manual nightmare. The friction occurs when trying to synchronise these tokens with our codebase. We want a single source of truth where a change to a primary brand colour in one place propagates everywhere. Currently, the bridge between Figma tokens and CSS variables or TypeScript objects is often held together by third-party plugins or manual exports, which introduces the risk of human error and version drift.
Code as the Source of Truth: Google Stitch and Beyond
Because of these limitations, many forward-thinking companies are moving the source of truth out of the design tool and into the code. Google Stitch is a prime example of this philosophy. By defining the design system in code first, developers and designers can ensure that the constraints of the medium - the browser - are respected from day one.
When the design system lives in code, we can utilise tools like TypeScript to enforce strict adherence to the system. This approach allows us to define our tokens in a structured format that can be consumed by multiple platforms. Below is an example of how we might define a theme configuration that acts as the authoritative source for both our styling engine and our documentation.
// theme-provider.ts
export const designSystem = {
colours: {
primary: {
base: '#0055FF',
hover: '#0044CC',
active: '#0033AA',
},
surface: {
default: '#FFFFFF',
subtle: '#F4F7FA',
},
},
spacing: {
unit: 4,
xs: '4px',
sm: '8px',
md: '16px',
lg: '24px',
xl: '32px',
},
breakpoints: {
mobile: '320px',
tablet: '768px',
desktop: '1024px',
wide: '1440px',
},
} as const;
export type Theme = typeof designSystem;By defining our constraints here, we remove the ambiguity of the Figma file. If a designer asks for a 15px gap, the code-driven system provides an immediate check: that value does not exist in our spacing scale. This rigour is essential for maintaining consistency across a large-scale project.
The AI Implementation Advantage
Perhaps the most compelling reason to move toward a code-first design system is the future of AI-driven development. Large Language Models (LLMs) are exceptionally good at understanding structured data but struggle to interpret the nuances of a visual canvas without extensive context. If your design system is defined in a clear, semantic, and versioned code repository, you provide a map for AI to build interfaces on your behalf.
In my project, the AI Integrated Content Creation Workflow, I saw first-hand how providing an LLM with structured guidelines allowed it to generate content that felt native to the platform. The same applies to UI. If an AI agent knows your components, your tokens, and your layout rules through a JSON schema or a TypeScript library, it can generate entire page layouts that are already compliant with your brand. It turns the AI from a general-purpose tool into a specialist that understands your specific design language. This is significantly more efficient than asking an AI to guess the intent behind a Figma screenshot.
Conclusion
Figma is a fantastic tool for ideation and visual communication, but it should not be the ultimate authority for a design system. To build truly resilient products, we must move away from the pixel-perfect Photoshop mentality and embrace a code-first approach. By centralising our tokens and components in code, we bridge the gap between design and development, reduce technical debt, and prepare our infrastructure for the next wave of AI-integrated workflows. The future of design is not a drawing; it is a system of logic.