Context
Fractalia Cybersecurity is the consumer and SMB cybersecurity arm (antiphishing, identity monitoring, cloud backup, legal advice, device protection) of a Spanish tech group with an international footprint, providing ICT services to telecom operators, insurers, banks and retailers under a B2B2C model.
I joined Fractalia as Senior Product Designer with a clear mandate: turn the existing design system into something development could actually build from, without slowing delivery down as the product scaled. The diagnosis in the first weeks was straightforward — the system existed as a set of carefully crafted screens in Figma, not as an operational language shared with development. What was missing wasn’t craft; it was structure: a design system that had been growing for years without a layer that let that knowledge be reused outside Figma.
That gap showed up in three concrete ways:
The Friction
Design System
There was no design system with reusable, well-organised components for development.
Tokens & Naming
There were no design tokens or consistent naming between Figma and the development code.
Development
Without a unified component system, Fractalia's interface kept accumulating visual inconsistencies.
Consequences
No Common Reference
Every screen was built almost from scratch, repeating the same inconsistency in every implementation or rebuilding graphic elements.
Disconnected Documentation
Without a real design system behind it, the little documentation that existed was imprecise and scattered across elements.
Knowledge You Couldn't Query
There was no way for the AI used by development to query component documentation directly, made worse by the inconsistencies and technical debt.
The Process
My first move, as the person now responsible for that system, was to rebuild it properly in Figma, starting from its underlying structure: components were reorganised and reclassified into a coherent system, with parent components and correctly inherited variants. The library now runs to 886 components counting every variant, 196 of them parent components documented in depth in Supernova — measurements, tokens, states, variants — a joint effort with the rest of the design team.
On top of that structure came a two-layer token system, primitives and semantics: 109 colour tokens and 179 foundation tokens (spacing, radius, border-width, typography), all documented and officially rolled out in production — 288 tokens in total across both layers.
Everything was built to WCAG 2.1 AA and AAA, in line with European accessibility law: the European Accessibility Act came into force on 28 June 2025 — within this very project’s timeframe — and requires sectors like banking, insurance and telecoms to comply with EN 301 549, which fully incorporates WCAG 2.1 AA.
0+
Accessible components in Figma
0+
Tokens documented & implemented
0+
Components in Supernova
On that foundation, the solution wasn’t a new screen or a new tool — it was connecting the steps that already existed in the design flow so they worked as one continuous pipeline, where the output of each step feeds automatically into the next. That’s what an emerging speciality within product design, Spec Driven Design, is really about: just as development now works with AI generating code from instructions and shifts its own role to auditing what comes out, product design needs the same kind of bridge — a structured, unambiguous document the AI can read directly, rather than a screen it has to interpret.
That’s why every service I design ships with its own SPEC in .MD format, not just the screen in Figma: which design-system components it’s built from and with which tokens, all the copy, every state and edge case — loading, error, empty, blocked, completed — the screen architecture by breakpoint, and the service’s specific accessibility criteria. Every service Fractalia offers is now documented this way. The SPEC, not the screen, is the real handover point to development: if it’s complete, there’s no room left for guesswork.
Service brief
Wireframe
Claude design
Iteration & validation
Figma ready
Responsive
Spec/MD
Rgeneration
Handoff & Walkthrough
Service
development
¿Where AI comes ?
the brief that comes from the product owner already has the product’s needs worked through, with solid context behind it. AI analyses it in depth and passes it on to Claude Design, which produces the high-fidelity wireframe, covering every likely use case and every screen in the flow.
That wireframe then goes back to the product team, and a thorough round of iteration follows until we land on the prototype we want. Once it’s validated, it moves into Figma — already connected via MCP — for the final, responsive design, with RTL where the service calls for it.
Once the design is locked, the SPEC gets generated in MD, handoff wraps up with a walkthrough, and development builds the service with AI through vibe coding — querying live, over MCP, both that service’s SPEC and the 201 documents and components already sitting in Supernova, plus all the service’s technical documentation, held in an internal repository — Directus, in this case.
The Quality System
Automating handoff demanded a level of control as strict as the manual process. Seven quality gates were defined before any piece reached development.
Design lock
No change reaches the spec without the design being frozen and versioned.
Design system
Verification of tokens, components and patterns against the official library.
Accessibility Review
A11y check before moving to specification.
Component Inventory
What exists, what gets reused, what's new.
MD Package
The service's SPEC must be complete before moving to handoff.
Internal Audit Log
Traceability of every change, for the team and for compliance.
Walkthrough
Handoff and development don't start without a joint review with the development team.
Results
What follows is a direct consequence of putting this system in place and refining it — design system, tokenisation, accessibility, and an AI pipeline governed by specs and quality gates — inside the real day-to-day flow of product design. Integrating AI operationally, rather than as a one-off experiment, is what made it possible to audit at a scale that would have been unworkable by hand, fix issues with real precision, and cut delivery times that used to depend entirely on manual pace.
And it’s measurable: 416 pages of documentation reviewed, 917 findings, 111 errata fixed without disrupting production, 100% of the affected components brought to full consistency, and roughly a 50% cut in a product’s delivery time. These are process and documentation figures — not product or business ones, under NDA — but they point to something bigger: bringing AI into product design in a structured way doesn’t cost you rigour or judgement. It multiplies efficiency without giving up either.