Şubat ayında, altı yıldır yaşayan bir mobil uygulamayı devraldık. Önceki ekip dağılmış, dokümantasyon yok denecek kadar az. İlk iş olarak arayüz envanteri çıkardık ve saydık: uygulamada 34 farklı mavi ton, 17 farklı buton stili ve 9 farklı yazı boyutu skalası kullanılıyordu. Aynı "Kaydet" butonu bir ekranda köşeleri 4 piksel, diğerinde 12 piksel yuvarlatılmıştı. Kimse kötü niyetli değildi; sadece altı yıl boyunca her yeni özellik, bir öncekine bakılmadan tasarlanmıştı.
Bu tablo bize hiç yabancı değil. Tasarım sistemi denince akla büyük kurumların yüzlerce sayfalık kılavuzları geliyor ama asıl mesele çok daha sade: aynı kararı iki kez vermemek.
Otuz Dört Mavi Bir Günde Birikmez
Tutarsızlık dramatik bir hatayla başlamıyor. Bir tasarımcı acele bir ekranda ana maviyi göz kararı seçiyor, bir geliştirici Figma'dan rengi elle kopyalarken bir karakteri yanlış alıyor, bir kampanya için "biraz daha canlı bir mavi" isteniyor ve o mavi kalıcılaşıyor. Her adım masum; toplamı 34 ton.
Kullanıcı bu tonları tek tek fark etmez ama toplamını hisseder: uygulama "eğreti" durur, güven vermez. Asıl faturayı ise ekip öder. Devraldığımız projede basit bir renk değişikliği talebi — marka mavisinin güncellenmesi — önceki ekip tarafından üç haftalık iş olarak fiyatlandırılmış. Üç hafta! Çünkü rengin geçtiği her yer elle bulunacaktı. Tasarım sistemi olan bir projede bu, tek satırlık bir token değişikliğidir.
Token Dediğimiz Şey Renk Değil, Karardır
Sistemi kurarken ilk kat, tasarım token'ları oldu. Token kavramı kulağa teknik geliyor ama özü şu: "bu buton mavi" demek yerine "bu buton, birincil eylem rengini kullanır" demek. Renk yarın değişebilir; karar — birincil eylemin tek ve tutarlı bir rengi olduğu kararı — kalıcıdır.
Biz token'ları üç katmanda tutuyoruz: ham palet (mavi-600 gibi), anlamsal katman (birincil-eylem, hata, uyarı) ve bileşen katmanı (buton-zemin, buton-metin). Figma tarafında bunları değişkenlerle yönetiyoruz; kod tarafında aynı isimlerle tema dosyasına işliyoruz. Böylece tasarımcının Figma'da gördüğü isimle geliştiricinin kodda yazdığı isim birebir aynı oluyor. Handoff toplantılarındaki "bu hangi gri?" sorusu bu projede tarihe karıştı; abartmıyorum, sprint başına en az bir saat kazandırdı.
Aynı mantık boşluklara, köşe yarıçaplarına, gölgelere ve tipografiye uygulanıyor. 9 yazı skalasını 5 kademeli tek bir skalaya indirdik. İlginç olan şu: hiçbir kullanıcı "yazılar değişmiş" demedi ama uygulama içi memnuniyet anketinde "daha derli toplu görünüyor" yorumları kendiliğinden gelmeye başladı.
Bileşen Kütüphanesi Figma'da Bitmez, Kodda Biter
Sektörde sık gördüğümüz bir tuzak var: ekip Figma'da kusursuz bir UI kit hazırlıyor, herkes mutlu, sonra kod tarafı bu kit'i hiç yansıtmıyor. Tasarım sistemi Figma dosyası değildir; Figma dosyası sistemin sadece vitrini.
Bizim yaklaşımımızda her bileşenin iki kimliği var: Figma'daki tasarım bileşeni ve koddaki karşılığı. Butonun Figma'da üç boyutu ve dört durumu varsa, koddaki buton bileşeni de aynı üç boyutu ve dört durumu parametre olarak alır — ne eksik ne fazla. Bu eşleşmeyi sağlamak için bileşen envanterini tasarımcı ve geliştirici birlikte çıkarır. Geliştiricinin "bu varyantı kimse kullanmıyor, silelim" deme yetkisi vardır; tasarımcının da "bu durumu kodda görmüyorum, ekleyin" deme yetkisi. (Bu karşılıklı veto hakkı, kâğıt üzerinde kulağa çatışma gibi geliyor; pratikte tam tersine, iki tarafın birbirinin işine gerçekten bakmasını sağlıyor.)
Devraldığımız projede 17 buton stilini önce 6'ya, üç ay sonra 4'e indirdik. Yeni özellik geliştirme hızı ilk sprintlerde biraz düştü — bunu müşteriye baştan söylemiştik — ama üçüncü aydan itibaren ekran geliştirme süresi ortalama yüzde 40 kısaldı, çünkü ekranlar artık hazır bileşenlerle kuruluyor.
Yaşayan Bir Ürünü Durdurmadan Sisteme Geçirmek
Devraldığımız uygulama günde on binlerce kişi tarafından kullanılıyordu; "üç ay durup her şeyi baştan yazalım" seçeneği masada yoktu. Zaten hiçbir müşteriye bunu önermeyiz — büyük patlama şeklindeki geçişler bizim tecrübemizde ya yarıda kalır ya da bütçeyi ikiye katlar.
Bunun yerine kademeli bir strateji izledik. Önce token katmanını mevcut kodun altına döşedik: uygulamanın görünüşünde tek piksel değişmedi ama 34 mavi, arka planda 6 anlamsal isme bağlandı. Bu adım kullanıcıya görünmez, ekibe ise hemen değer üretir; artık en azından yeni yazılan her ekran sistemli doğuyor. İkinci adımda "dokunduğun ekranı dönüştür" kuralını koyduk: hangi ekrana özellik ya da hata düzeltmesi için giriliyorsa, o ekran sisteme taşınarak çıkılır. Üçüncü adımda ise en çok kullanılan beş ekranı — envanter verisine göre trafiğin yüzde 70'ini taşıyan ekranları — planlı şekilde elden geçirdik.
Altı ayın sonunda uygulamanın ekran bazında yüzde 80'i sisteme geçmişti ve bu süre boyunca ürün yol haritası durmadı. Kalan yüzde 20, ayda bir açılan ayar ve sözleşme sayfaları; onlar sıraya girmiş durumda ve açıkçası acele etmiyoruz.
Bu geçişin görünmeyen kahramanı da envanterin kendisiydi. Müşteriye "tasarım sistemi kuralım" dediğinizde çoğu zaman soyut bir masraf duyar; 34 mavinin ekran görüntüleriyle yan yana dizildiği tek bir sayfa gösterdiğinizde ise tartışma biter. Sorunun fotoğrafı, sorunun tarifinden her zaman daha ikna edicidir.
Beş Kişilik Ekibe Ne Kadar Sistem Gerekir?
Buraya kadar okuyup "bizim ekip üç kişi, bu bize ağır" diyenlere hak veriyorum. Tasarım sisteminin dozu ekibe göre ayarlanır. Google'ın Material Design'ı yüzlerce ürünü besliyor; sizin sisteminizin tek bir ürünü beslemesi yeterli.
Küçük ekipler için önerdiğimiz asgari paket şu kadarcık: bir renk paleti anlamsal isimlerle, tek bir yazı skalası, bir boşluk cetveli ve en çok kullanılan beş-altı bileşen. Bu kadarı bir haftada kurulur ve tutarsızlığın yüzde 80'ini engeller. Gerisi — dokümantasyon sitesi, sürümleme, katkı süreci — ürün ve ekip büyüdükçe eklenir. Sistemi büyütmenin doğru zamanı, aynı soruyu ikinci kez duyduğunuz andır: "Bizde ikincil buton nasıldı?" sorusu iki kez soruluyorsa, cevabı yazılı bir yere koymanın vakti gelmiştir.
Bir de bakım meselesi var. Sahipsiz sistem, altı ayda envanterdeki 35. mavi tonuna kavuşur. Bizim projelerimizde sistemin bir sahibi olur — çoğunlukla bir tasarımcı ve bir geliştiriciden oluşan iki kişilik bir "sistem nöbeti" — ve her sprint sonunda sisteme girmek isteyen değişiklikler bu ikilinin onayından geçer.
Elinizde yıllar içinde dağılmış bir arayüz varsa ve nereden başlayacağınızı bilmiyorsanız, ilk adım bizden bir envanter çalışması istemek olabilir; iletişim sayfamızdan yazın, mevcut uygulamanızın kaç maviye sahip olduğunu birlikte sayalım. Sonuç bazen tek başına ikna edici oluyor.