Design Tokens: Gerçek Tasarım Sistemleri Tutarlılığı Nasıl Korur
Design token nedir, gerçek sistemlerin kullandığı üç katmanlı model (Shopify Polaris, IBM Carbon, GitHub Primer), nasıl adlandırılır, dark mode için tema oluşturma ve token'ların ne zaman gereksiz olduğu.
Design Tokens: Gerçek Tasarım Sistemleri Tutarlılığı Nasıl Korur
Bir hex kodu bir değerdir. Token ise adı olan bir karardır. Tasarım sistemleri kararlardan oluşur, değerlerden değil.
Bu ayrım konunun tamamı. #0EA5E9'u on dört Figma bileşenine hardcode edin, dark mode talebi gelsin ve bir haftalık bul-değiştir maratonu sizi bekliyor olsun. Bunu color-interactive-primary olarak adlandırın, tek bir değeri değiştirin ve her yüzey güncellensin. Bu sihir değil, sadece adlandırılmış kararlar.
Design token aslında nedir
Design token, bir tasarım kararını saklayan adlandırılmış bir değişkendir. Renk, boşluk değeri, font boyutu, border radius, gölge veya süre tutabilir. İsim sözleşmedir. Adın arkasındaki değer, onu kullanan hiçbir şeyi bozmadan değişebilir.
Klasik token-olmayan yaklaşım şöyle başlar: bir tasarımcı birincil butonlar için #1D4ED8 seçer, bunu buton bileşenine hardcode eder, ardından aynı hex'i karta, rozete ve linke kopyalar. Altı ay sonra marka güncellenir. Artık gönderdiğiniz her bileşenle büyüyen bir bakım sorunuyla karşı karşıyasınız.
Token'lar bunu tersine çevirir. Kararı adlandırırsınız (color-action-default), değeri bir kez atarsınız ve token'a başvuran her şey senkronize kalır. Değer uygulama detayıdır. İsim ise sistemdir.
Token'ları işlevsel kılan üç katman
Ham token'lar sadece değişkendir. Token sistemini gerçekten kullanışlı kılan şey hiyerarşidir. İncelemeye değer her üretim sistemi üç katman kullanır.
| Katman | Diğer Adları | Ne Saklar | Örnek |
|---|---|---|---|
| Primitive | Global, Base | Ham değerler, anlam yok | color.blue.500 = #3B82F6 |
| Semantic | Alias, Role | Primitive'lere eşlenmiş adlandırılmış roller | color.interactive.default = color.blue.500 |
| Component | Specific | Bileşen kapsamlı kararlar | button.background.default = color.interactive.default |
Primitive'ler paletinizdir. Her mavi, her boşluk adımı ve her radius, kullanıldığı yer hakkında herhangi bir görüş belirtmeksizin adlandırılmış bir değer olarak burada yaşar. Primitive'leri bileşenlerde doğrudan tüketmezsiniz.
Semantic token'lar rolleri primitive'lere eşler. color-surface-default token'ı açık modda neredeyse beyaza, koyu modda neredeyse siyaha işaret edebilir; bileşen hangi ham değeri aldığını hiçbir zaman bilmez. Yalnızca rolü bilir.
Component token'lar en özgüldür. Bir bileşenin semantic varsayılandan kasıtlı olarak farklı bir karara ihtiyaç duyduğunda var olurlar. Tehlike butonu arka planını varsayılan etkileşimli yerine kritik geri bildirim rolüne yönlendirir. Çoğu bileşenin kendi token'larına ihtiyacı yoktur; semantic token'ları doğrudan tüketirler.
Token'lar neden hardcoded değerleri geçer
Değişim hızı bariz argümandır ama gerçek olan değil. Gerçek argüman kesinliktir.
Bir tasarımcı ham hex kodlarıyla dolu bir dosya teslim ettiğinde, geliştirici hangilerinin kasıtlı hangilerinin tesadüfi olduğunu bilemez. #1A1A2E arka plan mı, yoksa biri yanlış katmanı mı eyedrop etti? Token'lar belirsizliği ortadan kaldırır. Semantic bir token adı, değerle birlikte seyahat eden belgedir.
Token'lar aynı zamanda 2026'da tasarım araçları ile kod arasındaki handoff sözleşmesidir. Figma değişkenleri CSS custom property'lerine doğrudan eşlenir. Bir Figma dosyasında tanımlanan token, tek bir manuel adım olmadan export edilebilir, commit'lenebilir ve kodda tüketilebilir. Her iki taraf da aynı token adlarını konuştuğunda tasarım ile uygulama arasındaki uçurum kapanır.
Erişilebilirlik çalışması yapan ekipler için token'lar bir güvenlik katmanı daha ekler. Semantic paleti tek bir yerde denetlersiniz ve color-text-default'un hangi tema aktif olursa olsun her zaman color-surface-default'a karşı 4.5:1 kontrast geçtiğini garanti edersiniz.
Gerçek tasarım sistemleri token'larını nasıl yapılandırır
Bilinmesi gereken üç sistem var: Shopify Polaris, IBM Carbon ve GitHub Primer. Üç katmanlı modeli farklı şekillerde ele alıyorlar ve farklılıklar öğretici.
Shopify Polaris primitive'leri bir renk skalasında (color-sky-100 ile color-sky-900 arası) tutar ve bunları --p-color-bg-fill-active gibi semantic rollere alias'lar. Component token'lar seyrektir, bu yüzden çoğu bileşen semantic token'ları tüketir. Kural rol-sonra-durum biçimindedir; kodda doğal okunur çünkü bg-fill-disabled'ın ne için olduğunu ek bağlam olmadan anlarsınız.
polaris.shopify.com'da canlı görün
IBM Carbon semantic katmanlara derinlemesine gider. Renk seti support-error ve support-success gibi açık geri bildirim token'larını, etkileşimli durum token'larını ve iç içe yüzeyler için katman token'larını içerir (bir sayfadaki paneldeki bileşenin her birinin farklı bir yüzey değerine ihtiyacı vardır). Daha karmaşıktır ama IBM, her iç içe durumun önemli olduğu kurumsal yazılım gönderir.
carbondesignsystem.com'da canlı görün
GitHub Primer primitive katmanını "primitives" ve semantic katmanı "functional tokens" olarak ortaya koyar ve bunları primer.style'da kamuya açık belgeler. Primer'ın teması, GitHub'ın tek bir bileşen setinden açık, koyu, açık yüksek kontrast ve koyu loş modları göndermesini sağlar. Her tema, aynı token adlarına farklı bir değer atamasıdır.
Üçünde de ortak örüntü tutarlıdır: ölçek olarak primitive'ler, rol adları olarak semantic token'lar ve semantic katmanda değer takası olarak tema. Bileşenler hiç değişmez.
Brainy, tasarımcıların tek seferlik ekranlar değil ölçeklenen sistemler kurmasına yardımcı olur. İçerik üreticileri için neler yaptığımıza bakın: /creators.
Aklınızı kaybetmeden token adlandırma
Token adlandırması ekipleri parçalar. Çok genel olursa adlar hiçbir bilgi taşımaz. Çok özgül olursa her bileşen için yeni bir token yazarsınız.
İşe yarayan bir adlandırma kuralı dört parçayı adlandırır: kategori, rol, varyant ve durum. Her seferinde dördünü de kullanmayacaksınız ama yapı gelişigüzel kaosun önüne geçer.
| Parça | Yakaladığı Şey | Örnekler |
|---|---|---|
| Kategori | Tasarım özelliği | color, spacing, radius, shadow, font |
| Rol | Semantic amaç | surface, text, border, interactive, feedback |
| Varyant | Alt rol veya değiştirici | primary, secondary, danger, subtle |
| Durum | Etkileşim koşulu | default, hover, active, disabled, focus |
Bir geliştiricinin gerçekte tükettiği CSS custom property olarak yazılmış çalışan örnekler:
color-surface-defaultvarsayılan sayfa arka planını ayarlarcolor-text-subtledaha düşük kontrastta ikincil metindircolor-interactive-primary-hoverbirincil bir eylemin hover durumudurspacing-component-mdbileşenler için orta büyüklükte iç dolguyu ifade ederradius-interactivetıklanabilir öğelerin köşe yarıçapıdır
İki kural en fazla tartışmayı önler. Ham değeri adda hiçbir zaman kodlamayın çünkü color-blue-500 rol hakkında hiçbir şey söylemez. Semantic katmanda bileşene göre asla adlandırmayın çünkü semantic katmandaki button-primary-color, semantic katmanı tamamen atladığınız anlamına gelir.
Ölçeklenen tip sistemleri için aynı kural geçerlidir ve font-size-body-lg, text-18px'i her zaman geçer.
Tek token seti, açık ve koyu mod
Dark mode, token sistemlerinin en görünür biçimde karşılığını verdiği yerdir. Token'larınızı role göre adlandırdıysanız dark mode bir yeniden tasarım değil, değer takasıdır.
Mekanizma basittir. Semantic token'ınız color-surface-default, açık modda neredeyse beyaz olan ve koyu modda neredeyse siyah olan bir primitive'e işaret eder. Onu tüketen bileşen hiç değişmez. Temaları semantic katmandaki değer eşlemesini değiştirerek geçersiniz.
CSS custom property'ler bunu mekanik hale getirir:
:root {
--color-surface-default: #ffffff;
--color-text-primary: #111827;
}
[data-theme="dark"] {
--color-surface-default: #0f172a;
--color-text-primary: #f8fafc;
}
var(--color-surface-default)'a başvuran her bileşen artık sıfır ek kod ile tema özniteliğine yanıt verir. Shopify Polaris, GitHub Primer ve IBM Carbon bu örüntüyü üretim ölçeğinde kullanır.
Başarısızlık modu, bileşenlerde semantic ve primitive token'ları karıştırmaktır. Bir bileşen color-interactive-primary yerine doğrudan color-blue-600'e başvurduğunda, o bileşen temaya yanıt vermeyi durdurur. Tek bir dikkatsiz primitive başvurusu tüm modeli bozar. Bileşen kodunda doğrudan primitive tüketimini işaretleyen lint kuralları kurulum süresine değer.
Renk seçimlerinin nasıl sonuçlandığını anlamak kavramsal zemini sağlar; token'lar ise bunu her temada uygulamak için yapıyı verir.
Design token'lar ne zaman gereksizdir
Token'lar dolaylılık ekler. Dolaylılığın maliyeti vardır. Bu maliyetlerin ne zaman ödemeye değer olduğu konusunda dürüst olun.
| Durum | Token'lar? | Neden |
|---|---|---|
| 3+ ürüne hizmet eden tasarım sistemi | Evet | Paylaşılan token'lar kendini anında amorti eder |
| Tek ürün, 5+ tasarımcı | Evet | Ekip genelinde palet kaymasını önler |
| Tek ürün, 1-2 tasarımcı, aktif iterasyon | Belki | Yalnızca semantic katman, component token'larını atlayın |
| Bileşen kütüphanesi olmayan pazarlama sitesi | Hayır | Tek bir stylesheet değiştirmek daha hızlı |
| 3 aydan kısa prototip veya MVP | Hayır | Tasarım oturulduktan sonra soyutlayın |
| Mevcut sisteme dark mode ekleme | Evet | Token'lar tam olarak bunun için var |
Küçük ekipler token'lar olmadan daha hızlı hareket eder. Ürün-pazar uyumu peşindeki üç kişilik bir startup, üç katmanlı hiyerarşiye ihtiyaç duymaz. İki haftada bir görsel yönü değiştiriyorsanız, tek bir Figma stil kütüphanesi yeterlidir.
Kaçınılması gereken anti-örüntü erken semantic adlandırmadır. color-blue ve color-gray adlı token'lar anlam olmadan dolaylılık ekler. Ya color-surface ve color-text ile role göre adlandırın ya da rollerin gerçekte ne olduğunu bilecek kadar bileşeniniz olana kadar primitive'lere bağlı kalın.
Kötü token adlandırması, token olmamaktan daha kötüdür. Semantic katmanda button-color-for-the-checkout-page adlı bir token bir bakım tuzağıdır. Adlandırma disiplini isteğe bağlı değildir; token'ların işe yaramasının nedeni budur.
SSS
Design token'lar Figma stillerinin yerini alır mı?
Hayır, ama onları genişletir. 2023'te yayımlanan Figma değişkenleri, Figma içindeki en yakın yerel eşdeğerdir ve her iki tarafta da adlandırma kurallarını paylaştığınızda kod token'larına eşlenir. Figma stilleri tipografi ve renk dolgularını işlerken değişkenler durum ve bileşen düzeyindeki kararlar dahil tam token hiyerarşisini işler.
Token'lar tasarım sistemi olmadan çalışır mı?
Token'lar bir tasarım sistemi içinde en değerlidir, ancak tek bir ürün bile CSS custom property düzeyinde semantic adlandırmadan yararlanır. Hex değerlerini hardcode etmeyi bırakmak için resmi bir sisteme ihtiyacınız yok.
Token'ları yönetmek için hangi aracı kullanmalıyım?
Küçük ekipler için Figma değişkenleri artı bir JSON export yeterlidir. Daha büyük ekipler için Style Dictionary (açık kaynak, Amazon tarafından) standart build aracıdır. Token JSON yapısını alır ve CSS custom property'leri, iOS Swift sabitleri ve Android XML çıktısı üretir. Figma için Tokens Studio, Figma ile Style Dictionary arasındaki popüler eklenti köprüsüdür.
Bileşen token'ları ne kadar ayrıntılı olmalıdır?
Yalnızca ihtiyacınız kadar ayrıntılı. Çoğu bileşen semantic token'ları doğrudan tüketebilir. Bileşene özgü token'lar, yıkıcı bir işlem butonu veya olağandışı bir yüzeye sahip bir banner gibi bir bileşenin kasıtlı olarak semantic katmandan saptığı durumlarda mantıklıdır. Şüphe duyduğunuzda semantic tüketin ve component token'larını yalnızca istisnalar yazdığınızı fark ettiğinizde oluşturun.
Token'lar yalnızca rengi mi işler, boşluk ve tipografiyi de mi?
Token'lar ayrı bir değeri olan her şey için çalışır: renk, boşluk, tipografi, border radius, box shadow, hareket süresi, hareket easing'i ve z-index. IBM Carbon ve Atlassian Design System gibi en olgun sistemler bunların tümü için token'lara sahiptir. Renk ve boşlukla başlayın, ardından sistem olgunlaştıkça diğerlerini ekleyin.
Değerleri hardcode etmeyi bırakın
Pratik yol karmaşık değil:
- Primitive'lerinizi bir ölçek olarak adlandırın
- Bu primitive'leri semantic rollere eşleyin
- Her bileşenin semantic token'ları tüketmesini, primitive'leri asla tüketmemesini sağlayın
- Token değerlerini tek bir kaynaktan export edin (Figma değişkenleri, bir JSON dosyası veya bir tasarım sistemi paketi) ve build araçlarının bunları CSS, iOS ve Android'e dağıtmasına izin verin
Başlamak için üç aylık bir migrasyona ihtiyacınız yok. Bir bileşen seçin, kararlarını adlandırın ve bir değeri değiştirip her şeyin güncellendiğini izlediğinizdeki farkı hissedin. O deneyim, argümanın kendisidir.
Daha fazla tasarım sistemleri yazısı için Brainy'nin başka neler kapsadığına bakın: /paper.
Brainy helps designers build systems that scale, not one-off screens. See what we are building for creators.
Get Started
