İçeriğe geç
NAFRUYazılım x Geliştirme
← Blog ana sayfası

3 dk okuma

Beş kişilik ekipte tasarım sisteminin işi

Tasarım sistemi bir bürokrasi katmanı değil. Yalın ekipler için, her sprintte aynı arayüz sorununu yeniden çözmeyi durdurma yöntemi.

Furkan ÇolakDeveloper

Tam karşıdan görünen bir dizgi kasası, her gözü kendi ayrılmış metal harfleriyle özenle dolu.
"Casse de typographe, Grandjean — musée Champollion", VIGNERON, CC BY 3.0, Wikimedia Commons. 3:2 oranına kırpıldı.

“Tasarım sistemi”, 200 kişilik bir ürün organizasyonunun ihtiyacı olan, beş kişilik bir ekibin vakti olmayan bir şey gibi duyuluyor. Bu mantık tersten kurulmuş. Büyük şirketler hiç tanışmayacak yüzlerce kişiyi koordine etmek için sistem kurar. Küçük ekiplerin sisteme ihtiyacı daha ucuz bir sebepten: her sprintte aynı boşluk tartışmasını yeniden açmamak için.

Nielsen Norman Group’un yalın tasarım sistemi ekipleri üzerine araştırması sezgiye aykırı bir şey buldu: küçük, sıkı bağlı ekipler çoğu zaman büyük, merkezi ekiplerden daha iyi benimsenen sistemler üretiyor, çünkü bileşenleri kullananlarla onları inşa edenler aynı kişiler (NN/g, “Small by Design”). “Sistem ne diyor” ile “ürün gerçekte neye ihtiyaç duyuyor” arasında bir çeviri katmanı yok.

Performans tarafındaki kanıt da somut. İyi benimsenmiş bir tasarım sistemiyle çalışan ekipler, karşılaştırılabilir arayüz görevlerini sistemsiz ekiplere göre yaklaşık %34 daha hızlı tamamlıyor (Figr, “Driving Design System Adoption That Works”). Çünkü bir butonun, kartın ya da boş durumun nasıl görüneceği kararı her PR incelemesinde yeniden tartışılmak yerine bir kez, doğru şekilde verilmiş oluyor.

Bileşen kütüphanesinden önce daha az karar

Zaten tekrarladığınız kalıpları belgeleyerek başlayın: formlar, kartlar, navigasyon, boş durumlar. Bir sistemin başlangıcı budur. Tek bir ekran çıkmadan önce hazırlanmış 200 bileşenlik bir Figma kütüphanesi değil.

İlk günün hedefi kapsam değil. Her hafta biraz farklı şekilde yeniden verilen o birkaç kararı ortadan kaldırmak: Boşluk ölçeğimiz ne? Devre dışı bir buton nasıl görünür? Bir hatayı nasıl ifade ediyoruz?

Kısıtlar bir kalite mekanizması

Sınırlar tutarlılığı zorlar, tutarlılık da profesyonellik olarak okunur; özellikle her sürümden önce tam bir görsel kalite kontrolüne kimsenin vakti olmayacak kadar hızlı hareket eden küçük bir ekip için.

Bir bileşen paylaşıldığında, bir düzeltme kullanıldığı her yere yayılır. Her ekran özel yapıldığında ise aynı hata üç farklı şekilde üç kez düzeltilir, kimsenin fark etmediği dördüncü örnek ise bozuk şekilde yayında kalmaya devam eder.

Benimseme, dayatmayı geride bırakır

Vaka çalışmalarında tekrar eden bir bulgu var ve buna, sisteme ayrılmış hiçbir tasarım ya da geliştirme kadrosu olmadan yürütülen bir Storyblok kurulumu da dahil. Sistemler, tepeden dayatıldığında değil, ihtiyacı olan kişiler tarafından benimsendiğinde başarılı oluyor (Sparkbox, tasarım sistemi vaka çalışmaları). Hayatta kalmak için bir dayatmaya ihtiyaç duyan sistem, ilk teslim tarihi sıkıştığında sessizce takip edilmemeye başlayan sistemdir.

Sistemi acıyla birlikte büyütün

Belirli bir tutarsızlık size gerçek zaman kaybettirmeye başladığında token ve bileşen ekleyin. Kimsenin sizden hazırlamanızı istemediği bir lansmandan önceki düzenlilik telaşında değil.

Üç kişinin gerçekten başvurduğu yaşayan bir sistem, kimsenin açmadığı kapsamlı bir Figma dosyasından iyidir. Küçük bir ekip için bu bir lüks değil. Göndermekle yeniden karar vermek arasındaki farktır.

Önerilen yazılar

( 00-09 ) İLETİŞİM

Ne inşa ettiğinizi ve NAFRU'nun nasıl yardım edebileceğini konuşalım.

Sohbeti başlatalım.