Tasarım Sistemi Nasıl Kurulur? İlk Üç Ekrandan Bileşen Kütüphanesine

Tasarım sistemi, bir ürünün arayüzünde tekrar eden her parçanın (renk, yazı tipi, boşluk, buton, form alanı) bir kez tanımlanıp her yerde aynı biçimde kullanılması demektir. Büyük bir kütüphane kurmakla başlamaz; ilk üç ekranda alınan küçük kararlarla başlar. Bu yazıda nereden başlanacağını, hangi sırayla ilerlenmesi gerektiğini ve hangi hatalardan kaçınılacağını anlatıyoruz.

Tasarım sistemi tam olarak nedir, stil rehberinden farkı ne?

Stil rehberi bir belgedir; tasarım sistemi ise hem tasarım dosyasında hem kodda yaşayan bileşenlerin bütünüdür. Rehber "ana renk mavidir" der. Sistem ise o mavinin tasarım aracında ve kodda aynı adla bulunmasını, değiştiğinde ikisinin birlikte güncellenmesini sağlar.

Bir tasarım sistemi genellikle üç katmandan oluşur:

1. Token'lar: Renk, yazı boyutu, boşluk ve köşe yuvarlaklığı gibi en küçük kararların adlandırılmış değerleri. Tasarım token'ı, "16 piksel" yerine "orta-boşluk" demenizi sağlayan isimdir.
2. Bileşenler: Token'lardan yapılan buton, giriş alanı, kart, açılır menü gibi hazır parçalar.
3. Kalıplar (pattern): Bileşenlerin birlikte kullanım biçimi; örneğin giriş formu, arama çubuğu ve sonuç listesi, tablo ile filtre çubuğu.

Tasarım sistemine ne zaman ihtiyaç duyulur?

Aynı butonun üç ekranda üç farklı görünmesi ya da yeni bir ekranın her seferinde sıfırdan çizilmesi, ihtiyacın başladığını gösterir. Ekip büyüdükçe bu belirti hızla pahalılaşır; çünkü her tasarımcı ve geliştirici küçük farklarla kendi sürümünü üretir.

İlk sürümünü çıkarmaya hazırlanan bir girişimseniz önce MVP nasıl geliştirilir yazımıza bakın; tasarım sistemini ürün fikri doğrulanmadan büyütmek erken yatırımdır.

Nereden başlanır? İlk üç ekran kuralı

En sağlam başlangıç, ürünün en kritik üç ekranını tasarlayıp tekrar eden her şeyi listelemektir. Sistemi boşlukta, "belki lazım olur" diye kurmak yerine gerçek ekranlardan türetmek, hiç kullanılmayacak bileşenlerin üretilmesini engeller.

Pratikte sıra şöyle ilerler:

1. Envanter çıkarın. Mevcut ürün ya da ilk taslaklardaki tüm buton, renk ve yazı boyutlarının ekran görüntüsünü yan yana koyun. Dağılmış arayüzlerde birbirine çok yakın onlarca gri ton çıkması olağandır; bu fark, sistemin neden gerektiğini herkese gösterir.
2. Renk ve tipografiyi daraltın. Bir ana renk, bir vurgu rengi, birkaç nötr ton ve durum renkleri (başarı, uyarı, hata) yeterlidir. Yazı için en fazla bir yazı tipi ailesi ve 5–6 boyut tanımlayın.
3. Boşluk ölçeği seçin. 4 ya da 8 piksellik katlar (4, 8, 16, 24, 32) gibi sınırlı bir ölçek, "bu ne kadar boşluk olmalı" tartışmasını bitirir.
4. Önce 6–8 bileşen çizin. Buton, metin alanı, seçim kutusu, kart, modal pencere, bildirim, sekme ve tablo satırı çoğu ürünün ilk ihtiyacını karşılar.
5. Kodda karşılığını aynı hafta yazın. Tasarımda var olup kodda olmayan bileşen, birkaç hafta içinde kopyalanıp bozulur.

Token'lar neden bileşenlerden önce gelir?

Token'lar, sistemin değişiklik maliyetini belirler: marka rengini değiştirmek tek bir değeri güncellemek mi olacak, yoksa yüzlerce dosyayı elle düzeltmek mi? Token yoksa ikincisi olur.

İki seviyeli adlandırma iyi çalışır. Ham değerler (`mavi-600` gibi) bir palet olarak durur; anlam taşıyan adlar (`buton-arkaplan`, `metin-ikincil`) o palete işaret eder. Karanlık mod ya da ikinci bir marka eklenirken yalnızca ikinci katman yeniden eşlenir, bileşenlere dokunulmaz.

Renk seçerken kontrast oranını baştan kontrol edin. WCAG (Web İçeriği Erişilebilirlik Yönergeleri) AA düzeyi, normal metin için en az 4,5:1 kontrast ister. Bu kontrolü token seviyesinde yapmak, her ekranda ayrı ayrı yapmaktan çok daha ucuzdur.

Bileşenleri tasarlarken hangi durumları unutmamak gerekir?

Bir bileşen yalnızca "normal" haliyle tamamlanmış sayılmaz; ürünü amatör gösteren çoğu şey eksik durumlardır. Her etkileşimli bileşen için şu durumları baştan tanımlayın:

Odak durumu (klavyeyle gezinirken seçili öğenin görünür çerçevesi) özellikle sık atlanır. Fare kullanmayan kullanıcı için bu çerçeve olmadan form kullanılamaz hale gelir.

Sistemi ayakta tutmak: sahiplik ve sürümleme

Tasarım sistemleri çoğunlukla ilk aylarda değil, ilk yıldaki ihmalde çöker. Birisi "ufak bir istisna" ekler, bir diğeri kopya bileşen üretir ve sistem fark edilmeden dağılır.

Bunu önlemek için üç küçük kural yeterlidir: sistemin belli bir sorumlusu olsun, yeni bileşen eklemek için kısa bir gerekçe istensin ve değişiklikler bir sürüm notuyla duyurulsun. Büyük bir ekip olmasanız da bu disiplin, ürün büyüdükçe kendini fazlasıyla amorti eder.

Hazır kütüphane mi, kendi sistemimiz mi?

Çoğu ilk ürün için hazır bir bileşen kütüphanesini markaya göre özelleştirmek en hızlı yoldur; sıfırdan sistem ise ürün oturduktan sonra anlamlıdır. Karar verirken şu sorular yol gösterir:

• Ürünün görsel kimliği rakiplerden belirgin biçimde ayrışmak zorunda mı?
• Erişilebilirlik ve klavye desteği hazır kütüphanede zaten çözülmüş mü?
• Ekipte sistemin bakımını yapacak biri var mı?
• Web ve mobil aynı bileşen mantığını paylaşacak mı?

Maliyeti belirleyen kalemler (kapsam, bileşen sayısı, platform sayısı) için yazılım projesi maliyeti rehberimize bakabilirsiniz. Sistemin gerçek bir üründe nasıl uygulandığını görmek isterseniz Academy360 projemizi inceleyin. Kendi ürününüz için bir başlangıç noktası arıyorsanız bizimle iletişime geçin.

Tasarım sistemi kurarken en sık yapılan hatalar nelerdir?

• Her şeyi baştan kurmak: Kırk bileşenlik kütüphane çizilir, dokuzu kullanılır. Gerçek ekran ihtiyacı olmadan bileşen eklemeyin.
• Yalnızca tasarım aracında yaşatmak: Kodda karşılığı olmayan sistem, belge olmaktan öteye geçmez.
• Durumları atlamak: Hata, boş ve yükleniyor halleri sonradan eklenince bileşenin yapısı yeniden çizilmek zorunda kalır.
• Adlandırmayı görünüşe bağlamak: `kirmizi-buton` yerine `tehlike-buton` demek, renk değiştiğinde adın yalan olmasını önler.
• Sahipsiz bırakmak: Sorumlusu olmayan sistem birkaç ayda dağılır.