Yani, Tasarıma, arayüze ya da component library tarafına biraz yakın durmuş herkesin başına gelmiştir: İlk başta “brand-800’ü direkt basalım gitsin” fikri baya mantıklı görünür. Hatta açık konuşayım, ben de yıllarca o kafadaydım. Renk var, değişken var, ne gerek var bu kadar katmana diye düşünüyorsun. Sonra ürün büyüyor… ve işte orada tablo fena halde değişiyor (ki bu çoğu kişinin gözünden kaçıyor)
Geçen yıl, 2025’in Mart ayında İstanbul’da bir SaaS paneli için tema sistemi kurgularken aynı duvara çarptım. Küçük ekipte her şey tatlı gidiyordu ama dark mode, high contrast ve farklı marka varyasyonları devreye girince basit görünen renk eşlemesi bir anda küçük bir kabusa döndü. İşin aslı şu ki sorun renk seçmek değil; o rengi nerede, hangi anlamla ve hangi bağlamda kullandığın — bu üç şey birbirinden büyük ölçüde farklı sorular ve çoğu zaman biri diğerinin cevabını tamamen alt üst ediyor.
Bunu yaşayan biri olarak söyleyeyim, Bir de şu var. Tasarım token dediğimiz şey aslında “renkleri ezberlemek” değil, onları düzenli bir dil haline getirmek. Tıpkı mutfakta her yemeğe ayrı ayrı tuz koymak yerine ölçü kabı kullanmak gibi… Başta ekstra iş gibi geliyor. Ama ölçek büyüyünce seni kurtaran şey tam da bu oluyor.
Bir dakika — bununla bitmedi.
Neden tek palette diretmek yetmiyor?
İlk bakışta çok yaygın bir düşünce var: “Elimde mavi tonları var, button’a 800 veririm, badge’e 100 veririm, biter.” Evet. Küçük demo’da bitiyor. Ama gerçek ürün başka bir dünya — butonun yüzeyiyle border rengi aynı mantıkla davranmıyor, disabled state ile hover state de kafasına göre takılmıyor zaten (ciddiyim)
Editör masasında bu konuyu yazarken aklıma 2024 sonbaharında Kadıköy’de görüştüğüm bir frontend ekibi geldi. Adamlar tek katmanla başlamıştı ve ilk üç ay gayet rahattılar. Dördüncü ayda iki tema daha gelince “niye bu kadar çok override yazıyoruz?” sorusu patladı — çünkü her bileşen farklı yönde dönüyordu, biri açık temada koyulaşıyor, diğeri tam tersine açılıyordu ve kimse neden böyle olduğunu net açıklayamıyordu.
Durun, bir saniye.
Aslında mesele çok basit. Aynı palet değeri her yerde aynı anlama gelmiyor. Button surface için doğru olan değer badge background için yanlış olabiliyor. Border renginde hafiflik isterken text tarafında kontrast istiyorsun (en azından benim deneyimim böyle). Yani tek palette kalınca tasarım sistemi sana yardım etmiyor; tam tersine seni elle düzeltme cehennemine atıyor.
Semantic token’ların olayı şu: Rengi değil anlamı taşırsın. Böylece “bu butonun yüzeyi” dersin; altında hangi raw renk olduğuna sonra karar verirsin.
Üç katman nasıl çalışıyor?
Araya gireyim: Lafı gevelemeden söyleyeyim. Bu yapı üç seviyeli düşünmeyi zorunlu kılıyor ama karşılığını da mis gibi veriyor. Birinci katmanda ham palet var; mesela --color-brand-800. Saf renk deposu gibi düşün bunu — başka bir şey değil.
İkinci katmanda semantic token geliyor: --color-surface-brand-primary. Burada artık “bu renk brand-800’dür” demiyorsun; “bu yüzeyde kullanılacak temel brand tonu budur” diyorsun. Yarın dark mode geldiğinde sadece bu katmandaki map’i değiştirip bütün sistemi oynatabiliyorsun — bu fark küçük görünüyor ama pratikte gece ile gündüz kadar büyük. Bash Öğrenmek İçin Tarayıcıda Bir Uygulama: Fikir Güzel mi? yazımızda bu konuya da değinmiştik.
Üçüncü katman ise component token seviyesi. Mesela --color-button-brand-default-surface. Burada dümdüz sistem kararını değil, bileşen kararını saklıyorsun. Bir komponent diğerlerinden farklı davranacaksa müdahaleyi en alt seviyede yapıyorsun; ana omurgayı bozmuyorsun (yanlış duymadınız)
| Katman | Ne tutar? | Nerede değişir? | Kullanım amacı |
|---|---|---|---|
| Layer 1 | Ham palet değerleri | Tema değişince | Mavi mi mor mu? Temel kaynak burasıdır. |
| Layer 2 | Anlamsal eşlemeler | Koyu/açık mod veya erişilebilirlikte | Bileşenlerin genel davranışını yönetir. |
| Layer 3 | Bileşen bazlı token’lar | Komponent istisnalarında | Tek bileşenin özel kararlarını saklar. |
İşte, bunu yaşayan biri olarak söyleyeyim, Tablonun ikinci satırı kritik. Çoğu ekip zaten ilk iki satırda hataya düşüyor — Layer 2’nin önemi tam da burada ortaya çıkıyor: görsel karar ile teknik uygulama arasında köprü kuruyor. Bu köprü olmayınca iki taraf birbirinden habersiz büyüyor. Bu konuyla ilgili Google Meet, Slack ve RAG ile Toplantı Hafızası Kurmak yazımıza da göz atmanızı tavsiye ederim.
Neden bu ayrım işe yarıyor?
Düşün ki elinizde otuz komponent var; button, input, checkbox, badge… Her biri dört state’e sahip: default, hover, focus ve disabled. Şimdi bunların surface, text ve icon değerlerini tek tek hard-code ettiğinizi hayal edin — evet, biraz can sıkıcı oldu bile.
Aynı şeyi üç katmanla yaptığında sadece kaynak paleti yönetiyorsun ve üstten aşağı akışı kuruyorsun. Mesela dark mode’da layer 2’deki semantic mapping’i değiştirdiğinde onlarca component otomatik toparlanıyor. Büyü gibi görünüyor ama büyü değil — sadece düzgün yapılandırılmış bir bağımlılık zinciri bu.
Bir startup’ta bu yaklaşım fazla mühendislik gibi görünebilir. Ama ekip büyüdüğünde hayat kurtarıyor — Bir enterprise projede ise zaten mecbursun…
Maliyet hesabı neden göz korkutuyor?
Burası güzel tarafın matematiği aslında. Kuru kuru teori yok yani. Şöyle düşün: 30 komponent, her biri için dört state, her state’te üç özellik — surface, text, icon. Buna iki mod ekle: light ve dark. Bir de beş tema ekle: blue, violet, pink, cyan, orange. İşte o zaman iş çığrından çıkmaya başlıyor ve sayılar fena şekilde büyüyor.
# Basit örnek
--color-brand-800
--color-surface-brand-primary
--color-button-brand-default-surface
/* Dark mode'da yalnızca semantic mapping değişebilir */
[data-theme="dark"] {
--color-surface-brand-primary: var(--color-brand-200);
}Layersız yaklaşımın derdi ne?
Layersız modelde hesap neredeyse hep çarpanlarla büyüyor: komponent × state × property × mode × tema. Bu kulağa akademik gelebilir ama günlük hayatta şuna dönüşüyor: “Kim bu override dosyasına yine dokundu?” Ve cevap genelde kimse bilmiyor oluyor…
Kendi deneyimimde en sinir bozucu nokta buydu. 2025 Ocak ayında Ankara’daki bir ürün ekibinde deneme yaparken yalnızca yeni tema eklemek için ondan fazla dosya açtığımız oldu. Birkaç gün sonra ufak bir border rengi değişti diye başka yerler bozuldu. Hayal kırıklığı tam buydu işte — kağıt üstünde kolay görünen şey pratikte dağılıyor. Claude Word’e Geldi: Yan Panelde Akıllı Düzenleme Dönemi yazımızda bu konuya da değinmiştik.
Peki pratikte nasıl kurulur?
- Sadece raw color ile component boyamaya çalışma;
- Anlamsal token isimlerini insan diliyle kur;
- Bileşen istisnalarını üçüncü kata sakla;
- Tema geçişini mümkün olduğunca ikinci katta çöz;
- Aynı rengi farklı amaçlarla tekrar etme;
- Ekip içinde isimlendirme sözlüğü oluştur;
- Erişilebilirlik kontrastını en baştan test et! — ciddi fark yaratıyor
Aşağıdaki yapı benim gördüğüm en temiz başlangıçlardan biri: PostgreSQL’de Bağlantı Patlaması: PgBouncer ve Supavisor yazımızda da bu konuya değinmiştik. Confdroid Selinux: Puppet ile Güvenliği Otomatikleştirmek yazımızda da bu konuya değinmiştik.
Peki neden?
:root {
--color-brand-200:#c7d7fe;
--color-brand-800:#1e40af;
}
[data-theme="light"] {
--color-surface-brand-primary:var(--color-brand-800);
--color-button-default-surface:var(--color-surface-brand-primary);
}
[data-theme="dark"] {
--color-surface-brand-primary:var(--color-brand-200);
}Şöyle ki, Dikkat ettiniz mi? Burada hata yapmak kolaydır — ama düzeltmek de kolaydır (kendi tecrübem). İşte fark tam orada yatıyor.
Küçük startup mı büyük kurum mu?
Küçük startup’ta bazen hızlı hareket etmek gerekir; bunu inkâr edemem (kendi tecrübem). Ürün-pazar uyumu peşindeyseniz aşırı soyutlama erken gelebilir. Ama en azından Layer 1 ve Layer 2’ye yatırım yapmak çoğu zaman yeterli — çünkü sonradan retrofit etmek gerçekten yorucu oluyor, hem teknik hem psikolojik olarak.
Bir şey dikkatimi çekti: Büyük kurum tarafında ise durum daha serttir. Tasarımı onlarca takım kullanıyorsa naming standardı olmazsa kaos çıkar. Benzer şeyi Temmuz 2024’te İzmir’de danışmanlık yaptığım bir fintech projesinde gördüm; aynı buton bileşeni üç takım tarafından üç farklı renkle çağrılıyordu. Yani ortak sistem vardı sanılıyordu ama aslında yoktu (şaşırtıcı ama gerçek)
Nerede eksik kalır?
Açık konuşayım: üç katmanlık model sihir değil. Yanlış kurgulanırsa sadece klasör sayısı artar. Ayrıca gereksiz soyutlama da ekibi yorar — bunu küçümseme. Bazı projelerde iki katman yeterlidir; özellikle küçük admin panellerinde ya da kısa ömürlü kampanya sitelerinde buradaki kritik soru şu: “Bu sistem altı ay sonra hâlâ yaşayacak mı?” Cevap “hayır”sa, o zaman üçüncü katmanı zorlama.
Aman ha, unutmayın: ince noktalar
- Name spacing olmadan token adı verme; karışır.
- Tema ile semantik rolü birbirine sokma.
- Aynı value’yu hem source hem semantic olarak kullanıp kafa karıştırma.
- Erişilebilirliği sonradan değil baştan düşün.
- Dökümantasyonu ciddiye al — yoksa sistem unutulur!
Şunu fark ettim: Biz seneler önce buna benzer bir yapıda kod review sırasında aynı hatayı defalarca yakaladık. En büyük problem teknik değildi aslında; insanlar neden o token’ın orada olduğunu unutuyordu (en azından benim deneyimim böyle). Neden önemli bu? Dökümantasyon olmayınca sistem yaşayan organizma olmuyor, sadece eskiyen dosya yığınına dönüşüyor.
Bakın şimdi — bir tasarım sistemi kuruyorsanız küçük görünse bile not alın: hangi token hangi seviyede tanımlandı, hangi durumda override edilir, hangi takım bunu değiştirebilir (şaşırtıcı ama gerçek). Bu notlar ilk hafta gereksiz görünür… Üçüncü ayda altın değerine gelir.
Sıkça Sorulan Sorular
Tasarım tokenu ile CSS variable aynı şey mi？
Pek aynı sayılmaz.CSS variable teknik taşıyıcıdır;design token ise kavramsal sözleşmedir.Yani variable altyapıdır,token ise onun üzerinde çalışan anlam katmanı gibidir.
Neden doğrudan brand rengini kullanmayayım？》
Brand rengini doğrudan kullanırsanız tema değiştirmek,dark mode eklemek veya özel bileşen istisnası yapmak zorlaşır.Kısacası kısa vadede rahat,orta vadede yorucu olur.
Üç katmanın hepsi şart mı？_#
Hayır.Küçük projelerde ikinci seviye bile yeterli olabilir.Ama ürün büyüyorsa ya da çok tema destekliyorsa üçüncü katman ciddi rahatlık sağlar.
Erişilebilirlik için ne kazanırım？#
Kontrast kontrolünü merkezi hale getirirsiniz.Bu da text okunurluğu,focus ring görünürlüğü ve yüksek kontrast modlarını daha temiz yönetmenizi sağlar.
Kaynaklar ve İleri Okuma}
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
