Tasarım sistemi kurmak iyi bir fikir gibi görünür ve çoğu zaman öyledir. Ama iki yönde de hata yapılır: beş ekranlı bir ürün için aylar süren bir sistem kurmak ve onlarca ekranlı bir ürünü hiç sistem olmadan büyütmek. Doğru zamanı belirlemek için önce neyin kastedildiğini netleştirmek gerekir.
Tasarım sistemi ile UI kit arasındaki fark #
UI kit bir dosyadır: düğmelerin, form alanlarının, kartların ve renklerin toplandığı bir Figma kütüphanesi. Tasarımcının işini hızlandırır ama yalnız tasarım tarafında yaşar.
Tasarım sistemi ise bir çalışma düzenidir. Tasarım tokenları, tasarım ve kod tarafında birbirinin karşılığı olan bileşenler, kullanım kuralları, dokümantasyon ve sistemde kimin nasıl değişiklik yapacağını söyleyen yönetişim modeli bu düzenin parçalarıdır. Fark şurada görünür: UI kit'te bir düğmenin rengini değiştirirseniz tasarım dosyası güncellenir. Sistemde aynı değişiklik, tek bir token üzerinden ürünün tamamına yayılır.
Bu ayrım önemlidir, çünkü birçok ekibin "tasarım sistemimiz var" dediği şey bir UI kit'tir ve ilk aşamada ihtiyaç da çoğu zaman bundan fazlası değildir.
Zamanı belirleyen altı ölçüt #
Sistemin gerekip gerekmediğine şu altı soru birlikte karar verir.
- Ekran sayısı: ürün birkaç ekrandan mı oluşuyor, yoksa onlarca ekran ve modül mü var?
- Ürünün ömrü: bir kampanya sitesi mi, yıllarca geliştirilecek bir ürün mü?
- Ekip büyüklüğü: aynı arayüze tek tasarımcı ve tek geliştirici mi dokunuyor, yoksa birden çok ekip mi?
- Tekrar eden bileşenler: aynı tablo, form ya da kart kaç farklı yerde kullanılıyor?
- Platform sayısı: yalnız web mi, yoksa web, iOS ve Android birlikte mi?
- Tasarım ile kod arasındaki fark: Figma'daki ekran ile yayındaki ekran ne kadar ayrışmış durumda?
Bu soruların çoğuna "az" ya da "tek" cevabı veriliyorsa kapsamlı bir sistem yüktür. Çoğuna "çok" cevabı veriliyorsa sistemin eksikliği her sürümde bedel ödetir.
Çok erken kurulduğunda oluşan yük #
Ürünün ne olacağı henüz belli değilken kurulan sistem, yanlış soruya verilmiş ayrıntılı bir cevaptır. Bileşenler henüz kullanılmadan soyutlanır, ürün yön değiştirdiğinde sistemin büyük kısmı atılır.
Erken kurulan sistemin ikinci maliyeti bakımdır. Her bileşenin varyantları, durumları ve dokümanı güncel tutulmak zorundadır. Küçük bir ekipte bu iş ürün geliştirmeye ayrılacak zamandan düşer. Üçüncü maliyet katılıktır: ekip, sistemde olmayan bir çözümü denemekten kaçınmaya başlar ve ürün erken dönemde ihtiyaç duyduğu esnekliği kaybeder.
İlk sürümünü çıkarmamış bir ürün için doğru yatırım sistem değil, tutarlı birkaç temel karardır.
Çok geç kalındığını gösteren belirtiler #
Sistemin zamanı geçtiyse ürün bunu kendisi söyler.
- Aynı işi yapan birden çok düğme, modal ya da tablo türü vardır.
- Yeni bir ekran tasarlamak, mevcut bir ekranı kopyalayıp düzeltmekle başlar.
- Tasarım dosyasındaki ekran ile yayındaki ekran arasında aralık, renk ve davranış farkları birikmiştir.
- Küçük bir görsel değişiklik için onlarca dosyaya dokunmak gerekir.
- Ekibe yeni katılan biri hangi bileşenin doğru olduğunu soracak kimse bulamaz.
- Farklı platformlardaki aynı özellik farklı görünür ve farklı davranır.
Bu belirtilerin birkaçı birlikte görülüyorsa ekip zaten bir sistemin maliyetini ödüyordur; yalnız karşılığını almıyordur.
Minimum uygulanabilir tasarım sistemi #
Sistem kurmak, ya hep ya hiç bir karar değildir. En küçük işe yarar sistem şunlardan oluşur.
- Temel tokenlar: renk, yazı ölçeği, aralık ve köşe yarıçapı. Tasarım ve kod tarafında aynı adlarla.
- En sık kullanılan bileşenler: düğme, form alanı, seçim öğeleri, kart, tablo ve modal. Bütün durumlarıyla birlikte.
- Kısa kullanım kuralları: hangi bileşen ne zaman kullanılır, ne zaman kullanılmaz.
- Sahiplik: sistemde değişiklik yapma kararını kim verir.
Bu dört parça birkaç bileşenle başlar ve ürün büyüdükçe genişler. Ölçüt, bileşenin en az iki üç yerde gerçekten kullanılıyor olmasıdır. Kullanılmayan bileşen sisteme girmez.
Denetim ve kurulum süreci #
Yayındaki bir ürün için sistem, sıfırdan çizilerek değil, mevcut durumdan çıkarılarak kurulur. Tasarım Sistemi Denetimi ve Kurulumu çalışmasını şu sırayla yürütüyoruz.
- Envanter: mevcut ekranlar ve bileşenler tek görünümde toplanır; tekrarlar ve eksikler işaretlenir.
- Mimari: token yapısı, bileşen katmanları, adlandırma ve sahiplik modeli ürünün gerçek ihtiyacına göre tanımlanır.
- Bileşenler: öncelikli bileşenler varyasyonları ve durumlarıyla üretilir.
- Eşleme: Figma bileşenleri ve tokenlar kod tarafındaki karşılıklarıyla ilişkilendirilir.
- Dokümantasyon ve yönetişim: kullanım kuralları yazılır, sistemde kimin karar vereceği belirlenir.
Envanter adımı çoğu zaman tek başına değerlidir, çünkü ekip ilk kez aynı işi yapan kaç farklı bileşen olduğunu görür. Sistem kurulduktan sonra korunması ayrı bir iştir: yayındaki ürünün sistemden sapıp sapmadığı Design QA ile düzenli kontrol edilir. Birden çok ekip aynı sisteme katkı veriyorsa kararların ortak çerçevede kalması için tasarım liderliği rolü gerekir.
Ne zaman yalnızca temel bileşen kütüphanesi yeterlidir? #
Şu durumlarda kapsamlı bir sistem yerine iyi kurulmuş bir bileşen kütüphanesi yeterlidir.
- Ürün tek platformda ve sınırlı sayıda ekrandan oluşuyorsa.
- Arayüze tek bir tasarımcı ve küçük bir geliştirme ekibi dokunuyorsa.
- Ürün ilk sürüm aşamasındaysa ve yönü henüz kesinleşmediyse.
- Site ya da ürün belirli bir süre için yapılıyorsa.
Bu durumda hazır bir açık kaynak bileşen kütüphanesini markanın renk ve tipografisiyle uyarlamak, sıfırdan sistem kurmaktan daha doğru bir yatırımdır. Kütüphane, ürün büyüyüp yukarıdaki belirtiler görünmeye başladığında sisteme dönüştürülür. O noktada elde çalışan bileşenler ve gerçek kullanım örnekleri olduğu için sistem varsayıma değil, ihtiyaca göre kurulur.
Kaynaklar #
- Design Systems 101, Nielsen Norman Group; tasarım sisteminin bileşenleri ve ne zaman gerektiği
