Bir acente yöneticisi sabah ofiste web panelinden günlük raporlara bakar, öğleden sonra müşteri ziyaretinde aynı verilere mobil uygulamadan ulaşır. İki ekranda farklı mavi tonları, farklı yazı büyüklükleri ve farklı durum renkleri görürse, aynı ürünü kullandığından şüphe etmese bile her geçişte küçük bir uyum çabası harcar. Daha önemlisi, web panelinde "gecikmiş" anlamına gelen renk mobilde başka bir anlam taşıyorsa, yanlış yorum riski ortaya çıkar.
Tasarım token'ları, bu tür tutarsızlıkları kaynağında önlemek için kullanılan bir yöntemdir. Bu yazıda token kavramını, acente yazılımı bağlamında nasıl uygulanabileceğini ve dikkat edilmesi gereken noktaları ele alıyoruz.
Tasarım Token'ı Nedir?
Tasarım token'ı, bir tasarım kararının isimlendirilmiş ve platformdan bağımsız biçimde saklanmış halidir. Örneğin belirli bir mavi tonunun kodu yerine "birincil renk", belirli bir piksel değeri yerine "orta boşluk" gibi isimler kullanılır. Bu isimler tek bir kaynakta tanımlanır ve buradan web, iOS ve Android gibi farklı platformların kullanabileceği biçimlere dönüştürülür.
Token'lar genellikle şu kategorilerde tanımlanır:
- Renkler,
- Yazı tipleri, boyutları ve satır yükseklikleri,
- Boşluk ölçüleri,
- Köşe yuvarlaklıkları ve çerçeve kalınlıkları,
- Gölgeler ve katman seviyeleri,
- Animasyon süreleri.
Ham Değerden Anlamsal İsme
Token sistemlerinde genellikle iki katman bulunur. İlk katman, ham değerleri tanımlar: "mavi-600" ya da "gri-100" gibi. İkinci katman ise bu ham değerlere anlam yükler: "birincil eylem rengi", "uyarı arka planı", "ikincil metin rengi" gibi.
Anlamsal katman, acente yazılımı için özellikle değerlidir. Durum renkleri, örneğin "yenileme yaklaşıyor", "tahsilat gecikmiş" ya da "teklif tamamlandı", ham renk adlarıyla değil anlamsal isimlerle tanımlandığında, hem web panelinde hem mobil uygulamada aynı anlam aynı görsel karşılıkla eşleşir. Gelecekte bir renk tonu değiştirilmek istendiğinde, yalnızca token değeri güncellenir; tüm ekranlar otomatik olarak yeni değeri kullanır.
Web ve Mobil Arasında Neler Ortak Olmalı?
Platformlar arasında her şeyin birebir aynı olması gerekmez. Mobil işletim sistemlerinin kendi gezinme kalıpları, dokunma hedefi büyüklükleri ve sistem yazı tipleri vardır. Token yaklaşımında amaç, platformun doğasını bozmadan ürünün kimliğini ve anlam dilini korumaktır.
Ortak tutulması önerilenler
- Marka ve eylem renkleri,
- Durum ve uyarı renkleri ile bunların anlamları,
- İkon seti ve ikonların anlamları,
- Boşluk ölçeğinin oranları,
- Köşe yuvarlaklıklarının karakteri.
Platforma göre uyarlanabilecekler
- Yazı tipi ailesi ve boyut ölçeği,
- Gezinme bileşenleri,
- Dokunma hedeflerinin asgari boyutu,
- Animasyon karakteri.
Token'larla Koyu Tema ve Erişilebilirlik
Anlamsal token'lar, tema desteğini de kolaylaştırır. "Sayfa arka planı" ve "birincil metin" gibi token'lar açık ve koyu tema için farklı değerlere sahip olabilir; bileşenler hangi temada olduklarını bilmek zorunda kalmaz. Sahada, düşük ışıkta mobil uygulama kullanan bir çalışan için koyu tema rahatlık sağlarken, token yapısı durum renklerinin anlamının korunmasını garanti eder.
Erişilebilirlik açısından da token'lar bir kontrol noktası sunar. Her metin ve arka plan token çifti için kontrast oranı önceden hesaplanabilir ve yetersiz eşleşmeler daha ekranlara ulaşmadan tespit edilebilir.
Uygulama Adımları
- Mevcut değerleri toplayın: Web ve mobil kod tabanında kullanılan tüm renk, boyut ve boşluk değerlerini listeleyin. Bu liste genellikle birbirine çok yakın ama farklı onlarca değer içerir.
- Değerleri sadeleştirin: Yakın değerleri birleştirerek sınırlı bir ölçek oluşturun.
- Anlamsal isimleri belirleyin: Değerlerin nerede ve neden kullanıldığını yansıtan isimler verin.
- Tek kaynak oluşturun: Token'ları platformdan bağımsız bir dosyada tanımlayın ve buradan platformlara özgü çıktılar üretin.
- Bileşenleri token'lara bağlayın: Bileşen kodunda sabit değer yerine token adları kullanılmasını sağlayın.
- Kademeli geçiş yapın: Önce en çok kullanılan ekranları ve bileşenleri taşıyın.
Dikkat Edilmesi Gereken Tuzaklar
- Aşırı ayrıntı: Her küçük kullanım için ayrı token tanımlamak, sistemi yönetilemez hale getirir.
- Belirsiz isimler: "renk-1", "renk-2" gibi isimler anlam taşımaz ve token yaklaşımının faydasını ortadan kaldırır.
- Kaynağın dışında değer kullanımı: Geliştiricilerin kolaylık için sabit değer kullanmaya devam etmesi, tutarlılığı yavaş yavaş bozar. Kod incelemelerinde bu durum kontrol edilmelidir.
- Tek taraflı güncelleme: Token değişikliğinin yalnızca bir platforma yansıtılması, platformlar arasındaki farkı yeniden doğurur.
Branş Ekranlarında Tutarlılık
Trafik, kasko ve DASK tekliflerinin ayrı sorgu akışları vardır ve her biri web panelinde ve mobil uygulamada kendi ekranlarına sahiptir. Token'lar sayesinde bu ekranların tamamı aynı görsel dili konuşur. Bir kullanıcı sahada mobilden başlattığı DASK teklifini ofiste webden açtığında, durumları ve eylemleri aynı renk ve ikon anlamlarıyla görür.
Örnek: Bir Durum Renginin Güncellenmesi
Kullanıcı geri bildirimleri, "yenileme yaklaşıyor" durumunda kullanılan sarı tonun açık arka planda zor okunduğunu gösteriyor olsun. Token yapısı yoksa bu rengin geçtiği her ekranı web ve mobil kod tabanlarında tek tek bulmak ve değiştirmek gerekir; bazı yerler kaçırılır ve iki platform arasında yeni bir tutarsızlık doğar. Token yapısında ise yalnızca "uyarı metni" ve "uyarı arka planı" token'larının değerleri güncellenir, kontrast oranı yeniden hesaplanır ve değişiklik iki platforma aynı anda yansır.
Bu küçük örnek, token'ların yalnızca başlangıçta değil, ürünün yaşamı boyunca bakım maliyetini düşürdüğünü gösterir.
Görünmeyen Ama Hissedilen Bir Altyapı
Kullanıcılar tasarım token'larını hiçbir zaman doğrudan görmez. Ancak sonuçlarını her gün hisseder: Web panelinden mobil uygulamaya geçerken yeniden alışma ihtiyacının olmaması, durum renklerinin her yerde aynı anlamı taşıması ve arayüzün bütünlüklü görünmesi bu altyapının ürünleridir.
InsureHub'da web paneli ile mobil uygulamanın aynı veriyle ve aynı görsel dille çalışmasını hedefliyoruz. İki platformu yan yana denemek için demo talebi oluşturabilirsiniz.