UI kit ile tasarım sistemi arasındaki fark nedir?

UI kit hazır bileşenlerden oluşan bir koleksiyondur. Tasarım sistemi ise bu bileşenlerin yanında temel kararları, kullanım kurallarını, dokümantasyonu ve kodla eşleşmeyi de kapsar.

Küçük bir proje için tasarım sistemi gerekli mi?

Kapsamlı bir sistem gerekmeyebilir, ancak renk, tipografi ve boşluk için değişkenler ile temel bileşenleri baştan tanımlamak küçük projelerde bile ileride zaman kazandırır.

Figma değişkenleri koda nasıl aktarılır?

Değişkenler eklentiler veya Figma API aracılığıyla JSON olarak dışa aktarılabilir ve buradan CSS değişkenlerine, Tailwind temasına ya da mobil tema dosyalarına dönüştürülebilir. Basit projelerde isimleri birebir eşleyip elle aktarmak da yeterli olabilir.

Figma ile Tasarım Sistemi Kurmak: Adım Adım Rehber

Ürün büyüdükçe ekranlar çoğalır, farklı tasarımcılar farklı buton stilleri üretir ve geliştiriciler aynı bileşeni üç kez yazmaya başlar. Bu dağınıklığın ilacı bir tasarım sistemidir. Bu rehberde Figma ile tasarım sistemi kurmak için izlediğimiz adımları; değişkenlerden (variables) bileşenlere, dokümantasyondan kod tarafıyla eşleşmeye kadar anlatıyoruz.

Tasarım sistemi (design system) nedir?

Tasarım sistemi; renk, tipografi, boşluk gibi temel kararlardan, bu kararlarla inşa edilen bileşenlere ve bunların nasıl kullanılacağını anlatan kurallara kadar uzanan ortak bir dildir. Sadece bir UI kit değildir. UI kit, hazır bileşenlerden oluşan bir dosyadır; tasarım sistemi ise bu bileşenlerin neden ve nasıl kullanılacağını da tanımlar ve kodla senkron tutulur.

Katman	İçerik	Örnek
Temeller (foundations)	Renk, tipografi, boşluk, köşe yarıçapı, gölge	color/primary, space/16, radius/md
Bileşenler	Tekrar kullanılabilir arayüz parçaları	Button, Input, Card, Modal
Kalıplar (patterns)	Bileşenlerin birleştiği tipik çözümler	Form doğrulama, boş durum ekranı
Rehber	Kullanım kuralları, yapılır ve yapılmaz örnekleri	Birincil buton ekranda bir kez kullanılır

Ne zaman tasarım sistemine ihtiyaç duyarsınız?

Her proje ilk günden kapsamlı bir sistem gerektirmez. Ancak şu işaretler varsa zamanı gelmiş demektir:

Birden fazla ürün ya da platform (web, iOS, Android) aynı markayı taşıyor.
Birden fazla tasarımcı ve geliştirici aynı ürün üzerinde çalışıyor.
Aynı bileşenin farklı ekranlarda küçük farklarla tekrarlandığını görüyorsunuz.
Karanlık mod, yeni tema ya da marka güncellemesi planlanıyor.

Tek bir uygulama ve tek bir tasarımcıyla çalışan erken aşama bir girişimde bile temel değişkenleri ve birkaç çekirdek bileşeni baştan tanımlamak mantıklıdır. Bu, ileride sistemin büyümesi için sağlam bir zemin hazırlar ve ürün hızla değişirken bile ekranların birbirinden kopmasını önler. Kapsamlı dokümantasyon ve yönetişim süreçleri ise ekip büyüdükçe eklenebilir.

Adım 1: Figma variables ile temelleri tanımlayın

Figma'nın değişken (variables) özelliği, design token mantığını doğrudan tasarım dosyasına taşır. Önerdiğimiz yapı iki katmanlıdır:

Primitive (ham) değişkenler: Paletin tamamı, örneğin blue/500, gray/100. Bunlar doğrudan ekranda kullanılmaz.
Semantic (anlamsal) değişkenler: Kullanım amacını anlatan isimler, örneğin text/primary, surface/default, border/subtle. Bunlar primitive değerlere referans verir.

Bu ayrım sayesinde karanlık mod için yeni bir mode eklediğinizde yalnızca semantic katmandaki eşleşmeleri değiştirirsiniz; ekranlar otomatik güncellenir. Boşluk ve köşe yarıçapı için de sayı değişkenleri tanımlamak, geliştirici tarafında aynı değerlerin kullanılmasını kolaylaştırır. Tipografi için text style'lar oluşturun ve bunları başlık, gövde, etiket gibi rollerle adlandırın.

Adım 2: Bileşenleri auto layout ve varyantlarla kurun

Bileşenler, sistemin en görünür parçasıdır. Sağlam bir bileşen için şu prensiplere dikkat ediyoruz:

Auto layout her yerde: İçerik değiştiğinde bileşen doğru şekilde genişlemeli ya da daralmalı.
Varyantlar mantıklı eksenlerde: Örneğin Button için size (sm, md, lg), variant (primary, secondary, ghost) ve state (default, hover, pressed, disabled).
Component properties: Metin, ikon gösterme/gizleme ve ikon değişimi için boolean ve instance swap özelliklerini kullanın; böylece varyant sayısı patlamaz.
Sadece değişken kullanın: Bileşen içinde sabit renk ya da elle girilmiş boşluk değeri kalmamalı.

Küçük bileşenlerden (ikon, badge, avatar) başlayıp büyüklere (kart, liste satırı, modal) ilerlemek, iç içe kullanımda tutarlılığı korur.

Somut bir örnek verelim. Bir form alanı (Input) bileşeni tasarlarken yalnızca varsayılan görünümü çizmek yetmez. Etiket, yardımcı metin, hata mesajı, sol ve sağ ikon, devre dışı ve salt okunur durumlar, odaklanma hali ve farklı boyutlar düşünülmelidir. Bu durumların her biri ayrı ayrı çizilmek yerine; boolean özelliklerle gösterilip gizlenen katmanlar ve state ekseninde tanımlanan varyantlarla tek bir bileşende toplanır. Böylece tasarımcı bir ekranda form kurarken sağ paneldeki birkaç seçenekle ihtiyacı olan halini seçer, geliştirici de hangi durumların kodlanması gerektiğini tek bakışta görür.

Adım 3: Dosya yapısı ve adlandırma

Tasarım sistemini ürün dosyalarından ayrı bir Figma kütüphanesi olarak yayınlamak, güncellemelerin kontrollü dağıtılmasını sağlar. Sayfa düzeni için basit bir öneri:

Kapak ve sürüm notları
Foundations: renk, tipografi, boşluk, ikonlar
Components: her bileşen ya da bileşen grubu için ayrı sayfa
Patterns ve örnek ekranlar

Adlandırmada kod tarafındaki isimlerle birebir uyum hedefleyin. Figma'da "Primary Button" olan şey kodda "ButtonPrimary" ise ekipler arasında sürekli çeviri yapılır. Ortak bir sözlük, devir sürecindeki soruların önemli bir kısmını ortadan kaldırır.

Sürümleme de en az adlandırma kadar önemlidir. Kütüphanede yapılan her değişiklik yayınlandığında, bu kütüphaneyi kullanan tüm ürün dosyalarına güncelleme bildirimi gider. Büyük değişiklikleri, örneğin bir bileşenin varyant yapısını değiştirmeyi, önce bir dal (branch) üzerinde denemek ve kısa bir değişiklik notuyla yayınlamak, çalışan ekranların beklenmedik şekilde bozulmasını önler. Kod tarafında da aynı değişikliğin hangi sürümle eşleştiğini not etmek, tasarım ile yazılımın birbirinden kopmasını engeller.

Adım 4: Dokümantasyon ve geliştirici devri

Dokümante edilmemiş bir sistem kısa sürede yorum farklılıklarına açılır. Her bileşen için şunları yazmanızı öneririz:

Ne zaman kullanılır, ne zaman kullanılmaz
Durumlar ve davranışlar (yükleniyor, hata, boş)
Erişilebilirlik notları: kontrast, dokunma alanı, ekran okuyucu etiketi
Kod tarafındaki karşılığının adı

Figma'nın Dev Mode özelliği, geliştiricilerin değişken adlarını ve ölçüleri doğrudan görmesini sağlar. Web tarafında bu değişkenleri CSS değişkenlerine ya da Tailwind temasına, mobil tarafta ise SwiftUI ve Jetpack Compose tema dosyalarına aktarmak, sistemin iki dünyada da tek kaynaktan beslenmesini sağlar. Bu eşleşmeyi web yazılım geliştirme ve mobil uygulama geliştirme projelerimizde tasarımın ilk gününden planlıyoruz.

Sık yapılan hatalar

Çok erken, çok büyük başlamak: Henüz ürünün kendisi netleşmemişken yüzlerce bileşen tasarlamak. Gerçek ekranlardan çıkan ihtiyaçlarla büyütmek daha sağlıklıdır.
Sahipsiz bırakmak: Sistemi güncelleyen ve değişiklikleri onaylayan net bir sorumlu olmalı.
Detach alışkanlığı: Tasarımcıların bileşeni koparıp elle düzenlemesi, sistemin eksik bir ihtiyacı karşılamadığını gösterir; bu sinyal kütüphaneye geri taşınmalı.
Kodla senkronu unutmak: Figma'daki sistem ile koddaki bileşenler ayrıştığında sistem bir referans olmaktan çıkar.

Figma ile tasarım sistemi kurmak, değişkenlerle sağlam bir temel atmak, bileşenleri esnek kurmak ve bunları kodla aynı dili konuşacak şekilde belgelemek demektir. Doğru kurulduğunda yeni ekranlar daha hızlı tasarlanır, geliştirme daha az soruyla ilerler ve ürün her platformda tutarlı görünür.

BernSoftware olarak UI/UX tasarım projelerimizde tasarım sistemini ürünle birlikte büyütüyor, web ve mobil kod tabanıyla eşleştiriyoruz. Mevcut ürününüz için bir sistem kurmak ya da dağınık bir UI kit'i toparlamak istiyorsanız bize yazın.