Design Systems
Creating reusable design foundations for clearer, more consistent digital products.
I help structure design systems around components, patterns, variables, design tokens, naming conventions and practical documentation. The goal is to make interface decisions reusable, scalable and easier to connect with implementation.
- SaaS Platforms
- Enterprise Tools
- Multi-page Interfaces
- WordPress Sytstems
- Headless Builds
- Code Consistency
- Service Products
- Complex Web Apps
- Content-heavy Systems
- Mobile Apps
What Design Systems mean in practice
It’s not just about a UI kit. Truly useful design system captures repeated design decisions and turns them into reusable components, patterns, variables, tokens and documentation. It helps teams avoid redesigning the same interface decisions again and again.
In practice, this can include typography, colour, spacing, grids, components, interaction states, responsive behaviour, accessibility rules, naming conventions, Figma libraries, design tokens and front-end-ready documentation. For me, a design system should work on more than one level: it should be clear enough for designers to use, structured enough for developers to implement, and flexible enough to support future product growth.
Problems I help solve
- The interface looks inconsistent across screens, pages or product areas
- Design decisions are repeated manually instead of reused
- Figma files are difficult to maintain or understand
- Components exist, but naming and structure are unclear
- Design tokens or variables are missing, duplicated or poorly mapped
- Colours, typography and spacing are used inconsistently
- Design and code drift apart over time
- Responsive behaviour is handled case by case instead of systemically
- Developers receive screens, but not enough rules, states or reusable logic
- The system is too visual and not connected enough to implementation
How I approach Design Systems
I start by identifying repeated decisions: colours, typography, spacing, layout rules, components, states and interface patterns that appear across the product or website.From there, I structure the system in layers — from primitive or brand-level values, through semantic aliases, to mapped tokens and component-level usage.I use Figma Variables where they provide a clear, native UI for designers, and Tokens Studio where a more powerful token workflow is needed, especially when tokens need to be synced, versioned or connected with code through GitHub and transformation tools.The goal is not to create a complicated system for its own sake. The goal is to make design decisions easier to reuse, explain, maintain and implement.
Token structure & naming approach
I usually think about design tokens in layers:
Brand / primitive tokens
The raw design values: brand colours, spacing scale, typography scale, radius, shadow and other foundational values.
Alias / semantic tokens
Reusable design meanings that sit above raw values, such as primary colour, secondary text, small radius or standard border width.
Mapped / usage tokens
Context-specific tokens that describe where the value is used, such as surface error, border warning, text muted or action primary background.
Example:
Brand / primitive
color.ocean-blue.100
color.ocean-blue.500
spacing.4
radius.md
Alias / semantic
color.primary.100
color.text.default
border-width.sm
radius.card
Mapped / usage
color.surface.error
color.border.warning
color.text.subtle
color.action.primary.background
Naming conventions
Naming conventions are one of the most important parts of a design system.
A good naming convention should be readable, predictable and useful across design and development. It should make it clear whether a token is a raw brand value, a semantic alias or a context-specific usage token.
For example, I prefer a layered naming approach:
brand / primitive
color.ocean-blue.100
alias / semantic
color.primary.100
mapped / usage
color.surface.error
color.border.warning
color.action.primary.background
Figma Variables and Tokens Studio
I use both Figma Variables and Tokens Studio, depending on what the system needs.
Figma Variables are useful when the priority is clarity inside Figma: designers can work with native collections, modes and reusable values directly in the design file. They are especially helpful for colour modes, typography values, spacing, layout values and responsive design decisions.
Tokens Studio is more powerful when the token system needs to be managed, transformed, synced or connected with code. GitHub sync, token JSON, support for DTCG-style token formats and Style Dictionary workflows make it useful for more advanced design-to-code pipelines.
Responsive variables / responsive token collection
For responsive design, I like keeping a separate collection for values that change across screen sizes.
This can include typography size, line height, paragraph spacing, section spacing, grid values, container widths, component spacing or other layout-related parameters.
Instead of manually adjusting every screen, responsive variables make it easier to define how the interface should adapt across breakpoints.
Collection: Responsive
Modes:
mobile
tablet
desktop
large desktop
Variables:
font.size.body
font.size.heading.lg
line-height.body
paragraph.spacing.default
section.spacing.md
container.max-width
grid.columns
component.padding.card
What Design Systems can include
Design foundations
Colour, typography, spacing, radius, shadow, grid and layout rules.
Figma Variables
Native reusable values for colour, numbers, strings and modes inside Figma.
Design tokens
Platform-agnostic design decisions that can be transformed and used in code.
Token hierarchy
Primitive, semantic and mapped token layers that separate raw values from usage.
Naming conventions
Readable and predictable naming for tokens, variables, components and styles.
Responsive variables
System-level values that change across screen sizes and layout contexts.
Components
Reusable UI elements such as buttons, inputs, cards, tables, modals, navigation and alerts.
Component states
Hover, focus, active, disabled, loading, empty, error, warning and success states.
Patterns
Reusable interface solutions for forms, dashboards, filters, tables, detail panels and workflows.
Documentation
Usage notes, examples, do/don’t guidance, accessibility notes and handoff information.
Design-to-code workflow
Connecting Figma, tokens, GitHub, Style Dictionary and front-end implementation where appropriate.
Typical artefacts
Design foundations
Design foundations define the basic visual and structural rules of the interface.
This can include colour, typography, spacing, radius, shadows, grids, layout rules and responsive behaviour. These foundations shape how the product feels before individual components are designed.
Why it mattered
Figma Variables
Figma Variables provide native reusable values inside Figma.
They can be used for colours, numbers, strings and design modes. I use them when the system needs to stay clear and practical for designers working directly in Figma, especially for theming, spacing, typography values and responsive decisions.
Design tokens
Design tokens turn design decisions into reusable values that can be shared across design and development.
They can represent colours, typography, spacing, radius, shadows and other visual properties. When structured well, tokens help reduce inconsistencies and make it easier to connect design tools with code.
Token hierarchy
Token hierarchy defines how design values are layered.
I usually separate tokens into primitive or brand values, semantic aliases and mapped usage tokens. This keeps raw values separate from their role in the interface, making the system easier to maintain, theme and extend.
Naming conventions
Naming conventions make a design system easier to understand and maintain.
Good names should explain the role of a token, component or pattern without requiring people to inspect the value manually. I prefer names that are readable, layered and predictable across both design and code.
Responsive variables
Responsive variables define values that change across screen sizes or layout contexts.
This can include font sizes, line heights, paragraph spacing, section spacing, container widths, grid settings and component spacing. Keeping these values in a dedicated responsive collection makes responsive behaviour easier to manage systematically.
Components
Components turn repeated interface elements into reusable building blocks.
This can include buttons, inputs, cards, navigation, tabs, tables, modals, alerts, filters and status indicators. Good components are not only visually consistent — they also define behaviour, variants, states and usage rules.
Component states
Component states define how interface elements behave in real use.
This includes default, hover, focus, active, disabled, loading, selected, empty, error, warning and success states. These states make the interface more predictable, accessible and implementation-ready.
Patterns
Patterns are reusable solutions to common interface problems.
A pattern might describe how filters work, how a multi-step form behaves, how a dashboard presents status, how a detail panel opens, or how errors are handled across the product.
Patterns help teams avoid solving the same interaction problem differently every time.
Documentation
Documentation explains how the design system should be used.
This can include usage notes, examples, do/don’t guidance, accessibility notes, component behaviour, responsive rules and implementation considerations.
Good documentation helps the system become a shared product language rather than a collection of detached components.
Design-to-code workflow
A design system becomes more powerful when it connects with implementation.
Depending on the project, this can involve Tokens Studio, GitHub sync, token JSON, Style Dictionary, CSS variables, component documentation, Storybook or front-end handoff.
The goal is not to over-engineer every project, but to create a workflow where design decisions can move into code more consistently.
Design Systems for different types of work
Information architecture usually sits between UX strategy and detailed interface design.It often follows discovery, audits or product analysis, and creates the structure that UI design, content and development can build on.
In many projects, IA is the point where vague requirements become a clearer model: which pages or product areas exist, how they connect, what each one is responsible for and how users move through them.
For digital products
For products and platforms, design systems help maintain consistency across many screens, states and workflows.
They are especially useful when the product includes dashboards, forms, data tables, filters, status indicators, permissions, alerts, modals and reusable workflow patterns.
For websites
For websites, design systems can define page sections, typography, spacing, buttons, cards, navigation, forms, content blocks and responsive behaviour.
This is useful for WordPress, Elementor, headless WordPress, static sites and multi-page business websites where consistency and maintainability matter.
For enterprise platforms
For enterprise platforms, design systems need to handle density, complexity and role-based behaviour.
Components often need to support technical detail, status visibility, error handling, permissions, audit trails, accessibility and implementation constraints.
For design-to-code workflows
For design-to-code workflows, the system needs clear naming, token hierarchy, documentation and a practical way to move design decisions into implementation.
This may involve Figma Variables for design clarity, Tokens Studio for token management, GitHub sync for versioning, and Style Dictionary or similar tooling for generating code-friendly outputs.
Related areas
UX Strategy · Product Design · UI Design · Front-End Development
Related work
Selected projects where design system thinking helped create clearer, more consistent and more scalable digital experiences.
Enterprise Automation Platform
Product Design · Design Systems · UI Design
Identifying reusable workflow patterns, status models, tables, filters and interface structures for a complex enterprise product.
Related Certifications
NN/g’s Certified
Certified in UX Management by Nielsen Norman Group
My UX Management Specialty supports the way I work with product teams, stakeholders and complex decision-making — not only designing screens, but helping structure the process behind them.
Methods & Tools
User Interviews · Usability Testing · Heuristic Evaluation · UX Audits · Journey Mapping · Workshops · A/B Testing · Card Sorting · Data Analysis
Need better consistency between design and code?
I can help structure the design foundations, tokens and components that make products easier to design, build and maintain.
