Design System ve Stil Rehberi: Farkı Kapsam Değil Yaptırım Belirler

Design system ve stil rehberi ayrımı genelde kapsam üzerinden anlatılır: biri geniş bir çatı, diğeri o çatının altındaki parçalardan biri. Tanım olarak yanlış değil, ama bir ekibe hangisinin gerektiğini söylemiyor. Asıl ayrım başka yerde: yazılı kuralın uygulamada karşılığı var mı, yok mu. Renk paletini bir dokümanda tarif etmekle, paleti değiştirdiğinizde arayüzün gerçekten değişmesi arasında epey mesafe var.

Kapsam ayrımı doğru ama yetersiz

Standart tarif şöyle: stil rehberi renk, tipografi, ikonografi, ses tonu gibi belirli bir alanın kurallarını yazar; design system bunların üstüne bileşen kütüphanesi, örüntüler ve dokümantasyon ekler. Buraya kadar itirazım yok. Sorun, tarifin design system'i "daha çok doküman" gibi göstermesi.

Aradaki gerçek fark hacimde değil. Stil rehberi arayüzü tarif eder, bileşen kütüphanesi arayüzü üretir. Butonun köşe yarıçapını bir sayfada 8px diye yazarsanız ekip bunu okur ve çoğunlukla uyar; aynı değeri bileşenin içine koyarsanız uymamak için fazladan çaba harcamak gerekir. Material Design ya da Carbon referans gösterilirken genelde atlanan şey, bu sistemlerin ağırlığının dokümantasyon sitesinde değil, kurulup projeye dahil edilen paketlerde olması.

Kaynakların kendi içinde takıldığı yer

Konuyu anlatan metinlerin çoğunda aynı çelişki duruyor. Bir yanda stil rehberi design system'in bileşenlerinden biri olarak listeleniyor, öbür yanda karşılaştırma tablosunda design system "yaşayan, sürekli güncellenen", stil rehberi "statik, nadiren güncellenen" diye ayrılıyor. İkisi aynı anda doğru olamaz. Parça bütünün içindeyse bütünle birlikte değişir.

Pratikte olan şu: stil rehberi gerçekten geride kalıyor, ama bu doğası gereği değil, ayrı bir yerde durduğu için. Renk tanımı bir sunum dosyasında, PDF'te ya da wiki sayfasında yaşıyorsa güncellenmesi ayrı bir iş kalemidir, ve o iş kalemi hep sonraya bırakılır. Aynı tanım bileşenlerin okuduğu token dosyasındaysa güncellenmemesi zaten mümkün değil, çünkü güncellenmediği anda arayüz yanlış görünür.

Bakım iki yerde birden yapılıyor

Design system kurmanın en çok hafife alınan tarafı burası. Her bileşen en az iki yerde var: tasarım aracında ve kodda. Otuz bileşenlik mütevazı bir kütüphanede bile bu, eşzamanlı tutulacak altmış nokta demek, üstelik ikisi farklı ekiplerin sorumluluğunda.

Tek kaynaktan üretmenin yolu belli: renk, aralık, tipografi ölçeği gibi değerleri token olarak bir yerde tanımlayıp hem tasarım aracına hem CSS'e oradan dağıtmak. Kurulumu birkaç günlük iş, atlanması ise yıllara yayılan bir eşitleme borcu. Bir projede buton bileşeninin tasarımdaki hali ile koddaki hali altı ay içinde birbirinden ayrılmıştı; kimse hata yapmıyordu, sadece iki ayrı yerde güncelleme gerekiyordu ve biri hep unutuluyordu.

Kuralın uygulandığını nasıl anlarsınız

Dokümantasyonun zayıf tarafı, okunduğunu varsaymasıdır. Oysa bir kuralın tutup tutmadığını ölçmenin ucuz yolları var: token dışında tanımlanmış renkleri yakalayan bir lint kuralı, bileşen kütüphanesi dışından gelen stilleri sayan basit bir tarama, sürüm öncesi görsel karşılaştırma. Bunların hiçbiri rehber yazmaktan pahalı değil, ve rehberden farklı olarak kimsenin okumasına ihtiyaç duymaz.

Böyle bir ölçüm kurmadan "tutarlılık sağladık" cümlesi bir temenniden ibaret kalır. Kaç ekranın kütüphane dışına çıktığını bilmiyorsanız, sisteminizin ne kadar işlediğini de bilmiyorsunuz demektir.

Küçük ekipte design system kurmak erkendir

Tek ürün, tek ekip, beş kişi varsa cevap net: stil rehberini yazın, değerleri CSS değişkenlerine taşıyın, bileşenleri ihtiyaç çıktıkça ortaklaştırın. Design system'in maliyeti üreten tarafta, faydası tüketen tarafta birikir. Tüketici sayısı bire yakınken denge negatiftir.

Eşiğin geçildiğini anlamanın işareti soyut değil: aynı bileşeni birbirinden habersiz iki ekip ayrı ayrı yazmaya başladığında, ya da bir marka değişikliğinin kaç dosyaya dokunacağını kimse kestiremediğinde eşik geçilmiştir. O noktaya gelmeden kurulan sistem, kullanıcısı olmayan bir kütüphaneyi bakımda tutmaktan başka bir şey değildir.