The foundational design system powering Fitch’s ecosystem was built to unify interfaces, scale new features, and reduce dev overhead. I created component libraries, pattern architecture, and shared guidelines to support cross-product consistency.
When I tell people that I still create spec sheets (even with Figma Dev mode) I get raised eyebrows. But there’s a method behind it. Designing at scale, across multiple teams, means you need clarity, consistency, and a shared language. That’s what “Blueprints for the Build” is about: my approach to making UI systems understandable, maintainable, and extensible.
The Problem: Ambiguity & Drift in Design Systems
Without unified standards, product teams interpreted shared components differently leading to visual drift, inconsistent logic, and redundant code debt across applications.
In reality, there’s friction:
-
Developers may not have direct access or understand how to find what matters.
-
Base components get broken or misused due to missing constraints or unclear rules.
-
The amount of “noise” in art boards and file complexity often buries what’s important.
-
Updates and changes are inevitable. Without a clear procedure, components slip into one-off customizations or inconsistencies.
My Approach & Workflow
I believe that good design documentation, spec clarity, and version control enable teams to move faster, not slower.
Here’s how I do it:
Component Audit & Pattern Definition
I review existing components at the “molecule” level (smallest reusable units) and identify drift, duplication, or missing rules.
Spec Sheets as Source of Truth
I generate lightweight, focused PDF spec sheets from Figma showing padding, component usage, constraints, and flow context. These specs are meant for developers, not for show.
Versioned Spec Linking
The process is simple: upload the PDF to a shared drive, link it in the story / ticket. When a spec changes, replace the PDF: the link stays the same, so stories auto-reference the updated spec.
Developer Alignment & Documentation
he specs highlight only what devs need: dimensions, constraints, component rules, and key flows. No noise, no extra fluff. The goal: reduce assumptions and questions during development.
Reflection / Why It Matters
Having led large-scale redesigns and system builds, I’ve come to see that the invisible scaffolding (specs, documentation, shared rules) is as critical as the polished screens. Without it, teams diverge, standards erode, and design debt balloons.
The system became a foundation for speed, quality, and visual alignment across Fitch’s ecosystem, and a model for future platform initiatives.
Skills
-
Attention to Detail
-
Print media background
-
Team guidance
-
Product buy-in / Presentations
-
Component creation (Figma)
-
Dev mindset
Technology Used
-
Figma, Confluence, and more Figma