Renkleri kodla yönetmek: tasarım sistemleri ve renk token'ları

Kısa cevap

Bir butona doğrudan hex kodu yazmak, o rengin neden orada olduğunu kodun içinde kaybeder: kod yalnız «bu mavi» der, «bu birincil eylem» demez. Renk değişmek istendiğinde aynı kodun yüzlerce kopyasını tek tek bulmak gerekir, küçük farklarla yazılmış kopyalar gözden kaçar ve karanlık tema ya da yüksek kontrast gibi ikinci bir görünüm eklemek her kopyanın ayrıca elden geçirilmesini gerektirir. Renk token'ları bu sorunu katmanlara ayırarak çözer: ham değerler bir yerde, rolleri anlatan adlar başka bir yerde durur ve bileşen yalnız rolü çağırır.

Sabit kodun bedeli

Bir ürünün ilk sürümünde her şey hızlı ilerler. Tasarımcı bir mavi seçer, geliştirici onu butonun arka planına yazar, bir sonraki ekranda bağlantı rengi olarak yine yazar, bir bildirim kutusunun kenarında bir kez daha yazar. Değer her yerde aynı onaltılık dizidir ve kimse bunun bir sorun olduğunu düşünmez.

Sorun, ürün büyüdüğünde görünür hâle gelir. Marka mavisi biraz koyulaştırılmak istendiğinde ekip, kod tabanında o altı karakteri arar ve iki şeyle karşılaşır. İlki, aynı mavinin bir iki basamağı farklı yazılmış kopyalarıdır: biri ekrandan göz kararı alınmış, biri bir tasarım dosyasından eski bir sürümle kopyalanmış. Arama bunları bulmaz ve değişiklikten sonra ürünün içinde iki mavi yaşamaya başlar. İkincisi daha sinsidir: bulunan kopyaların hepsi aynı işi görmez. Aynı mavi bir yerde birincil butonun zemini, bir yerde bir bağlantının rengi, bir yerde yalnız dekoratif bir çizgidir. Marka mavisi değişince bağlantıların da değişmesi gerekir mi? Kod bu soruya cevap veremez, çünkü kodda yalnız değer vardır, niyet yoktur.

Aynı sorun yeni bir görünüm eklenince büyür. Karanlık tema, yüksek kontrast modu ya da bir alt marka için farklı bir renk teması, her sabit kodun ayrı ayrı ele alınmasını gerektirir. Kartın sorusunun cevabı buradadır: bir butona doğrudan hex kodu yazmak, bugün hiçbir şeyi bozmaz, ama her gelecekteki değişikliği bir arama ve tahmin işine çevirir.

Token nedir

Tasarım token'larının dosya biçimini standartlaştırmaya çalışan topluluk, W3C çatısı altındaki Design Tokens Community Group, 2025.10 adıyla ilk kararlı biçim belirtimini yayımladı. Belge, token'ları tasarım kararlarını platformdan bağımsız biçimde ifade etmenin bir yöntemi olarak tanımlar; amaç, farklı disiplinler, araçlar ve teknolojiler arasında ortak bir sözlük kurmaktır. Bir token'ın zorunlu tek alanı değeridir; türü, açıklaması ve başka alanlar isteğe bağlıdır. Renk türündeki bir token'ın değeri, yalnız bir onaltılık diziyle değil, hangi renk uzayında yazıldığı da belirtilen bir nesneyle verilir. GT-10'da bir hex kodunun uzay adı olmadan eksik olduğunu gördük; belirtim bu eksikliği biçimin içine yerleştirir.

Son cümle önemlidir: bu belge bir W3C standardı değildir ve kendi başına hiçbir aracı bağlamaz. Ama pek çok ekibin zaten yaptığı şeyi ortak bir dosya biçimine yazar ve bir tasarım aracının ürettiği token dosyasının, bir çeviri aracı tarafından web, iOS ve Android koduna dönüştürülmesinin yolunu açar.

Üç katman

Token'ların gücü tek başına bir adda değil, adların birbirine başvurabilmesindedir. Çoğu tasarım sistemi renkleri üç katmanda düzenler.

Ham palet, markanın ve arayüzün kullanabileceği bütün renkleri toplar. Adlar bu katmanda anlam taşımaz: «mavi 600» bir mavidir, birincil eylem olup olmadığını bilmez. Bu katmandaki renkler çoğunlukla ton skalaları olarak düzenlenir.

Yaygın bir çerçeve, bir tonun açık ucuna 50, koyu ucuna 900 ya da 950 numarası verip araya yüzlük adımlar koymaktır. Tailwind CSS'in varsayılan paletinde her renk on bir basamak taşır: 50 en açık, 950 en koyu ve aradaki basamaklar 100'den 900'e yüzer yüzer ilerler. Aynı paletin renk değerleri OKLCH ile yazılmıştır. Bu bir tesadüf değildir: skala basamaklarının göze eşit aralıklı görünmesi için açıklık, gözün eşit adım sandığı farkları eşit sayılarla yazan bir uzayda ölçülmelidir; HSL'deki açıklık bu işi yapamaz. OKLCH ve OKLab'ın kendisi BI-24'ün, DT-07'deki açık ve koyu tonların oluşumu da o dersin konusudur. Numaralar arasındaki boşluklar bir gün iki basamak arasına yeni bir ton eklemek gerekirse ona yer bırakır.

Orta katman, tasarım sisteminin asıl kararlarını taşır. «Birincil» adlı bir token, değerini «mavi 600»e başvurarak alır. «Birincil üstündeki metin» adlı bir token, birincil zeminin üzerine yazılacak metnin rengini belirler ve değerini belki «beyaz»a başvurarak alır. Bu iki token her zaman birlikte düşünülür, çünkü aralarındaki kontrast UX-06'daki orana uymak zorundadır. Hangi rengin başarıyı, hangisinin hatayı anlattığı ve bu anlamların nerede kırıldığı UX-02'nin konusudur; bu katmanın burada önemli olan yanı, adın bir rolü, değerin ise o rolün bugünkü rengini taşımasıdır.

En üst katman bileşenlere aittir. «Dolu buton zemini» adlı bir token, «birincil»e başvurur. Bir gün yalnız butonların biraz daha koyu olması istenirse, bu tek token başka bir semantik ya da ham değere bağlanır ve ürünün geri kalanı etkilenmez.

Üç katmanı birbirine bağlayan şey bu başvurulardır. Material Design'ın web bileşenleri bu yapıyı açıkça yazar: her bileşen token'ı bir sistem token'ına, her sistem token'ı somut bir başvuru değerine bağlanır; web'de bu token'lar CSS özel özellikleri olarak yaşar. Aynı belgelerdeki bir örnekte, hata türündeki bir butonun zemin rengi doğrudan bir renkle değil, sistemin «hata» rengine başvuruyla verilir; butonun metni de «hata üstündeki» renge bağlanır.

Temalar tek bir bağlantı değişikliğidir

Katmanların asıl kazancı, ikinci bir görünüm eklendiğinde ortaya çıkar. Karanlık temada «yüzey» token'ı açık bir griye değil, koyu bir griye bağlanır; «yüzey üstündeki metin» koyudan açığa döner; «birincil» belki bir basamak açılır, çünkü koyu zemin üzerinde metinle arasındaki kontrastın yeniden sağlanması gerekir. Bu değişikliklerin hiçbiri bir bileşene dokunmaz: butonlar, kartlar ve formlar aynı semantik adları çağırmaya devam eder, adların bağlandığı ham değerler değişir. Karanlık temanın neden yalnız renkleri tersine çevirmekten ibaret olmadığı UX-03'ün konusudur; bu derste yeterli olan, temanın bir token haritası olarak yazılabilmesidir.

Aynı mantık yüksek kontrast modu, bir alt marka ya da bir kampanya teması için de geçerlidir. Her biri, semantik katmanın ham palete başka bir bağlanışıdır.

Tasarım ile kod arasında tek kaynak

Token'ların çözdüğü ikinci sorun, tasarım dosyası ile kodun zamanla birbirinden kopmasıdır. Tasarımcı bir tasarım aracında birincil rengi günceller, geliştirici kodda eski değeri kullanmaya devam eder ve iki taraf aylarca farklı ürünler görür.

Olgun ekiplerde token'lar bir sürüm kontrol deposunda tek bir dosya olarak durur. Bir çeviri aracı bu dosyadan web için CSS özel özellikleri, mobil platformlar için kendi biçimlerini üretir; tasarım aracı da token'ları aynı dosyadan alır. Bir renk değişikliği bu dosyada bir satırlık bir düzenlemedir, bir kod incelemesinden geçer, sürüm numarası alır ve her platforma aynı değerle ulaşır. GT-10'daki marka rehberinin ana kaynağı ile bu dosya aynı işi farklı ortamlarda görür: biri basımevi, boyacı ve kumaşçı için, öbürü ekranlar için rengin tek doğru tanımıdır. İyi kurulmuş bir sistemde token dosyasının ham paletindeki marka rengi, rehberdeki ana kaynaktan türetilmiş ekran değeridir.

Var olan bir üründen token'a geçiş

Çoğu ekip token'larla sıfırdan başlamaz; sabit kodlarla dolu bir ürünü dönüştürür. Bu geçişin ilk adımı bir envanterdir: kod tabanındaki bütün renk değerleri toplanır ve kaç farklı değerin, kaç yerde kullanıldığı çıkarılır. Envanter çoğu zaman beklenenden kalabalıktır, çünkü göz kararı alınmış yakın kopyalar ayrı değerler olarak sayılır.

Ardından birbirine çok yakın değerler kümelenir ve her küme için bir ham palet basamağı seçilir. Bu, bir tasarım kararıdır, otomatik bir birleştirme değil: birbirine yakın iki gri, birinin kasıtlı olarak daha koyu seçildiği iki ayrı rolü taşıyor olabilir. Kümeleme bittiğinde her kullanım yeri tek tek incelenir ve ham değer yerine bir rol adı konur. Bu aşamada bazı yerlerin aslında aynı rolü taşıdığı, bazılarının ise hiçbir role uymadığı ortaya çıkar; ikinciler ya yeni bir semantik token alır ya da tasarımın gözden geçirilmesi gerektiğine işaret eder. Geçişin sonunda kod tabanında doğrudan yazılmış renk değeri kalmamalıdır; bunu bir kod denetim kuralıyla zorunlu kılmak, yeni sabit kodların sessizce geri gelmesini önler.

Örnek — görüntülü görüşmede ad etiketi

Bir görüntülü görüşme uygulaması, her katılımcının görüntüsünün sol alt köşesine adını yazan küçük bir etiket koyuyor. İlk sürümde etiket beyaz yazı ve yarı saydam bir siyah zeminle çiziliyor; iki değer de doğrudan bileşenin içine yazılmış.

Kullanıcılardan gelen bir şikâyet, sorunun bir değer değil bir yapı sorunu olduğunu gösteriyor. Koyu tenli ve koyu kıyafetli bir katılımcı, loş bir odada kameraya yakın oturduğunda, yarı saydam siyah zemin arkasındaki görüntüden neredeyse ayrılmıyor ve etiketin kenarı kayboluyor. Açık tenli bir katılımcı parlak bir pencerenin önünde oturduğunda ise etiket okunuyor ama zemin, yüzün bir kısmını gereksiz yere karartıyor. Tek bir sabit renk, arkasına düşebilecek bütün tenlere ve ortamlara aynı anda uymuyor.

Ekip önce etiketi token'lara bağlıyor: «video üstü etiket zemini» ve «video üstü etiket metni» adlı iki semantik token, bileşen token'ları da bunlara başvuruyor. Ardından tasarım kararını tek yerde değiştiriyor: zemin, yarı saydam siyah yerine daha opak, nötr koyu bir griye bağlanıyor ve etiketin çevresine ince, açık bir kenar çizgisi için üçüncü bir token ekleniyor. Böylece etiket, hem koyu hem açık bir görüntünün üzerinde sınırını koruyor. Değişiklik yüksek kontrast temasına da kendiliğinden geçiyor, çünkü o tema aynı semantik adları başka ham değerlere bağlıyor. Değişikliği sınamak için ekip, en açığından en koyusuna tenleri, loş odaları ve pencere önlerini içeren bir görüntü setinin üzerinde etiketi yeniden deniyor; sabit kodla bu deneme her ekran için ayrı bir düzeltme demek olurdu.

Sık yapılan yanlış

Özet

1. Bir butona doğrudan hex kodu yazmak rengin rolünü kaybeder; değişiklik bir arama işine döner, yakın kopyalar gözden kaçar ve her yeni tema her kopyanın ayrıca ele alınmasını gerektirir.
2. Renk token'ları çoğunlukla üç katmanda düzenlenir: anlam taşımayan ham palet ve ton skalaları, rolleri adlandıran semantik token'lar ve bileşenlere ait token'lar; katmanlar birbirine takma adlarla başvurur.
3. Token'lar tek bir dosyada tutulup tasarım araçlarına ve koda aynı yerden dağıtılır; bir tema ya da düzeltme, bileşenlere dokunmadan bağlantıların değişmesiyle ürünün tamamına ulaşır ve farklı tenlerden insanların görüntüleri üzerinde tek yerden sınanabilir.

Kendini sına

1. (Kolay) Tailwind CSS'in varsayılan paletinde bir renk kaç basamak taşır ve en açık ile en koyu basamak hangi numaraları alır?
2. (Kolay) Design Tokens Community Group'un biçim belirtimine göre bir token'ın tek zorunlu özelliği nedir?
3. (Orta) Bir butona doğrudan hex kodu yazmak neden uzun vadede sorun yaratır?
4. (Orta) Ham palet token'ı ile semantik token arasındaki fark nedir?
5. (Zor) Bir ürüne karanlık tema eklemek, token katmanlarıyla kurulmuş bir sistemde neden bileşenlere dokunmayı gerektirmez?
6. (Zor) Görüntülü görüşme uygulamasındaki ad etiketinin sorunu neden bir renk değeri değil bir yapı sorunuydu?

Cevaplar

1. On bir basamak; 50 en açık, 950 en koyu («Üç katman»).
2. Değeri («Token nedir»).
3. Kod rengin rolünü değil yalnız değerini taşır; değişiklikte aynı değerin bütün kopyaları aranmak zorunda kalır, bir iki basamağı farklı yazılmış kopyalar gözden kaçar, aynı değerin farklı işler gördüğü yerler ayırt edilemez ve karanlık tema gibi her yeni görünüm her kopyanın ayrıca elden geçirilmesini gerektirir («Sabit kodun bedeli»).
4. Ham palet token'ı bir değeri ton ailesi ve basamağıyla, anlam yüklemeden adlandırır; semantik token bir rolü adlandırır ve değerini ham paletten bir başvuruyla alır («Üç katman»).
5. Bileşenler semantik adları çağırır; karanlık temada değişen şey, bu adların bağlandığı ham değerlerdir. Bileşenlerin çağırdığı adlar aynı kaldığı için bileşenler değişmez («Temalar tek bir bağlantı değişikliğidir»).
6. İki değer doğrudan bileşene yazılmıştı ve tek bir sabit renk, arkasına düşebilecek bütün tenlere ve ışık koşullarına uymuyordu. Değerler token'lara bağlanınca karar tek yerde değişti, yüksek kontrast temasına da geçti ve farklı tenleri ve ışıkları içeren tek bir görüntü setinde bir kez sınanabildi («Örnek — görüntülü görüşmede ad etiketi»).

Kaynaklar

• Design Tokens Community Group, «Design Tokens Format Module», 2025.10.
• Material Web, «Material Theming», resmî belgeler.
• Tailwind CSS, «Colors», resmî belgeler.

Sonraki adım

UX-02 semantik katmanın içine giriyor: başarı, uyarı, hata ve bilgi rollerinin hangi renklerle neden bu kadar yaygın biçimde eşlendiğini, bu eşlemenin kırıldığı durumları ve her şeyin renkle uyardığı bir arayüzde kullanıcının uyarıları görmez hâle gelmesini tartışıyor. UX-03 ise bu dersin tema haritasını açıyor: aynı token yapısından bir karanlık tema üretirken saf siyahın yerine neden koyu griler seçildiğini ve yüzeylerin yükseldikçe neden açıldığını anlatıyor.