Design token, bir tasarım kararını isimli ve tekrar kullanılabilir veriye dönüştürür. Ana renk, metin rengi, spacing adımı, radius veya tipografi değeri token olabilir. Asıl değer tek bir sayıyı saklamak değil, kararın ne amaçla kullanıldığını araçlar arasında taşıyabilmektir. Figma'daki bir variable ile kod deposundaki değerin aynı isimde görünmesi yeterli değildir; tür, referans ve sürüm davranışı da ortak anlaşılmalıdır.
Neden ortak format önemli?
Araçlar uzun süre kendi JSON biçimlerini kullandı. Aynı token bir exporter içinde type, başka bir araçta valueType, üçüncü bir pipeline içinde category olarak tanımlanabiliyordu. Design Tokens Community Group tarafından yayımlanan 2025.10 Format Module, araçtan bağımsız bir değişim biçimi tanımlar. Spesifikasyon token değerini value, türünü type alanıyla ifade eder ve referansların nasıl çözüleceğini açıklar.
Bu standart her ekibin aynı isimleri kullanmasını zorunlu kılmaz. Ama veri farklı araçlara taşındığında rengin sayı, duration veya gradient sanılmamasını sağlar. Spesifikasyonda tür açıkça belirtilmemişse aracın bunu tahmin ederek geçerli saymaması gerektiği belirtilir. Bu yaklaşım sessiz hatalar yerine erken doğrulamayı teşvik eder.
Üç katmanlı isimlendirme kurmak
Pratik bir sistem primitive, semantic ve component katmanlarını ayırabilir. Primitive token ham paleti taşır: blue-600 veya space-300 gibi. Semantic token kararın rolünü anlatır: color-text-primary, color-surface-action veya spacing-section. Component token ise yalnız gerçekten gereken yerde düğme yüksekliği veya input kenarlığı gibi yerel kararı ifade eder.
Uygulama kodu her yerde doğrudan blue-600 kullanırsa tema veya marka değişimi zorlaşır. Semantic token primitive değere alias verir; koyu temada aynı rol başka primitive'e bağlanabilir. Ancak her değeri üç katmanda kopyalamak da gereksizdir. Bileşen tokenı, ortak semantic rolün yetmediği gerçek bir fark olduğunda eklenmelidir.
Alias zincirlerini kısa ve anlaşılır tutmak
Referanslar merkezi değişikliği kolaylaştırır; çok uzun zincirler ise değerin nereden geldiğini belirsizleştirir. Bir component token semantic role, semantic rol primitive değere bağlanabilir. Bunun ötesindeki katmanlar ekip için açık bir fayda üretmiyorsa sadeleştirilmelidir.
Pipeline çözülemeyen referans, döngüsel referans veya tür uyuşmazlığında build'i durdurmalıdır. DTCG formatı bu hata durumlarını açık biçimde tanımlar. Bir renk tokenının duration değerine bağlanması gibi yanlışlık sessizce string'e dönüşmemeli, geliştiriciye ve tasarımcıya hangi yolun kırıldığı söylenmelidir.
Figma variable yapısını kod sözlüğü sanmamak
Figma içindeki collection ve mode yapısı tasarım üretimini kolaylaştırır; ürünün bütün kaynak gerçeği olmak zorunda değildir. Önce sahiplik belirlenir: token değişikliğini kim önerir, kim onaylar, hangi repo yayınlar ve sürüm nasıl duyurulur? Tasarım dosyası ile kod arasında çift yönlü ve kontrolsüz senkronizasyon çakışma yaratabilir.
Tek yönlü yayın akışı daha öngörülebilir olabilir: onaylanan token paketi sürümlenir, Figma ve kod tüketicileri aynı paketten güncellenir. Başka ekipte Figma kaynak olabilir; o durumda exporter çıktısı doğrulanır ve değişiklik pull request üzerinden incelenir. Araç seçimi ne olursa olsun manuel kopyalama kalıcı yöntem olmamalıdır.
Renk dışında gerçek türleri modellemek
Token sistemi yalnız renk paletinden ibaret değildir. Dimension, number, font family, font weight, duration, cubic bezier, border ve shadow gibi değerler farklı davranır. 16 sayısının spacing mi opacity mi olduğu tür ve bağlam olmadan anlaşılamaz. Birleşik değerlerde alt özelliklerin açık yapısı platform dönüşümünü kolaylaştırır.
Mobil ve web birimleri de doğrudan aynı string olarak taşınmamalıdır. Temel karar ortak olabilir; platform dönüştürücü dp, pt, rem veya CSS değişkeni üretir. Dönüşüm kuralı belgelenmezse eşit sayıların eşit deneyim oluşturduğu varsayılır. Test uygulaması gerçek cihaz ve tarayıcıda sonucu doğrulamalıdır.
Sürümleme ve geriye uyumluluk
Token adı değiştirmek tasarım temizliği gibi görünse de tüketici kod için API değişikliğidir. Eski adı hemen silmek yerine yeni token eklenebilir, eski olan deprecated işaretlenebilir ve geçiş süresi verilebilir. Değer değişikliği görsel regression testlerinde karşılaştırılır. Major, minor ve patch yaklaşımının ekip için ne anlama geldiği kısa bir sözleşmeyle yazılmalıdır.
Her yayın notunda eklenen, değişen ve kaldırılan tokenlar listelenmelidir. Ekran görüntüsü farkı tek başına yeterli değildir; değişikliğin amacı, etkilenen tema ve beklenen kullanıcı etkisi açıklanmalıdır. Tasarım sisteminin kullanıcıları ne zaman güncelleme yapmaları gerektiğini bu bilgiyle değerlendirir.
Küçük bir pilotla başlamak
Bütün siteyi aynı anda tokenlaştırmak yerine renk, spacing ve radius ile bir temel paket kurulabilir. Bir buton, input, kart ve navigasyon üzerinde açık-koyu tema denenir. Figma, web ve mobil çıktı karşılaştırılır; isimlerin ekip tarafından anlaşılmadığı noktalar düzeltilir. Sonra tipografi ve motion gibi alanlar eklenir.
Başarı token sayısıyla ölçülmemelidir. Tasarım-kod farklarının azalması, tema değişikliğinin daha kontrollü yapılması, aynı kararın tekrar tanımlanmaması ve kırılan referansın yayından önce bulunması daha anlamlı göstergelerdir. Standart format bu operasyonun temelini kurar; iyi yönetişim ise sistemi yaşayan ürüne dönüştürür.
Token kataloğunda her kaydın adı ve değeri kadar kısa açıklaması, sahibi ve kullanım örneği de bulunmalıdır. Yalnız otomatik üretilen tablo, iki benzer semantic rengin neden ayrı olduğunu anlatmaz. Kullanılmayan tokenlar periyodik olarak işaretlenebilir; doğrudan silmek yerine tüketici taraması ve deprecation süreci uygulanır. Bu bakım, kütüphanenin zamanla yeni bir belirsizlik katmanına dönüşmesini engeller.
Figma'dan koda sağlam bir veri akışı kurmak, tasarım ile geliştirme arasındaki en yaygın sürtünmeyi ortadan kaldırıyor. Web tasarım ve yazılım hizmetimde bu aktarımı baştan planlıyorum.
