Tasarım sistemini ekibe benimsetmenin 4 yolu
Bileşen kütüphanesi kurmak kolay; kullandırmak asıl mesele.
Kütüphane kurmak yetmez
Figma’da 200 bileşen, üründe 12 farklı buton varsa sistem yok demektir. Benimsetme, keşif maliyetini düşürmektir: geliştirici “hangi buton?” diye sormadan doğru olanı kullanır. Bunu sağlayan şey dokümantasyon değil, varsayılanlardır. Varsayılan yanlışsa ekip sistemi aşar.
İlk hafta coşku, üçüncü ay sapma. Sapmayı kişisel disiplinle çözmeye çalışmak yorar. Süreç kurun: yeni ekran PR’ında sistem dışı renk varsa CI uyarır, tasarım incelemesi bu uyarıyı kapatmadan birleştirmez. Kural yazılı, araç otomatik, istisna nadir ve tarihli olsun.
Dört yol
1. Tek kaynak, iki yüzey
Token’lar kodda yaşasın, Figma bunları okusun — ya da tersi, ama tek kaynak. İki yerde elle güncellenen turuncu, üç sprintte ayrışır. Kurumsal sitede --orange bir kez tanımlıdır; kampanya rengi token’a eklenmeden sayfaya yazılmaz.
2. /kit sayfası ve gerçek örnekler
Storybook yoksa bile canlı bir kit sayfası şarttır. Tasarımdaki gibi light/dark, gerçek metin uzunluklarıyla. Sahte “Lorem” ile karar verilmiş boşluk, Türkçe başlıkta kırılır. Kit, satış değil, iç sözleşme aracıdır.
3. Katkı yolu
Geliştirici yeni bir bileşen uydurmasın diye “nasıl eklerim?” yolunu yazın. Taslak, inceleme, token, erişilebilirlik, örnek. Yol yoksa yan yol açılır. İlk üç katkıya eşlik edin; dördüncüsü kendiliğinden gelir.
4. Ölçün
Sistem dışı sınıf kullanımı, kopyalanan CSS satırı, “bir kerelik” override sayısı. Bu üç metrik düşmüyorsa kütüphane şişiyor, benimsenmiyor. Ayda bir 20 dakikalık sapma turu, büyük yeniden yazımdan ucuzdur.
Ekip ritmi
Tasarım ve yazılım aynı sprintte aynı hikâyeyi alsın. “Önce tasarla, sonra kodla” ayrımı, sistemi müzakere edilemez bir PDF’e çevirir. Kısa bakış: bu ekranda yeni token var mı, yeni bileşen var mı, yoksa düzenleme mi? Cevap “düzenleme” ise mevcut API kullanılmak zorundadır.
Yeni işe başlayan biri kit sayfasından bir form üretebiliyorsa sistem çalışıyordur. Üretemiyorsa dokümantasyon eksiktir, bileşen değil. İlk görevi “iletişim formu klonu” yapmak, onboarding’i sisteme bağlar.
İstisna defteri tutun. “Bu kampanya sayfasında H1 64px olacak” bir karar ise tarihi, sahibi ve bitiş cümlesi vardır. Bitsiz istisna, yeni varsayılan olur. Üç aydır bitmeyen istisna ya sisteme alınır ya da silinir. Bu defter Figma’da gizli bir sayfa değil, changelog’da herkesin gördüğü bir satırdır.
Tasarım QA’sını yalnızca piksel karşılaştırmasına indirgemeyin. Klavye sırası, odak halkası, 44px hedef, hareket azaltma — bunlar da sistemin parçası. “Görünüyor” ile “kullanılıyor” arasındaki fark, erişilebilirlik sprintlerini sürekli erteleyen ekiplerde birikir. Kit’te bozuk bir accordion varsa ürün sayfasında da bozuktur; önce kit’i onarın.
Satışın “bir kerelik landing” baskısı sistemi deler. Landing’i sistemin alt kümesi sayın: aynı token, aynı buton, farklı içerik. Yeni bir kahraman tipi ancak üç kampanyada tekrarlanacaksa bileşen olur. Bir kez kullanılacak sahne, istisna defterine yazılır ve kampanya bitince kaldırılır.
Sonuç
Tasarım sistemi bir ürün gibi yönetilir: sürüm, changelog, sahiplik. Benimsetme dört yoldan geçer — tek kaynak, görünür örnek, katkı yolu, sapma metriği. Dördü yoksa kütüphane raf süsüdür.
Yayın öncesi kontrol
PR şablonuna “yeni token var mı, yeni bileşen var mı, istisna defteri?” üç kutusunu ekleyin. Kutular boşken birleştirme yasağı, tartışmayı toplantıdan koda taşır. İlk ay direnç olur; üçüncü ay alışkanlık. Alışkanlık oluşunca kit sayfası güncel kalır çünkü güncel olmayan PR geri döner.
Ayın son cuma sapma turunu 20 dakikada bitirin: sistem dışı renk, kopyalanan CSS, “bir kerelik” override. Üç metrik düşmüyorsa sonraki sprintin bir hikâyesi sistem onarımıdır, yeni landing değildir. Bu sıkıcı disiplin, kütüphaneyi raftan indirir.
Tasarım incelemesini Figma yorumunda bırakmayın. Token adı, boşluk kademesi ve istisna gerekçesi PR gövdesinde durur. “Biraz kaydır” yorumu ölçülemez; “space-3 yerine space-4” ölçülür. Ölçülmeyen sapma, üç sprint sonra yeni bir evrendir.
Yeni işe başlayanı kit sayfasıyla karşılayın, slaytla değil. İlk PR’si mevcut bir bileşeni kullansın, yenisini icat etmesin. Bu kural kırılırsa sistem “referans”a döner. Referans raflarda durur; ürün kodda yaşar.
- PR şablonunda üç kutu dolu mu?
- Ay sonu sapma turu takvimde mi?
- İstisna defterinde açık madde var mı?
- Yeni gelen ilk PR’sinde yeni bileşen açtı mı?
Sahada tekrar edenler
Tasarım sistemini “güzel Figma” sanan ekipler, sprint sonunda yine özel kart çizer. Çözüm estetik değil: token adı konuşulmayan toplantıyı bitirin. İsim yoksa sapma vardır. Bu cümleyi üç kez tekrar etmek, yeni bir landing’den ucuzdur.
Tasarım sistemleri ve kurumsal tipografi ölçekleri üzerine uzman. Bileşen kütüphanesini ürün ekiplerinin günlük işine bağlayan süreçleri kuruyor.