Renk, bir arayüzün karakterini birkaç saniyede kurabilir; fakat tek başına marka hissi üretmek için seçildiğinde kullanılabilirliği kolayca zayıflatır. Sağlam bir renk sistemi, estetik tercihi erişilebilirlik, içerik hiyerarşisi ve ürün davranışıyla birlikte ele alır. Amaç mümkün olduğunca çok renk kullanmak değil, her rengin hangi görevi üstlendiğini açıkça tanımlamaktır.
Palet ile sistem arasındaki fark
Palet, yan yana duran renk örnekleridir. Sistem ise bu örneklerin nerede, neden ve hangi koşulda kullanılacağını tarif eder. Ana marka rengi, nötr yüzeyler, metin tonları, kenarlıklar, odak göstergeleri ve başarı, uyarı, hata gibi durum renkleri ayrı rollere ihtiyaç duyar. Bir rengin adını “mavi 500” olarak tutmak üretim için yararlı olabilir; ancak bileşenlerin doğrudan bu ham değere bağlanması ileride tema değiştirmeyi zorlaştırır.
Bu nedenle temel renk tokenları ile anlamsal tokenları ayırmak iyi bir başlangıçtır. “blue-600” temel bir değeri, “action-primary-background” ise kullanım amacını anlatır. Açık tema, koyu tema veya farklı marka varyantı geldiğinde bileşen aynı anlamsal adı kullanmaya devam eder; yalnızca o adın bağlandığı değer değişir.
Kontrastı tasarımın başında ölçmek
WCAG 2.2 düzey AA kapsamında normal metin için en az 4.5:1, büyük ölçekli metin için en az 3:1 kontrast oranı ister. Bunlar yalnızca yayın öncesi kontrol listesine bırakılmamalıdır. Tasarım dosyasındaki metin, yüzey ve etkileşim tokenları daha ilk oluşturulurken uygun eşleşmelerle sınanmalıdır. Fontun ince olması, görüntünün üzerine yerleşmesi veya yarı saydam katman kullanılması gerçek ekrandaki sonucu değiştirebilir; yalnızca renk seçicideki iki HEX değerini ölçmek her zaman yeterli değildir.
Metin dışındaki aktif kontrol sınırları, ikonlar ve odak göstergeleri için de kontrast düşünülmelidir. Soluk bir input kenarlığı estetik olarak hafif görünebilir, fakat alanın nerede başladığını seçemeyen kullanıcı için formu kullanılamaz hale getirebilir. Hover, pressed, selected, disabled ve focus durumları ayrı ayrı test edilmelidir.
Renk tek başına anlam taşımamalı
WCAG, rengin bilgi iletmenin tek görsel aracı olmamasını söyler. Hata alanını yalnızca kırmızı çerçeveyle göstermek yerine anlaşılır bir hata metni ve gerekirse ikon eklenmelidir. Grafiklerde iki seriyi sadece renk tonu ile ayırmak yerine çizgi biçimi, etiket veya desen de kullanılabilir. Başarılı bir işlemi yeşil yapmak faydalıdır; fakat “Kaydedildi” mesajı olmadan bütün kullanıcılar aynı sonucu çıkaramayabilir.
Bu yaklaşım tasarımı renksizleştirmez. Aksine renk, üzerine yüklenen bütün anlamı tek başına taşımak zorunda kalmadığı için daha kontrollü kullanılabilir. Renk körlüğü simülasyonları yardımcı bir testtir; gerçek metin, ikon ve etiket yapısının yerini tutmaz.
Nötr skala ve yüzey hiyerarşisi
İyi bir arayüzün büyük bölümü marka renginden değil nötr tonlardan oluşur. Arka plan, yükseltilmiş kart, ikincil yüzey, ayırıcı, ana metin ve ikincil metin için yeterli fakat gereksiz derecede kalabalık olmayan bir nötr skala kurulmalıdır. Her yeni tasarımda farklı bir gri üretmek zamanla tutarsızlık yaratır. Yüzey seviyelerini tokenlarla sınırlandırmak hem açık hem koyu temada hiyerarşiyi korur.
Koyu tema, açık temadaki renkleri ters çevirmek değildir. Çok doygun vurgu renkleri karanlık zeminde titreşebilir; saf beyaz uzun metinde göz yorabilir. Her anlamsal çift yeniden ölçülmeli, görseller ve gölgeler de koyu bağlamda kontrol edilmelidir.
Durum renklerini gerçek akışlarla sınamak
Başarı, bilgi, uyarı ve hata renkleri aynı anda bir tabloda görünmeyebilir; fakat ürün içinde metin, ikon, arka plan ve sınır olarak farklı rollerde kullanılır. Her durum için güçlü metin, yumuşak yüzey ve belirgin sınır varyantları tanımlanabilir. “Warning text” ile “warning background” aynı renk değeri olmamalıdır; okunabilirlik için gereken tonlar farklıdır.
Testi yalnızca örnek bir bildirim kartında yapmak yerine form doğrulama, ödeme sonucu, boş durum, toast ve grafik gibi gerçek senaryolarda yürütmek gerekir. Böylece renk sisteminin içerik yoğunluğu arttığında da çalışıp çalışmadığı anlaşılır.
Tasarım ve kod arasında tek kaynak
Token adları Figma değişkenleriyle kod değişkenleri arasında eşleşmelidir. Bir bileşen kütüphanesi “text-muted” kullanırken tasarım dosyası “gray-04” kullanıyorsa ekip aynı kararı iki kez yorumlar. İsim, değer, açıklama, kullanım örneği ve kaçınılacak senaryolar tek bir dokümantasyonda tutulmalıdır. Değişiklikler sürümlenmeli; kontrastı düşüren bir token güncellemesi otomatik testte yakalanmalıdır.
Uygulanabilir kontrol listesi
Önce ürünün bütün renk kullanım alanları çıkarılır. Ardından temel palet, anlamsal roller ve tema eşlemeleri tanımlanır. Normal ve büyük metin kontrastları ölçülür; aktif kontroller, ikonlar ve odak halkaları ayrıca sınanır. Hata ve başarı gibi durumlarda metin veya ikon desteği doğrulanır. Son olarak sistem gerçek telefonlarda, farklı ekran parlaklıklarında ve mümkünse farklı görme ihtiyaçlarına sahip kullanıcılarla test edilir.
Renk sistemi bir kere hazırlanıp kapanan stil sayfası değildir. Yeni bileşenler, kampanyalar ve temalar geldikçe aynı kurallar üzerinden genişlemeli; istisnalar belgelenmelidir. Böylece marka karakteri korunurken okunabilirlik ve ürün güveni tesadüfe bırakılmaz.
Renk sistemini kontrast, durum ve tema boyutlarıyla kurmak, marka renginin birkaç HEX kodundan fazlası olmasını sağlıyor. Grafik tasarım hizmetimde renk, tipografi ve kompozisyon kararlarını bu ölçülebilirlikle birlikte belirliyorum.
