Tasarım Sistemi Kurmak İçin Doğru Zaman Ne Zaman?

"Bir tasarım sistemi kuralım" cümlesi genellikle bir eşik gibi konuşulur: bugün yok, yarın olacak.

Pratikte tasarım sistemi bir eşik değil, bir ölçektir. Bir ürünün üzerinde iki kişi çalışıyorsa, ortak kararlar zaten vardır — yazılı olmasalar bile. Soru "sistem kuralım mı" değil, "hangi seviyesini bugün ödemeye değer" sorusudur.

Bu soruyu atlayan ekipler iki yönden birine düşer: ya hiç kurmaz ve her ekranda aynı kararları yeniden verir, ya da ürünün ihtiyacından çok daha büyük bir sistem kurup bakımını üstlenemez.

Tasarım sistemi tek bir şey değil

Aynı isim altında dört farklı olgunluk seviyesi konuşulur ve bunlar birbirinin yerine geçmez.

Ortak kararlar. Renk, tipografi ölçeği, boşluk ritmi ve köşe yarıçapı gibi değerlerin bir kez belirlenip kullanılması. Genellikle birkaç token'dan ibarettir ve neredeyse her ürün için erken aşamada bile karşılığını verir.

Bileşen kütüphanesi. Buton, form alanı, modal gibi tekrar eden parçaların tek bir yerde tanımlanması. Faydası, aynı parçanın üçüncü kez yazılmasıyla başlar.

Belgelenmiş kalıplar. Bileşenin nasıl göründüğü değil, ne zaman kullanıldığı. "Hangi durumda modal, hangi durumda ayrı sayfa" sorusunun cevabı buradadır ve çoğu ekibin gerçekten eksik olduğu katman budur.

Yönetilen sistem. Değişiklik önerisinin nasıl geldiği, kimin karar verdiği, sürümlemenin nasıl yürüdüğü. Bu seviye bir ürünü değil, birden fazla ürünü veya birden fazla ekibi varsayar.

İlk seviye neredeyse herkes için doğrudur. Dördüncü seviye, çoğu şirket için hiçbir zaman gerekmez.

Erken kurmanın maliyeti

Tasarım sistemi bir soyutlamadır ve her soyutlama, henüz görülmemiş bir düzeni tahmin etmeye çalışır.

Ürün üç ekrandan ibaretken kurulan bir bileşen kütüphanesi, bu üç ekranın ihtiyacını genelleştirir. Dördüncü ekran geldiğinde bileşen ya uymaz ya da uyması için sekiz yeni parametre alır. Sekiz parametreli bir buton, bileşen olmaktan çıkıp yeni bir dil hâline gelir; öğrenmesi sıfırdan yazmaktan zordur.

İkinci maliyet hızdır. Erken aşamada asıl risk tutarsızlık değil, yanlış ürünü yapmaktır. Her değişikliğin önce sistemden geçmesi gereken bir kurulum, denemeyi pahalılaştırır.

Üçüncüsü bakımdır. Sistem de bir üründür: sürümü, dokümantasyonu ve kullanıcıları vardır. Kimsenin sahiplenmediği bir sistem birkaç ay içinde gerçekle uyuşmayı bırakır — ve yanlış bir dokümantasyon, hiç olmamasından daha maliyetlidir.

Geç kalmanın maliyeti

Ters yön daha sessiz ilerler.

Tutarsızlık tek seferde ortaya çıkmaz; her ekranda küçük bir sapma olarak birikir. Bir yıl sonra üründe yedi farklı gri tonu, dört farklı buton yüksekliği ve iki farklı form davranışı olur. Hiçbiri tek başına yanlış değildir; toplamda ürün derlenmemiş hissi verir.

Daha somut maliyet, değişiklik anında ortaya çıkar. Marka rengi güncellenecekse veya form alanlarının davranışı değişecekse, iş bir arama-bulma çalışmasına dönüşür. Bu noktada yenileme kararı genellikle gereğinden büyük görünür, çünkü küçük bir değişiklik bile her yeri açmayı gerektirir.

Üçüncü maliyet ekip üzerindedir. Yazılı karar yoksa, her yeni ekran bir müzakereyle başlar ve aynı tartışma birkaç ayda bir tekrarlanır.

Hazır olduğunuzu gösteren sinyaller

Aşağıdakiler, sistemi büyütmenin makul hâle geldiği durumlardır.

Aynı bileşeni üçüncü kez yazıyorsanız, tekrar artık gerçektir; iki kez yazmak henüz bir örüntü değildir.

Arayüz üzerinde birden fazla kişi çalışıyorsa, ortak karar yazılı olmadığında farklılaşma kaçınılmazdır. Tek kişilik bir üründe sistem çoğu zaman o kişinin kafasındadır ve bu bir süre yeterlidir.

Ürün ilk yeniden tasarımını atlattıysa, hangi kararların kalıcı hangilerinin geçici olduğu artık gözlemle bilinir. Bu, tahminle genelleme yapma riskini büyük ölçüde ortadan kaldırır.

Aynı soru farklı ekranlarda tekrar tartışılıyorsa — "bu bir modal mı olsun" gibi — eksik olan bileşen değil, kalıp dokümantasyonudur.

Nereden başlamalı

En yaygın hata, bileşenlerden başlamaktır. Daha güvenli sıra tersidir.

Önce token'lar gelir: renk, tipografi ölçeği, boşluk, yarıçap, gölge. Bunlar ürünün ne yaptığından bağımsızdır, tahmin riski taşımaz ve tek başlarına tutarsızlığın büyük kısmını kapatır.

Token'ları adlandırırken de bir tercih yapılır ve bu tercih sistemin ömrünü belirler. Rengi gördüğü gibi adlandırmak — mavi-500 — kısa vadede kolaydır; ancak marka rengi değiştiğinde ürünün her yerinde adı yanlış olan bir token kalır. Rolüne göre adlandırmak — birincil-eylem, kenarlık-sakin — ilk gün biraz daha fazla düşünmek gerektirir, sonrasında değişimi tek bir yere indirir.

Aynı mantık boşluk ve tipografi için de geçerlidir: ölçeğin adımlarına isim vermek, her kullanımda ham piksel değeri yazmaktan daha dayanıklıdır.

Sonra en çok tekrar eden üç bileşen gelir — genellikle buton, form alanı ve bir çeşit kart. Hepsi değil, üçü.

Kalıp dokümantasyonu ise en çok atlanan ve en yüksek getirili kısımdır. Bir bileşenin nasıl göründüğü koddan okunabilir; ne zaman kullanılacağı okunamaz. Bunu yazmak birkaç paragraflık bir iştir ve tekrarlayan tartışmaların çoğunu bitirir.

Sistem, ürünü izleyerek büyümelidir. Görsellik ve kullanılabilirlik dengesi yazısında belirtildiği gibi, iyi bir sistem istisnayı yasaklamaz; istisnanın bilinçli olduğunu görünür kılar.

Kurulduktan sonraki asıl sınav: benimsenme

Doğru zamanda kurulmuş bir sistem de başarısız olabilir. En yaygın biçimi, sistemin var olup kullanılmamasıdır.

Bu genellikle kötü niyetten değil sürtünmeden kaynaklanır. Sisteme bir bileşen eklemek, o bileşeni ekranın içinde doğrudan yazmaktan zorsa, teslim baskısı altındaki herkes ikinciyi seçer. Birkaç ay sonra sistem, ürünün gerçekte kullandığı şeyin yalnızca bir bölümünü tarif eder hâle gelir.

İkinci biçim, sistemin ihtiyacı karşılamamasıdır. Bir tasarımcı aradığı varyantı bulamadığında yeni bir tane yapar; bu varyant sisteme geri dönmezse, sistem güncelliğini kaybetmeye başlar.

Buradaki ayırt edici alışkanlık sade: istisnayı yasaklamak yerine geri besleme yolunu açık tutmak. "Bunu sistemde bulamadım, şöyle yaptım" cümlesinin gidebileceği bir yer varsa sistem canlı kalır; yoksa dokümantasyon yavaşça kurguya dönüşür.

Tasarım dosyası ile kod arasındaki kayma

Çoğu sistem iki yerde birden yaşar: tasarım aracında ve kodda. İkisi ayrı ayrı güncellendiğinde aralarındaki fark zamanla büyür.

Belirtisi tanıdıktır: tasarımda 8 piksel olan boşluk üründe 10'dur, tasarımdaki gri koddaki griden biraz farklıdır, bir bileşenin tasarımda üç varyantı vardır ama kodda beş.

Bu farkların her biri küçüktür ve hiçbiri hata sayılmaz. Ancak biriktiklerinde tasarım dosyası bir referans olmaktan çıkar; ekip hangisinin doğru olduğunu bilmediği için ikisini de sorgulamaya başlar.

Tek kaynaktan beslenen token'lar bu kaymanın büyük kısmını engeller. Bunu kurmak erken aşamada birkaç saatlik iştir; sonradan yapmak, iki tarafı elle karşılaştırmak anlamına gelir.

Sonuç

Tasarım sistemi bir olgunluk rozeti değil, bir bakım yükümlülüğüdür. Doğru seviyede tutulduğunda tartışmayı azaltır; ürünün önüne geçtiğinde kendisi işe dönüşür.

Pratik ölçüt sade: sistem, ekibin gününü kısaltıyorsa doğru boyuttadır. Ekibin günü sistemi güncellemekle geçiyorsa, ürün için değil sistem için çalışılıyordur. Bu ölçüt her çeyrekte bir sorulduğunda, sistemin fazla büyüdüğü nokta gecikmeden fark edilir.

Çoğu ürün için doğru cevap "hayır" ya da "evet" değil, "şimdilik token'lar ve üç bileşen" biçimindedir — ve bu cevap, ürün tasarımı çalışmalarımızda ürün büyüdükçe yeniden gözden geçirilir.