Design systems: from one product to many, and the pitfalls in between

[Aior]

Tasarım sistemleri altyapıdır, yan proje değil​

Bir tasarım sistemi, bir ekibin tutarlı ürünü daha hızlı inşa etmesini sağlayan bileşen, token, desen ve dokümantasyon setidir. İyi yapıldığında hızı artırır ve kaliteyi yükseltir. Kötü yapıldığında kimsenin kullanmadığı paralel bir kod tabanıdır.

Olgunluk merdiveni​

1. Stil rehberi — renkler, tipografi, boşluk bir doc / Figma'da belgelenmiş. Kod yeniden kullanımı yok.
2. Bileşen kütüphanesi — kodda tekrar kullanılabilir bileşenler. Tutarsız adoption.
3. Tasarım sistemi — bileşenler + tokenlar + desenler + dokümantasyon, adoption metrikleriyle.
4. Çoklu ürün platformu — birden çok ürünü kapsayan tasarım sistemi.

Çoğu ekip seviye 3'ü hedeflemeli ve orada durmalı. Seviye 4 kendi mühendislik ekibiyle kurumsal altyapıdır.

Hex kodlar değil, token'lar​

• Bir kez tanımlanır, her yerde kullanılır.
• Kodda mevcut (CSS custom properties, JS sabitleri).
• Tasarım araçlarında mevcut (Figma değişkenleri / stiller).
• Senkronize — Style Dictionary, Tokens Studio ile Figma → kod.

Hata: bileşenlerde sabit kodlanmış hex değerleri. Marka güncellemesi sistemi bozar.

Ölçeklenen bileşen tasarımı​

• Öngörülebilir varyasyonlar için varyantlar (size, intent, state).
• İçerik değişimi için slot / children.
• Mantıklı varsayılanlar.
• Konfigürasyon yerine kompozisyon.
• Varsayılan olarak erişilebilir — klavye, ekran okuyucu, focus yönetimi.

Okunan dokümantasyon​

• Kod örnekleri (çalışan, kopyala-yapıştır).
• Görsel örnekler.
• Kullanım yönergeleri.
• Erişilebilirlik notları.
• Açıkça belirtilen anti-desenler.

Storybook + MDX + bir stil rehberi sitesi 2026'da yaygın yığın.

Adoption zorluğu​

Hiçbir ekibin kullanmadığı tasarım sistemi yan projedir.

• Sistemi kendi yapmaktan daha kolay yapın.
• Code review uygulaması — sistem dışı bileşenler gerekçe ister.
• Tasarım pair-with — ürün incelemelerine tasarım sistemi tasarımcısı.
• Adoption metrikleri — sistem bileşenleriyle inşa edilen UI %.
• Migration scripti — bileşenler evrildiğinde codemod gönderin.

Yönetişim​

• Federe — herkes önerebilir, çekirdek ekip inceler.
• Merkezî — yalnızca çekirdek ekip değişiklikleri kabul eder.
• Hibrit — federe'den kabul edilen desenler; çekirdek ekip konsolide eder.

Versiyonlama​

• Paketin semantic versioning'i.
• Breaking change'ler için major sürümler, codemod ile.
• Deprecation döngüsü (uyar → destekle → kaldır).
• Üretimde aynı anda birden çok sürüm normaldir.

Figma-kod senkron sorunu​

• Tokens Studio + Style Dictionary ile token'lar.
• Figma'dan Storybook'a bileşen dokümantasyon bağlantıları.
• Tasarım QA — tasarımcılar amaca karşı inşa edilen bileşenleri inceler.
• "Source of truth" kararı — kod mu Figma mı? Her artifact için birini seçin.

Uyaracağımız bir desen​

Erken tasarım sistemi. Konsolide edecek 2-3 ürünü olmadan sistem inşa eden ekip altyapı spekülasyonu yapıyordur.

Her zaman karşılığını veren bir desen​

"Sistem katkıcısı" rolü — açık görevi adoption'ı desteklemek, codemod yazmak, office hours yapmak olan biri.

Tasarım sistemi yığınınız nedir?

Design systems are infrastructure, not a side project​

A design system is the set of components, tokens, patterns, and documentation that lets a team build consistent product faster. Done well, it accelerates velocity and elevates quality. Done badly, it's a parallel codebase that nobody uses.

The maturity ladder​

1. Style guide — colours, typography, spacing documented in a doc / Figma. No code reuse.
2. Component library — reusable components in code. Inconsistent adoption.
3. Design system — components + tokens + patterns + documentation, with adoption metrics.
4. Multi-product platform — design system spanning multiple products.

Most teams should aim at level 3 and stop. Level 4 is enterprise infrastructure with its own engineering team.

Tokens, not hex codes​

• Defined once, used everywhere.
• Available in code (CSS custom properties, JS constants).
• Available in design tools (Figma variables / styles).
• Synced — Figma → code via Style Dictionary, Tokens Studio.

The mistake: hard-coded hex values in components. The brand-update breaks the system.

Component design that scales​

• Variants for the predictable variations (size, intent, state).
• Slots / children for content variation.
• Sensible defaults.
• Composition over configuration.
• Accessible by default — keyboard, screen reader, focus management.

Documentation that gets read​

• Code examples (working, copy-pasteable).
• Visual examples.
• Usage guidelines.
• Accessibility notes.
• Anti-patterns explicitly called out.

Storybook + MDX + a styleguide site is the common stack in 2026.

The adoption challenge​

A design system that no team uses is a side project.

• Make the system easier than rolling your own.
• Code review enforcement — non-system components require justification.
• Design pair-with — design system designer in product reviews.
• Adoption metrics — % of UI built from system components.
• Migration scripts — when components evolve, ship the codemod.

Governance​

• Federated — anyone can propose, core team reviews.
• Centralised — only the core team accepts changes.
• Hybrid — accepted patterns from federated; core team consolidates.

Versioning​

• Semantic versioning of the package.
• Major versions for breaking changes, with codemods.
• Deprecation cycle (warn → support → remove).
• Multiple versions in production simultaneously is normal.

The Figma-code sync problem​

• Tokens via Tokens Studio + Style Dictionary.
• Component documentation links from Figma to Storybook.
• Design QA — designers review built components against intent.
• "Source of truth" decision — code or Figma? Pick one for each artefact.

One pattern we'd warn about​

Premature design system. A team building a system before they have 2-3 products to consolidate is doing infrastructure speculation.

One pattern that always pays off​

A "system contributor" role — someone whose explicit job is to support adoption, write codemods, run office hours.

What's your design system stack?