Design System’in En Büyük Düşmanı: İstisnalar
Sunday, July 12, 2026
Bir Design System’in çöküşü büyük kararlarla başlamaz.
Küçük "istisna"larla başlar. (Tırnak içinde bilerek yazdım çünkü hepimiz buna maruz kalıyoruz)
“Bu ekran biraz farklı.”
“Bu müşteriye özel.”
“Sadece bu sayfada farklı olsun.”
“Bu butonun padding’ini biraz değiştirelim.”
İlk bakışta bunların hiçbiri önemli görünmez. Hatta çoğu zaman mantıklı gerekçelere dayanır. Ancak her istisna, sistemin tutarlılığından küçük bir parça koparır.
Her istisna yeni bir standarttır
Bir Design System’in amacı, ekiplerin aynı problemi tekrar tekrar çözmesini engellemek, şirket içinde maliyeti azaltmaktır. Fakat istisnalar çoğaldıkça ekipler şu soruyu sormaya başlar:
“Burada hangisini kullanacağız?”
İşte o anda sistem, rehber olmaktan çıkar ve seçenekler listesine dönüşür.
Bir butonun üç farklı versiyonu, aynı kartın dört farklı spacing değeri veya birbirine benzeyen iki modal…
Bunların hiçbiri tek başına büyük bir sorun değildir.
Ama hepsi birlikte karar verme yükünü artırır.
İstisnaların gerçek maliyeti görünmez
Çoğu ekip istisnaların yalnızca tasarımı etkilediğini düşünür. Oysa etkisi çok daha büyüktür.
Her yeni istisna;
Geliştirilecek yeni bir component veya varyant anlamına gelir.
QA’nın test edeceği yeni bir senaryo oluşturur.
Dokümantasyonun güncellenmesini gerektirir.
Yeni ekip üyelerinin öğrenmesi gereken bir kural daha ekler.
Bakım maliyetini artırır.
Bir istisnanın maliyeti, oluşturulduğu gün değil; yıllarca sistemde yaşamaya devam ettiği sürece ortaya çıkar.
“Hayır” diyebilmek, Design System’in en önemli özelliğidir
Başarılı Design System ekipleri her talebi sisteme eklemez.
Önce şu soruyu sorarlar: Bu gerçekten yeni bir ihtiyaç mı, yoksa mevcut sistem küçük bir düzenlemeyle bunu karşılayabilir mi?
Çünkü her talebe “evet” demek, sistemi büyütür.
Her gereksiz istisnaya “hayır” demek ise sistemi güçlendirir. Design System’in amacı her senaryoyu kapsamak değildir. Amacı, ekiplerin büyük çoğunlukla aynı dili konuşmasını sağlamaktır.
Sonuç
Bir Design System’i ayakta tutan şey, yüzlerce component’e sahip olması değildir.
Onu güçlü yapan, hangi istisnaların kabul edileceğini ve hangilerinin reddedileceğini belirleyen bir denetim (governance) modelidir.
Bu, her istisnaya “hayır” demek anlamına gelmez.
Bazen mevcut bileşen gerçekten problemi çözmeyebilir. Yeni bir kullanıcı ihtiyacı ortaya çıkmış olabilir, erişilebilirlik gereksinimleri değişmiş olabilir veya ürün farklı bir kullanım senaryosuna evrilmiş olabilir. Böyle durumlarda yeni bir component veya yeni bir varyant oluşturmak doğru bir karardır.
Ancak bu kararın gerekçesi “Bence böyle daha iyi görünüyor.” olmamalıdır.
Yerine şu sorulara cevap verebilmelidir:
Mevcut bileşen hangi problemi çözemiyor?
Bu istisna hangi kullanıcı ihtiyacını karşılıyor?
Bu ihtiyacı mevcut sistem neden karşılayamıyor?
Bu değişikliği destekleyen kullanıcı araştırması, analitik veri veya iş gereksinimi var mı?
Kısacası, Design System’de istisnalar görüşlerle değil, kanıtlarla oluşturulmalıdır.
Çünkü her yeni istisna sisteme eklenen bir maliyettir. Bu maliyet ancak gerçek bir problemi çözdüğünde anlam kazanır. İyi bir Design System’in görevi her talebi kabul etmek değil, gerçekten değer üreten değişiklikleri sisteme kazandırmaktır.
