Bir ekibin eksiksiz component library'si ve production'da çalışan üç ürünü vardı. Yeni dashboard resmî butonu import etmek yerine eski bir butonu kopyaladı. Library versiyonu provider istiyor, marketing sitesinden gelen varsayımlar taşıyor ve basit ekranı yayınlamayı zorlaştırıyordu. Ekip disiplinsiz değildi. Sistem duplication'dan pahalı hale gelmişti.
Design system maliyetini yeterli insan ve ürün yüzeyinde tekrarlanan kararlarla çıkarır. Eşik zevk değil, koordinasyon maliyetidir.
Component'tan önce ekip ve yüzey sayın
Tek uygulamada çalışan tek ürün ekibi çoğu zaman local component ve küçük token setiyle daha hızlı ilerler. Bağımsız ekipler aynı interaction'ı çözdüğünde, birkaç yüzey aynı markayı taşımak zorunda olduğunda veya accessibility ve davranış review'ın yakalayabileceğinden hızlı ayrıştığında ortak sistem değer kazanır.
Consumer'ları, release döngülerini ve tekrarlanan kararları sayın. Web sitesi, hesap alanı, iç araç ve native app yalnızca daha fazla ekran değildir. Rendering, input ve release kısıtları farklıdır. Ortak foundation işe yarayabilir, fakat aynı component implementation'ını hepsine zorlamak sahte standart üretir.
Koordinasyonun tekrar ettiği yerden başlayın. Component olabilecek her şeyin envanteriyle başlamayın.
Sistem vergi çıkardığında adoption düşer
Local code'dan daha zor anlaşılan sistem terk edilir. Belirsiz component sınırı, geçmiş kazaları taşıyan prop kombinasyonları, zayıf dokümantasyon, erişilemez default ve ayrı pazarlık isteyen release süreci sık nedenlerdir. Her exception merkez ekipten izin istiyorsa ürün ekipleri component'ı sessizce fork eder.
Görsel tamlık işlevsel boşluğu saklayabilir. Button vardır, loading, error, focus ve analytics davranışı yoktur. Form field doğru görünür, ürün validasyonunu anlatamaz. Böylece sistem görünümü standartlaştırır, davranışı her ekip yeniden kurar.
İhtiyaçtan production'a kadar geçen süreyi ölçün. Adoption bir servis sonucudur, download sayısı değil.
Governance ürün işidir
Design system ownership, prioritisation, support ve deprecation ister. Birinin contribution incelemesi, kullanım sorusunu yanıtlaması, release yayınlaması ve consumer migration yapması gerekir. Bu kapasite yoksa library donar, ürünler ilerlemeye devam eder.
Contribution bize PR gönderin anlamına gelemez. Ürün ekibinin local pattern'dan shared primitive'e giden, tekrar kanıtını içeren açık yolu olmalı. System ekibinin ürün özelindeki talebe hayır deme yetkisi bulunmalı.
Versioning yalnız görsel değil davranış değişikliğini aktarmalı. Focus düzeltmesi, DOM değişimi veya yeni default screenshot aynı görünse de consumer'ı bozabilir.
Katalogdan önce foundation kurun
En dayanıklı katman genellikle vitrinden küçüktür: color role, typography, spacing, motion, focus treatment, form semantics ve layout primitive. Bunlar her ekranı evrensel component'a zorlamadan tutarlılık sağlar.
Tekrar kanıtlandığında ve davranış tutarlılığı önemli olduğunda shared component ekleyin. Escape hatch açık olsun. Product-specific composition, core library'de numara yapmadan ortak foundation kullanabilir. Kullanılmayan denemeleri silin. Design system şirketin yaptığı her arayüzün arşivi değildir.
Bu hafta sistemin değerini test edin
Aktif ekipleri ve ürün yüzeylerini yazın. Ayrışmış tekrarlı component'ları bulun, farkın maliyetini kaydedin: defect, accessibility açığı, duplicate emek veya tutarsız müşteri davranışı. Tekrarlayan maliyeti en açık pattern'ı seçin.
Bu parçayı gerçek ürün ekibiyle kurun veya düzeltin. Kullanımı, edge case'leri ve migration'ı belgeleyin. Adoption süresini ve kalan local override'ları ölçün. Shared versiyon delivery ve bakımda local çözümü geçemiyorsa genişlemeden önce sistemi düzeltin.
Rahatsız edici cevap, tam design system'ın henüz gereksiz olması olabilir. Disiplinli component klasörü yeterli olabilir. Doğru sistem, tekrar eden koordinasyon ortak ownership'ten pahalı olduğunda başlar ve shared yol en kolay güvenilir yol kaldığı sürece yaşar.