Design system, Figma’da düzenli duran bir UI kit veya kod tarafında bir component klasörü değildir. Üründe tekrar eden tasarım kararlarını tanımlayan, tasarım ve geliştirme çıktısını birbirine bağlayan, ekipçe nasıl değiştirileceğini açıklayan yaşayan bir ürün altyapısıdır. Başarısı bileşen sayısıyla değil; ekipte belirsizliği, tekrar işi ve kullanıcı deneyimi farklarını ne kadar azalttığıyla ölçülür.
Önce problem ve kapsam
Sisteme “bütün atomları yapalım” diye başlamak aylar süren, kullanılmayan bir kütüphane oluşturabilir. Önce mevcut ürün envanteri çıkarılmalıdır: kaç farklı buton, input, modal, spacing değeri ve aynı işi yapan desen var? Hangi farklar gerçek ihtiyaç, hangileri tesadüfi? En çok kullanılan ve en fazla hata üreten parçalar ilk kapsama alınmalıdır.
Tek marka, çok marka, web, iOS ve Android hedefleri açıkça yazılmalıdır. Her platformu aynı görünüme zorlamak yerine ortak marka ve erişilebilirlik ilkeleriyle platforma özgü davranışlar ayrılabilir. Sistem sınırları net olmazsa ekip hem fazla soyutlar hem de gerçek ürün sorunlarını çözemez.
Temel katman: design tokens
Renk, tipografi, spacing, radius, gölge, süre ve easing gibi kararlar tokenlarla adlandırılır. Ham token “blue-600” gibi değeri, semantik token “action-primary-background” gibi amacı, component token ise belirli parçadaki kullanımı ifade edebilir. Bu katmanlama tema ve marka varyantlarını yönetmeyi kolaylaştırır.
Design Tokens Community Group’un 2025.10 format modülü, tokenların araçlar arasında değişimi için kararlı bir topluluk spesifikasyonu sunuyor. Değer, tür, grup, alias ve genişletme mekanizmaları tanımlanıyor. Ancak belge açıkça W3C Recommendation veya W3C Standards Track standardı olmadığını belirtir. Ekip bunu vendor bağımsızlığı için değerlendirebilir; kullandığı araç zincirinin desteğini ayrıca test etmelidir.
Token adı görsel görünümü değil amacı mümkün olduğunca anlatmalıdır. “gray-light-2” kısa vadede kolay, farklı temada anlamsız olabilir. Adlandırma sistemi örneklerle belgelenmeli; yeni token ekleme eşiği belirlenmelidir. Her istisna için yeni değer üretmek sistemin ölçeğini hızla bozar.
Bileşen bir stil değil sözleşmedir
Button bileşeni yalnızca dolgu, radius ve fonttan oluşmaz. Primary, secondary, destructive gibi roller; normal, hover, focus, pressed, loading ve disabled durumları; ikon ve metin kuralları; erişilebilir ad ve klavye davranışı sözleşmenin parçasıdır. Input için label, yardım metni, hata ilişkisi, autocomplete ve validation davranışı tanımlanmalıdır.
API isimleri tasarım ve kod tarafında mümkün olduğunca eşleşmelidir. Figma’da “Type=Main, Mood=Red”, kodda “variant=danger” kullanılırsa teslim sırasında sürekli çeviri gerekir. Aynı kavram sözlüğü komponent props, dokümantasyon ve analitik isimlerinde korunmalıdır.
Pattern ve template katmanı
Bileşenler tek başına bütün kullanıcı problemlerini çözmez. Form doğrulama, filtreleme, arama sonuçsuz durumu, onboarding veya ödeme onayı gibi tekrar eden akışlar pattern olarak belgelenmelidir. Template ise belirli sayfa düzenine başlangıç sağlayabilir; içerik ve iş kuralını dondurmamalıdır.
Pattern dokümanı “ne zaman kullanılır?”, “hangi alternatifler var?”, “hangi içerik gerekir?” ve “hangi erişilebilirlik riski bulunur?” sorularını yanıtlamalıdır. Görsel örnek kadar anti-pattern göstermek ekip kararını hızlandırır.
İçerik ve dil sistemi
İyi design system metni dışarıda bırakmaz. Buton etiketleri, başlık hiyerarşisi, hata mesajları, boş durumlar ve tarih/sayı biçimleri için ilkeler gerekir. Bileşenler uzun Türkçe ve İngilizce metinlerle, büyük yazı ayarıyla ve sağdan sola diller gerekiyorsa o yönde test edilmelidir.
Sabit genişlikte, yalnızca kısa İngilizce kelimeye göre hazırlanan bileşenler gerçek üründe taşar. Truncation kullanılacaksa tam metne erişim yolu ve hangi içerikte kesmenin kabul edildiği açıklanmalıdır. Çeviri anahtarları tasarım dosyasındaki örnek metinden bağımsız yönetilebilir; ancak gerçek uzunluklar prototipte sınanmalıdır.
Dokümantasyon ve keşfedilebilirlik
Kullanıcı bir bileşeni bulamıyor veya ne zaman kullanacağını anlayamıyorsa sistem teknik olarak var olsa da işlemez. Her bileşende amaç, anatomi, varyantlar, davranış, içerik, erişilebilirlik, kod örneği ve sürüm bilgisi bulunmalıdır. Arama terimleri ve eski adlar alias olarak eklenebilir.
Dokümantasyon ürünle birlikte güncellenmelidir. Figma kütüphanesi, kod paketi ve belge farklı sürümlere ayrılırsa ekip güvenini kaybeder. Yayın süreci bu üç çıktının birlikte doğrulanmasını sağlamalıdır.
Yönetişim: kim, nasıl değiştirir?
Merkezi ekip bütün talepleri aylarca bekleten kapı olmamalı; tamamen serbest katkı da tutarsızlık yaratabilir. Katkı modeli, inceleme sorumluları, RFC eşiği, erişilebilirlik kontrolü ve yayın takvimi tanımlanmalıdır. Küçük düzeltme ile kırıcı API değişikliği aynı süreçten geçmek zorunda değildir.
Semantik sürümleme, değişiklik günlüğü ve kullanım dışı bırakma planı geliştirici güvenini artırır. Deprecated bileşen hemen silinmemeli; yerine geçiş örneği ve süre verilmelidir. Kullanım telemetrisi veya kod araması hangi eski parçaların hâlâ aktif olduğunu gösterebilir.
Başarı nasıl ölçülür?
“Kütüphanede 80 bileşen var” sonuç değildir. Yeni ekran üretim süresi, tekrar edilen tasarım kararları, erişilebilirlik hataları, bileşen benimsenme oranı, katkı bekleme süresi ve kullanıcı deneyimi tutarlılığı daha yararlı göstergelerdir. Nicel veriye ekip görüşmeleri eklenmelidir; insanlar sistemi neden atlıyor sorusu kritik olabilir.
İlk sürüm için bütün ürünü kapsamak gerekmez. Temel tokenlar, button, input, typography ve bir iki yüksek değerli pattern ile pilot başlatılabilir. Tasarım ve kod aynı gerçek sayfada kullanılır; eksikler öğrenilir, sonra kapsam genişletilir. İyi design system tamamlanmış bir dosya değil, değişimi güvenli hale getiren ortak çalışma biçimidir.
Token mimarisi, bileşen sözleşmeleri ve yönetişim; bir tasarım sisteminin ürün ekibinde gerçekten yaşamasını sağlayan üç katman. Web tasarım ve yazılım hizmetimde bu katmanları tasarımdan koda kadar birlikte kuruyorum.
