How long does a design system take?

A first usable release — tokens, the core components and the documentation to use them — typically ships in eight to twelve weeks. The system then grows with the product; we stay on as governance or hand over to an in-house owner.

Do we need to rebuild our product?

No. The system is introduced where the next feature is built and migrates existing screens as they are touched. Nothing is rewritten for its own sake.

Which stack do you work in?

Design in Figma with variables and Code Connect; code as web components, React or whatever your product already uses. Tokens are platform-agnostic by construction.

Who owns it after launch?

You do. Everything is delivered into your repositories and your Figma, with the decision records that explain why it is the way it is.

Capability

Design system agency

Token architecture, component libraries and the governance that keeps them alive — for product organisations running more than one brand, more than one platform, or more than one team.

Request an audit → See the twelve-brand case

Why this matters more than a redesign

Redesigns decay. Six months after launch, a marketing page uses a button that does not exist in the library, a new feature ships with its own modal, and the mobile team has quietly forked the colour palette. Nobody did anything wrong — there was simply no cheaper path than forking.

A design system changes the economics. When the shared component is the fastest thing to reach for, consistency stops being a policy people have to remember and becomes the default outcome.

This is also the part of design work with a defensible business case: fewer duplicated builds, one accessibility fix instead of six, faster market launches, and onboarding measured in days rather than in tribal knowledge.

Scope

What a system from us contains

Layer 01

Design tokens

Three-tier token architecture — primitives, semantic roles, component aliases — maintained as data and consumed identically by Figma and code.

Layer 02

Component library

Components documented with every state, keyboard behaviour, ARIA contract and the tokens they consume. Built to WCAG 2.2 AA as a baseline, not as a retrofit.

Layer 03

Multi-brand theming

Brand as a configuration value. Adding a brand is a theme file; changing a brand does not touch component logic.

Layer 04

Documentation

Written for implementers under deadline: what it is for, when not to use it, and what breaks if you fork it.

Layer 05

Governance

Contribution process, review path, exception handling and deprecation policy — the layer that decides whether the system survives its first year.

Layer 06

Adoption

Migration sequencing, team workshops and office hours. A system nobody adopts is a cost with no return.

Process

How we run it

Audit

We inventory what exists — every button variant, every colour in production, every component that has been forked — and map where drift is actually costing you. Four to six weeks, delivered as a written report you own whether or not we continue.

Token architecture

We define the three-tier token model and the naming convention, then validate it against your hardest case: the brand or platform that fits least well.

Core library

We build the components that appear in your highest-traffic journeys first, in stages, so teams adopt while we are still building rather than after.

Parity and handover

Figma library and code library are aligned, documented and versioned. Your team can extend the system without us in the room.

Governance

We install the contribution and review process, run the first cycles with your team, and then step back to an advisory cadence.

Proof

Systems we have shipped

Beko

Beko Careers — designed, systematised, built

A global careers platform for a 45,000-person employer: UX, interface design, a component system, and the front-end build against SAP. Live.

LiveUX designDesign systemFront-endSAP

Beko · Grundig

One design system, a whole brand portfolio

A token architecture and component library that keeps each brand visually distinct while sharing one interaction model and one release path.

Design systemTokensComponent libraryGovernance

Whirlpool Group

Four brands, four themes, one library

UI libraries and interface systems for Whirlpool, Bauknecht, Hotpoint-Ariston and Indesit — built so a brand is a theme file, not a fork.

UI libraryThemingMulti-brand

Arçelik Group

Six more brands, six more markets

UI systems and web interfaces for Defy, Arctic, Altus, Blomberg, Elektra Bregenz and Leisure — each in a market with its own retail habits and device mix.

UI systemsWeb interfacesLocalisation

Design system FAQ

What exactly is a design system?

A design system is the shared source of truth a product organisation designs and builds from: design tokens (colour, type, spacing, radius, elevation as data), a component library with defined states and accessibility behaviour, usage documentation, and a governance model that decides how it changes. A style guide describes how things should look. A design system makes the correct thing the easiest thing to ship.

How is a design system different from a UI kit?

A UI kit is a file of components. A design system is a contract between design and engineering: the same component name, the same states and the same tokens exist on both sides, and there is a defined process for changing them. A UI kit drifts within a quarter. A system has an owner, a version and a deprecation path.

We run several brands. Do we need one system or several?

One system, several token sets — in almost every case. Brand difference belongs in the theme layer: colour, typography, radius, tone. Component behaviour, accessibility and interaction patterns should be shared. That is exactly the architecture we built for a twelve-brand portfolio spanning two competing manufacturing groups — and adding the thirteenth brand is a theme file, not a project.

How long does building a design system take?

An audit and token architecture typically takes four to six weeks. A production-ready core library covering the components that actually appear in your top user journeys usually runs three to five months, delivered in stages so teams can start using it before it is finished. A system that is never adopted is worse than no system, so we sequence for adoption, not for completeness.

What does a design system project cost?

Pricing depends on the number of brands, the number of platforms (web, mobile, on-device) and whether we deliver design only or design and front-end code. We scope in three tiers — audit, core library, and ongoing governance — so you can commit to the first before deciding on the rest. Ask us for a scoped estimate and you get a written breakdown, not a single number.

Do you work in Figma?

Yes, and we keep Figma and code in parity rather than treating Figma as the deliverable. Tokens are maintained as data that both sides consume, so a change to a semantic token propagates to the library and to the codebase instead of being reapplied by hand.

Can you take over a design system we already started?

Frequently. Most systems we are asked about already exist in some form — a component page in Figma, a partial token file, a library one team maintains and nobody else uses. We start with an audit of what is there, what is actually being used, and where the drift is, then propose what to keep.

Do you work with clients outside Türkiye?

Yes. We work in English, we are one hour ahead of Berlin and two ahead of London, and our core reference is a brand portfolio sold across many markets. Remote collaboration with product teams in Europe is the normal working mode, not an exception.

Let's make the next one together.

hello@piaadworks.com