Tasarım Sistemi Neden ve Ne Zaman Gerekli?

Yanlış soru: "kuralım mı?"

Bana gelen sorulardan biri neredeyse hep aynı cümleyle başlıyor: "Bir tasarım sistemi kurmalı mıyız?" Bu sorunun doğru cevabı evet ya da hayır değil; "ne zaman ve ne kadarı?". Çünkü tasarım sistemi bir ürün değil, bir yatırımdır. Bugün ödediğin bir bedelin karşılığında yarınki her değişikliği ucuzlatır. Yatırımın mantıklı olup olmadığı da tamamen ürünün hangi aşamada olduğuna bağlıdır.

Bu yazıda uygulama tarafına girmiyorum; karar aşamasını konuşuyoruz. Hangi sinyaller "artık gerekli" der, ne zaman erkendir, maliyet ve getiri nasıl tartılır. Token'ları tasarımdan koda taşıma ve tutarlılığı production'da koruma pratiğini tasarım sisteminden production'a tutarlılık yazısında adım adım anlattım; burası ona gelmeden önceki durak.

Aslında neyi satın alıyorsun?

Tasarım sistemini "güzel bir bileşen kütüphanesi" sanmak en pahalı yanılgı. Aldığın şey bileşenler değil, üç somut kazanım:

• Karar tekrarının ortadan kalkması. Her yeni ekranda "bu boşluk kaç piksel, bu buton hangi ton?" sorusunu yeniden cevaplamazsın. Karar bir kez verilir, sonsuz kez kullanılır.
• Değişimin ucuzlaması. Marka rengi, yarıçap ya da tipografi değiştiğinde tek yerden dönersin; ürün genelinde otomatik yayılır.
• Kalite tabanının yükselmesi. Erişilebilir odak halkası, yeterli kontrast, tutarlı hata durumu bileşenin içine gömülüdür; yeni ekran doğduğu anda bunlara sahip olur.

Dikkat: bu kazanımların üçü de tekrar varsa değerlidir. Tekrarın olmadığı yerde sistem, kullanılmayan bir soyutlamadır.

Erken kurmanın gerçek maliyeti

Bedelin "kurulum süresi" olduğu sanılır. Asıl maliyet daha sinsidir:

1. Yanlış soyutlama borcu. Ürün henüz oturmamışken çıkardığın bileşen API'si üç ay sonra ihtiyaca uymaz. Yanlış soyutlamayı sökmek, hiç soyutlamamış olmaktan pahalıdır.
2. Hız kaybı. Erken aşamada en değerli şey öğrenme hızıdır. Her denemeyi "önce sisteme ekleyelim" disiplininden geçirmek, denemeyi yavaşlatır.
3. Bakım yükü. Dokümantasyon, sürümleme, görsel testler — hepsi süregelen emek ister. Kullanan iki ekran varsa bu emek boşa gider.
4. Yanlış güven. "Bizim sistemimiz var" cümlesi, aslında yalnızca bir renk paleti dosyası için söylendiğinde kimse gerçek tutarsızlığı sorgulamaz.

Benim ölçüm şu: sistem, çözdüğü sorundan küçük olmalı. Sorun henüz yoksa sistem fazlalıktır.

"Artık gerekli" diyen sinyaller

Karar için takvim değil sinyal kullanıyorum. Aşağıdakilerden üç ya da daha fazlası doğruysa iş gecikmiş demektir.

Üründe görünen sinyaller

• Aynı işi yapan bileşenin birden çok sürümü dolaşıyor: üç farklı buton, iki farklı modal.
• Aynı grinin beş komşusu var ve hiçbiri kasıtlı değil.
• Boşluklar göz kararı: 14, 16, 18, 20 piksel yan yana yaşıyor.
• Aynı hata durumu iki ekranda farklı görünüyor ve farklı dille konuşuyor.
• Yeni ekranlar eskilerin yanında "başka bir ürün" gibi duruyor.

Ekipte görünen sinyaller

• Basit bir görsel değişiklik birden çok dosyada arama yapmayı gerektiriyor.
• Yeni katılan biri "bunu nereden kopyalayayım?" diye soruyor; kaynak kişiye bağlı.
• Tasarım ile canlı ürün arasında sürekli küçük farklar konuşuluyor.
• Aynı soru tekrar tekrar gündeme geliyor: "bu durumda hangi bileşeni kullanıyoruz?"
• Aynı arayüz yüzeyine aynı hafta birden fazla el değiyor.

Son madde tek başına belirleyici olabilir. Tasarım sistemi büyük ölçüde bir koordinasyon aracıdır; koordine edilecek kimse yoksa değeri düşer.

Ölçekten gelen sinyaller

• Ekran sayısı elinle sayamayacağın kadar arttı.
• Birden çok yüzey var: tanıtım sitesi, uygulama, yönetim paneli, e-posta şablonları.
• Tema ihtiyacı doğdu: açık/koyu mod, beyaz etiket, marka varyantı.
• Ürün en az bir yıl daha yaşayacak ve üzerine düzenli özellik eklenecek.

Ne zaman erken, ne zaman gereksiz?

Dürüst olmak gerekirse çoğu proje tasarım sistemi olmadan yaşar ve biter. Şu durumlarda kurmam:

• Tek yüzeyli, kısa ömürlü işler: kampanya sitesi, etkinlik mikro sitesi, tek sayfalık iniş sayfası.
• Ürün-pazar uyumu aranırken: haftalık olarak ekran çöpe gidiyorsa soyutlama da onunla gider.
• Tek kişilik ve kısa süreli işler: tutarlılığı kafandaki tek kaynak zaten sağlıyorsa.
• Hazır bir temel işi görüyorsa: olgun bir bileşen kütüphanesinin üzerine ince bir marka katmanı geçirmek, sıfırdan sistem kurmaktan çoğu zaman daha akıllıcadır.

Son madde önemli: "tasarım sistemi kurmak" ile "her şeyi sıfırdan yazmak" aynı şey değil. Hazır bir temelin üzerine token katmanı geçirmek, kararların çoğunu satın almak demektir.

MVP'de ne yapmalı: sistemin tohumu

Erken aşamada tam sistem kurmam ama hiçbir şey yapmamak da hata. Sonradan geçişi mümkün kılan, maliyeti neredeyse sıfır olan bir çekirdek bırakırım:

• Kapalı ölçekler. Renk, boşluk ve tipografi için sınırlı bir liste; ara değer üretmek serbest değil.
• Anlamsal isimlendirme. accent, surface, ink gibi amaca göre adlar; ham renk adı değil.
• Tek kaynak dosyası. Değerler tek yerde tanımlı; bileşenler ham değer yazmıyor.
• Erişilebilir varsayılanlar. Odak görünürlüğü ve kontrast eşiği baştan garanti; sonradan eklenmesi en pahalı iş budur. Temellerini erişilebilirlik yazısında topladım.

Bu çekirdek bir "sistem" değildir; ama sistem gerektiği anlaşıldığında geçişi haftalar yerine günlere indirir. Tohumu ekmek ucuz, ağacı sonradan dikmek pahalıdır.

Küçük ekip mi, büyüyen ürün mü?

İki uçta karar farklı işler.

Tek kişi ya da iki kişilik ekip: Tutarlılık kafada ve tek bir stil dosyasında tutulabilir. Burada tam sistem değil disiplin gerekir: kapalı ölçekler, birkaç temel bileşen, kısa bir "yapma" listesi. Doküman yerine kodun kendisi kaynak olur.

Büyüyen ürün ve çok kişi: Artık iletişim maliyeti kod maliyetini geçer. Bir kararı yirmi kez anlatmak yerine bir kez bileşene gömmek gerekir. Dokümantasyon, sürümleme ve görsel regresyon testleri de yatırımın parçası olur.

Eşiği belirleyen şey kişi sayısından çok eşzamanlı dokunuş sayısıdır: aynı arayüz yüzeyine aynı hafta kaç farklı el değiyor?

Getiriyi nasıl ölçersin?

Tasarım sistemi "iyi hissettirdiği" için değil, ölçülebilir şeyleri iyileştirdiği için savunulmalı. Kurmadan önce bugünkü değerleri not al, birkaç ay sonra karşılaştır:

• Standart bir ekranın tasarımdan yayına geçme süresi.
• Bir görsel değişikliğin kaç dosyaya dokunduğu.
• Kod incelemesinde açılan "bu buton neden farklı?" tipli yorumların sayısı.
• Erişilebilirlik denetiminde tekrar eden bulguların sayısı.
• Yeni katılan birinin ilk ekranını tek başına çıkarma süresi.

Bu beş ölçüt iyileşmiyorsa kurduğun şey bir sistem değil, bir klasördür.

Karar rehberi: altı soru

Kendine dürüstçe cevapla:

1. Aynı arayüz parçasını son ay içinde kaç kez yeniden yazdın?
2. Ürün önümüzdeki bir yıl boyunca yaşayacak ve büyüyecek mi?
3. Aynı yüzeye kaç kişi dokunuyor?
4. Birden çok yüzey ya da tema ihtiyacı var mı?
5. Tasarım kararları hâlâ değişiyor mu, yoksa oturdu mu?
6. Sisteme kim bakacak? Sahibi belli mi?

İlk üç soruya "çok/evet" diyorsan sistem gecikmiş demektir. Beşinci soruda "hâlâ değişiyor" diyorsan çekirdekle yetin. Altıncı soruya cevabın yoksa hiç kurma: sahipsiz sistem altı ayda terk edilir, geriye yalnızca bakım borcu kalır.

Kademeli kur: hepsi ya da hiçbiri değil

Kararı verdiysen bile tek hamlede tam sistem kurmak zorunda değilsin. Sıralamam şu:

1. Token katmanı. Renk, tipografi, boşluk, yarıçap, gölge, hareket. En yüksek getiri burada.
2. En sık kullanılan beş bileşen. Buton, form alanı, kart, bildirim, modal. Gerisi bekler.
3. Desenler. Form düzeni, boş durum, yükleniyor durumu, hata durumu.
4. Doküman ve testler. Sistem gerçekten kullanılmaya başladıktan sonra.

Her adımı, bir öncekinin gerçekten kullanıldığını görmeden atmam. Kullanılmayan katmanı büyütmek, sistemlerin en yaygın ölüm sebebi.

Özet

• Tasarım sistemi bir ürün değil; tekrar eden kararları ucuzlatan bir yatırımdır.
• Erken kurmanın maliyeti yanlış soyutlama, hız kaybı ve sahipsiz bakım yüküdür.
• Karar için takvim değil sinyal kullan: tekrar eden bileşenler, çoğalan eller, birden çok yüzey.
• MVP'de tam sistem değil çekirdek kur: kapalı ölçekler, anlamsal adlar, tek kaynak, erişilebilir varsayılanlar.
• Getiriyi ölç; iyileşmiyorsa sistemi değil yaklaşımı sorgula.
• Kurarken kademe kademe ilerle; token katmanından başla.

Ürününün hangi aşamada olduğundan emin değilsen mevcut arayüzüne birlikte bakıp "şimdi mi, henüz değil mi?" sorusunu netleştirebiliriz. Cevap "henüz değil" ise bunu da açıkça söylerim. Tasarım sistemi kurulumu yaklaşımıma göz atabilir ya da bir proje konuşmak için yazabilirsin.