Kurumsal Design System Nasıl Kurulur? Governance, Token ve Component Yönetimi

Design system yalnız Figma içinde oluşturulmuş buton ve form kütüphanesi değildir. Tasarım kararlarını kod bileşenleri, design token’lar, erişilebilirlik standartları ve kullanım kurallarıyla birleştiren yaşayan ürün altyapısıdır.

Kurumsal yapılarda asıl zorluk ilk component setini oluşturmak değil; farklı ürün ekiplerinin sistemi tutarlı biçimde kullanmasını, değişikliklerin kontrollü yayımlanmasını ve tasarım-kod eşleşmesinin korunmasını sağlamaktır.

Design System Kapsamını Belirleyin

Sistem hangi ürünleri, markaları ve platformları kapsayacak? Web, iOS ve Android arasında ortak token yapısı kullanılabilirken component implementasyonları platform bazında değişebilir.

Design Token Yapısı

Renk, spacing, typography, radius ve shadow gibi kararların doğrudan sabit değerler yerine semantic token olarak tanımlanması theme ve marka varyasyonlarını yönetmeyi kolaylaştırır.

Component API Tasarımı

Component’in yalnız görsel varyantları değil state, validation, disabled, loading ve accessibility davranışları da açık sözleşmeyle tanımlanmalıdır.

Figma ile Kodun Eşleşmesi

Tasarım kütüphanesindeki component isimleri ve varyant yapısı frontend component API’siyle mümkün olduğunca paralel tutulmalıdır.

Accessibility

Keyboard navigation, focus state, contrast ve screen reader davranışı component seviyesinde çözülürse tüm ürünlerde tekrar tekrar ele alınması gerekmez.

Dokümantasyon

• Ne zaman kullanılmalı?
• Ne zaman kullanılmamalı?
• Props ve varyantlar
• Örnek kullanım
• Accessibility notları
• İçerik kuralları

Versioning

Breaking component değişiklikleri ürün ekiplerini bozabilir. Semantic versioning veya kontrollü release politikası uygulanmalıdır.

Governance Modeli

Yeni component talebini kimin değerlendireceği, contribution süreci ve hangi ekibin design system sahipliğini taşıdığı açık olmalıdır.

UX Kararını Veriye Nasıl Bağlamalı?

Kurumsal Design System Nasıl Kurulur? Governance, Token ve Component Yönetimi konusu değerlendirilirken Design System Kapsamını Belirleyin, Design Token Yapısı ve Component API Tasarımı yalnız tasarım tercihi olarak ele alınmamalıdır. Her kritik arayüz kararının hangi kullanıcı problemine karşılık geldiği ve hangi davranış metriğiyle doğrulanacağı belirlenmelidir. Örneğin bir butonun rengini değiştirmek tek başına UX iyileştirmesi değildir; kullanıcının görevi daha kolay fark etmesi, daha hızlı tamamlaması veya daha az hata yapması ölçülebilir sonuç üretir.

Nicel veri ile nitel araştırmanın birlikte kullanılması önemlidir. Funnel veya event analizi kullanıcının hangi adımda kaybolduğunu gösterebilir; görüşme ve usability test ise neden kaybolduğuna ilişkin bağlam sağlar. Değişiklik sonrasında aynı metriklerin yeniden ölçülmesi tasarım kararını varsayımdan çıkarıp doğrulanabilir ürün kararına dönüştürür. Bu nedenle UX backlog’unda yalnız ekran veya component adı değil problem, hipotez, hedef kullanıcı, başarı metriği ve acceptance criteria birlikte tutulmalıdır.

Uygulama ve Ölçüm Kontrol Listesi

• Kritik kullanıcı görevi tanımlandı mı?
• Mevcut davranış için baseline veri var mı?
• Mobil ve masaüstü senaryoları ayrı test edildi mi?
• Hata ve empty-state durumları tasarlandı mı?
• Erişilebilirlik kontrolleri yapıldı mı?
• Değişiklik sonrası başarı metriği belirlendi mi?
• Kullanıcı geri bildirimi ürün backlog’una bağlandı mı?

Kritik kullanıcı akışlarında performans ve teknik davranış da UX’in parçasıdır. Yavaş API cevabı, form submit sonrasında belirsiz loading state, veri kaybı veya mobil klavyenin alanı kapatması tasarım dosyasında görünmese bile gerçek kullanıcı deneyimini bozar. Bu nedenle frontend, backend, analytics ve tasarım ekipleri aynı kullanıcı senaryosunu uçtan uca değerlendirmelidir.

Araştırma, Hipotez ve İterasyon Döngüsü

Kurumsal Design System Nasıl Kurulur? Governance, Token ve Component Yönetimi kapsamında yapılan bir UX değişikliği mümkün olduğunca açık bir hipotezle başlamalıdır. Örneğin “kullanıcı bu ekranı beğenmiyor” yerine “Design System Kapsamını Belirleyin aşamasındaki belirsizlik görev tamamlama oranını düşürüyor” gibi test edilebilir bir problem tanımı yapılabilir. Hipotezin dayanağı analytics verisi, kullanıcı görüşmesi, destek kaydı, usability test veya gözlemlenen operasyon problemi olabilir. Böylece ekip çözümü doğrudan varsaymak yerine önce problemi kanıtlamaya çalışır.

Sonraki aşamada Design Token Yapısı ve Component API Tasarımı için hedef davranış tanımlanmalıdır. Task completion rate, süre, hata oranı, funnel geçişi, form abandonment veya kullanıcı düzeltme sayısı gibi metrikler uygun bağlama göre kullanılabilir. Yeni tasarım yayınlandıktan sonra aynı metriklerin önceki baseline ile karşılaştırılması gerekir. Sonuç beklenen yönde değilse tasarım kararı savunulmak yerine hipotez yeniden değerlendirilmelidir.

UX optimizasyonunun sürdürülebilir olması için araştırma çıktıları tek seferlik sunumlarda kalmamalıdır. Problem, kanıt, önerilen çözüm, kullanıcı segmenti, başarı metriği ve sonuç aynı backlog kaydında izlenebilir olduğunda ekip zaman içinde hangi tasarım kararlarının gerçekten işe yaradığını görebilir. Bu yapı UX çalışmasını estetik revizyon sürecinden çıkarıp ölçülebilir ürün geliştirme döngüsüne dönüştürür.

Sıkça Sorulan Sorular

UI kit ile design system aynı şey midir?

Hayır. UI kit görsel bileşen setidir; design system kod, kural, token, dokümantasyon ve governance içerir.

Design token ne işe yarar?

Görsel kararları semantic ve yeniden kullanılabilir değişkenlere dönüştürür.

Her ürün ekibi kendi componentini eklemeli mi?

Contribution yapılabilir ancak merkezi review ve governance duplicate component oluşmasını engeller.

Design system tamamlanır mı?

Genellikle hayır. Ürünlerle birlikte gelişen yaşayan bir sistemdir.

İlgili İçerikler

• Design System + Component Uyum + UI Kütüphanelerinin Evrimi
• AI Destekli Web Deneyimi: Akıllı Arama, RAG ve Kişiselleştirme
• API-First Geliştirme: Backend’i Ayrıştırmak, Uygulamayı Çoklu Kanal Yapmak