Case 03 · Talkspirit · Product design · UI · Design system

A design system isn't a toolkit. It's a shared language.

Built to enforce consistency across UI and UX, align designers with developers, and let teams reinvent less so they can solve more meaningful problems. This is how I structured it, from accessible color scales to a token architecture that keeps design and code in sync.

Role: Product Designer
Tools: Figma · Tokens Studio · Storybook
Product: Talkspirit · Holaspirit
Scope: Tokens · Figma architecture · accessibility

Design systemDesign tokensAccessibilityThemingDev handoff

Why a system

A shared language that lets teams reinvent less.

A design system is central to a designer's work, helping to enforce best practices and maintain consistency across UI and UX design. It also aligns with developers, allowing them to easily find both new and existing components that may need refinement.

More than just a toolkit, it works as a shared language that reduces friction, aligns user experience, and documents patterns and guidelines, empowering teams to reinvent less and solve more meaningful problems.

Basics & accessibility

Color in scales, with accessibility on the surface.

We built the color palette in scales (100, 200, 300, etc.), so every color family stays consistent. That way, a "100" shade always has the same lightness, whether it's neutral, burgundy, orange, or blue. It makes hover states, buttons, and backgrounds feel natural and balanced, behaving consistently across the system.

The deactivated swatches indicate what is not currently in use, making it easy to see where the brand sits within the wider color spectrum.

The color families in 100–900 scales, with default tags and contrast warnings.

Color built in scales, with "default" tags and contrast warnings surfaced on the swatches.

A "default" tag marks the standard choice in each family, keeping the palette clean. Some shades don't fully meet accessibility standards but were kept because they carry real brand decisions. Rather than hide that, I flagged them with a warning and their contrast ratio against white. Everyone can sees the limitation at a glance and can still make a thoughtful call, with the door open to WCAG 2.1 AA compliance later.

Design tokens

Three layers that keep design and code in sync.

Tokens are how I keep design and code in sync. I built them in three layers: options → decisions → components. Options are the raw values (the color scales, the text sizes, the spacing). Decisions give those values a job: "this red means danger". Components only ever use decisions, never raw values. So when I change one option, it flows through the whole system automatically.

Option · primitive

blue/800 · #015AD1

A raw value. Means nothing on its own.

Decision · semantic

action/primary → blue/800

Gives the value a job: "this is the primary action."

Component

Button CTA → action/primary

Uses the decision, never the raw value.

Change blue/800 once, and every call to action across the product updates automatically.

That layering is also what makes theming simple. The product runs three brand themes (burgundy, blue, and orange) that a client can switch between. Only the accent color changes; the feedback colors (danger, warning, info, success) are shared across all three, so the error red never moves by accident.

I chose Tokens Studio over Figma's native variables on purpose: it keeps these references intact, handles full typography styles, and exports to JSON that developers use straight in their code.

Tokens Studio: options, decisions, and themes, exportable to JSON for developers.

Organization

A file structured so nothing gets lost.

Three sections, each on its own pages: Foundations, Components, and Patterns. Components hold elements like buttons and fields. Patterns cover cards and navigation. Related variants sit together in one frame like every toggle button in a single place so it's easy to find, and the system stays scalable.

The Figma file: Foundations, Components, and Patterns, variants grouped in frames.

Foundations · Components · Patterns · Variants grouped in frames, atomic hierarchy underneath.

For more complex elements, I used an atomic approach (atoms, molecules, organisms) separating the simplest building blocks from larger structures like a kanban board. Page separation plus atomic hierarchy keeps the system quick to navigate and flexible enough to grow into advanced components.

An atomic approach: atoms and molecules composed up into larger organisms.

An atomic approach separates simple building blocks from larger structures.

How it lives across teams

A system is only as good as the teams it keeps aligned.

The real value is not the file but it is the shared understanding around it. That meant building two bridges: one to engineering, one to Marketing and Support (who tell users what's new).

With developers

Storybook as a living mirror

Every component and color is documented in Storybook as a mirror of the design system, so developers see exactly how things should look and behave before they ship. Weekly updates keep both sides aligned on what has been added, refined, or still needs work.

Storybook: the same components, documented for engineering.

With marketing & support

Telling users what's new, in-product

Users often missed new features. We leaned too hard on campaigns and the support team to spread the word. I closed that gap with a full page of feedback components: pop-ins, bubbles, banners, and quick dismissible tutorials that show new functionality right where it lives. Communication turned timely and natural rather than reactive.

Modals, surveys, and banners: a shared kit for in-product communication.

The takeaway

Accessibility, consistency, and organization shape more than the interface.

I learned how accessibility, consistency, and good organization can shape more than just the interface. They also change the way teams work together, turning a design system into something living that helps everyone move in the same direction.