Tasarım Sisteminden Production'a: Tutarlılığı Kodda Korumak
Token tabanlı bir tasarım sistemini Figma'dan production koduna taşırken tutarlılığı ölçeklendiren pratik bir yöntem.
Token tabanlı bir tasarım sistemini Figma'dan production koduna taşırken tutarlılığı ölçeklendiren pratik bir yöntem.
Güzel görünen değil, işleyen ve dönüştüren arayüzler nasıl tasarlanır?
Güzel görünen değil, müşteri kazandıran bir freelance portfolyosunun yapı, içerik ve dönüşüm prensipleri.
Her projede uyguladığım, çoğu zaman gözden kaçan ama büyük fark yaratan erişilebilirlik kuralları.
Genelde 24 saat içinde dönüş yapıyorum.
Çoğu ürün, başlangıçta güzel görünür ama büyüdükçe dağılır: aynı butonun beş farklı tonu, birbirine yakın ama eşit olmayan boşluklar, her ekranda biraz farklı bir gölge. Bu dağılma yetenek eksikliğinden değil, tek kaynağın olmamasından kaynaklanır. Tasarım sistemi tam da bu sorunu çözmek için vardır: tasarımdan koda kadar uzanan, paylaşılan bir doğruluk kaynağı.
Bu yazıda tasarım kararlarının üründe nasıl bire bir korunacağını, token tabanlı bir yaklaşımla anlatıyorum.
Token, bir tasarım kararının (renk, boşluk, tipografi, yarıçap) adlandırılmış ve makinece okunabilir hâlidir. Hedef, hem Figma'nın hem kodun aynı token tablosundan beslenmesidir.
:root {
--color-accent: #4f7a33;
--color-ink: #111014;
--space-4: 1rem;
--radius-card: 18px;
}
Bileşenler asla ham değer (#4f7a33, 16px) kullanmaz; yalnızca token'a referans verir. Böylece markanın aksan rengini değiştirmek tek satırlık bir iştir ve tüm ürün anında tutarlı kalır.
İyi bir token mimarisi üç katmanlıdır:
green-600, gray-900.accent, ink, surface. Bileşenler bunu kullanır.button-bg, card-border.Bileşenleri anlamsal katmana bağlamak, temeli değiştirdiğinizde kırılma yaşamadan tema değiştirebilmenizi sağlar.
Tutarlılığın ikinci ayağı, bileşenlerin kısıtlı ve niyetli olmasıdır. Bir butona istediğiniz her rengi geçirebiliyorsanız, sistem değil kaos kurmuşsunuz demektir. Bunun yerine variant üzerinden sınırlı, tanımlı seçenekler sunun:
type ButtonProps = {
variant?: "primary" | "secondary" | "ghost";
size?: "sm" | "md" | "lg";
};
Bu yaklaşımın faydaları:
Token'ları elle iki yerde tutmak, drift'in (sapma) kaynağıdır. Bunun yerine tek bir kaynaktan üretin:
Böylece "Figma'da değişti ama kodda unutuldu" sınıfı hataları sistematik olarak ortadan kaldırırsınız.
Görsel tutarlılık, gözle kontrol edilemeyecek kadar büyür. İki tür test işinizi görür:
Bu projede de uyguladığım ilke şu: bir değer iki yerde yaşıyorsa, ya birleştir ya da bir test ile eşitliğini kilitle. Çift bakım her zaman sapar.
Hiç kimsenin nasıl kullanacağını bilmediği bir tasarım sistemi, kullanılmaz. Canlı bir dokümantasyon (ör. Storybook) ile:
Tutarlı bir sistem, erişilebilirliği de tutarlı kılar. Token düzeyinde kontrast oranlarını garanti edin (ör. aksan/zemin ≥ 4.5:1), odak halkalarını bileşene gömün, anlamsal HTML kullanın. Böylece her yeni ekran otomatik olarak WCAG 2.2 AA'ya yakın doğar.
Tasarım sistemi bir kütüphane değil, bir anlaşmadır. Tasarımcı ile geliştiricinin (ki bu projede aynı kişi) aynı dili konuşmasını sağlar — ve tutarlılık, tesadüf olmaktan çıkıp garantiye dönüşür.