Tasarım Sistemi: Katmanları, Seçenekleri ve Bakım Maliyeti

Tasarım sistemi, renk ve tipografi kurallarından başlayıp üründe gerçekten çalışan bileşen kütüphanesine kadar uzanır. Çoğu ekip bu yolun ilk adımında durur: tasarım dosyasında özenli bir stil rehberi vardır, arayüzde hâlâ beş farklı buton. Asıl iş o mesafeyi kapatmaktır ve bu, tasarım işinden çok bakım işidir.

Sistem hangi katmanlardan oluşur

Bir tasarım sistemini üç ayrı şey olarak düşünmek işe yarıyor: kararlar, kararların somut hali, kararların nasıl kullanılacağının anlatımı.

• Stil rehberi: renk paleti, tipografi ölçeği, ikon seti, boşluk değerleri. Karar katmanı burasıdır, en kolay yazılanı da budur.
• Bileşen kütüphanesi: buton, form alanı, kart, tablo. Tasarım dosyasında ve kodda aynı isimle, aynı varyantlarla durması gerekir; durmadığında sistem ikiye ayrılır.
• Pattern'ler: giriş ekranı, ürün listesi, boş durum ekranı. Bileşenlerin tekrar eden birliktelikleri.
• Dokümantasyon: hangi bileşen ne zaman, hangi erişilebilirlik kuralıyla kullanılır. Yazılmazsa sistem sözlü geleneğe döner ve iki işe alım sonrasında kaybolur.

Hazırı almak, uyarlamak, sıfırdan kurmak

Material Design ya da Carbon gibi olgun bir sistemi doğrudan benimsemek en hızlı yol. Karşılığında ürününüz başkasının tasarım kararlarını taşır. Tasarım sistemine atfedilen faydaların başında marka dilinde tutarlılık gelir; hazır sistemi olduğu gibi aldığınızda tutarlı olan şey sizin markanız değil, onu üreten şirketin markası oluyor. Burada iki durumu ayırmak gerekiyor. İç araçlarda, admin panellerinde, bir ekibin günde sekiz saat baktığı ekranlarda hazır sistem neredeyse her zaman doğru seçim. Müşterinin markayla temas ettiği yüzeyde ise uyarlama yolu daha mantıklı: tokenları (renk, tipografi ölçeği, köşe yarıçapı) kendinize çekip bileşen davranışını olduğu gibi bırakmak.

Sıfırdan kurmak üçüncü seçenek ve çoğu ekibin tahmininden pahalı. Peki hangi durumda kaçınılmaz hale geliyor? Ürünün etkileşim modeli standart bileşenlerle ifade edilemiyorsa: zaman çizelgesi editörü, harita üstünde çizim. Buton ve form için sıfırdan sistem kurulmaz.

Maliyet nerede birikir

Pahalı olan kurulum değil, çarpım. Kırk bileşenlik bir kütüphaneyi web, iOS ve Android tarafında yaşatıyorsanız senkron kalması gereken yüz yirmi uygulamanız var. Tek bir renk tokenını değiştirmek, üç kod tabanında sürüm çıkarmak ve ardından o sürümü tüketen her ürünün yükseltmesini beklemek demek. Bileşen kütüphanesini tasarım aracında bitmiş saymam; kodda sürümlenmiş bir paket haline gelmeden elinizdeki şey stil rehberidir, sistem değildir.

Bu yüzden sistemi sahiplenen küçük bir ekip olmadan (bir etkileşim tasarımcısı, bir görsel tasarımcı, bir geliştirici yeter) kütüphane altı ay içinde ürünlerin gerisine düşer. Kimsenin işi değilse kimse yükseltmez. Ekipler kütüphaneyi kopyalayıp kendi içinde değiştirir ve ortaya tek sistem yerine dört çatal çıkar.

Ne zaman kurmamak daha iyi

Tek ürün, tek ekip, altı aylık bir proje. Burada sistem kurma maliyeti geri dönmez. Eşiği daha net koymak mümkün: aynı bileşeni iki farklı kişi, birbirinden bağımsız olarak ikinci kez yazdığında sistemin zamanı gelmiştir. Bundan öncesi, henüz var olmayan bir tekrarı çözmek için bakım yükü eklemek olur.

Küçük ekibin ara çözümü de var. Ortak bir token dosyası, beş on bileşenlik bir paket, dokümantasyon sitesi yerine kütüphanenin içindeki örnek dosyalar. Sistem büyüdüğünde kalanı eklenir; büyümezse zaten kaybınız yok.