Tasarım sistemi nedir, nasıl kurulur?

Kısaca

Tasarım sistemi, ekibinizin her ekranı sıfırdan çizmemesi için kurulan ortak bir parça kutusudur. Bir butonun hangi durumda nasıl göründüğü ve kodda hangi adla çağrıldığı tek bir yerde yazılıdır.

Nielsen Norman Group'tan Therese Fessenden tanımı şöyle yapar: tasarımı ölçekli yönetmek için yeniden kullanılabilir bileşen ve kalıplardan oluşan eksiksiz bir standartlar seti. Ben bunu daha kısa söylüyorum: aynı kararı ikinci kez vermemek.

Sistem bir Figma dosyası değildir. Figma dosyası sistemin tasarım tarafındaki kopyasıdır. Asıl sistem kodda yaşayan bileşenlerdir. Onları anlatan belgeler ve onlara bakan insanlar da sistemin parçasıdır.

• Bence küçük bir ekip için bile işe yarar, ama ilk haftada değil. Getirisi ürün büyüdükçe görünür.
• Sistemin en küçük birimi, design token denen adlandırılmış değerlerdir.

Tasarım sistemi, stil rehberi ve bileşen kütüphanesi farkı

Stil rehberi, bileşen kütüphanesi ve tasarım sistemi sık karıştırılır. Bunun nedeni, ilk ikisinin üçüncünün içinde durmasıdır. NN/g'ye göre bir tasarım sisteminin deposunda çoğu zaman bir stil rehberi, bir bileşen kütüphanesi ve bir kalıp kütüphanesi bulunur.

Parça	Ne anlatır	Örnek
Stil rehberi	Marka kuralları, ses tonu gibi içerik yönergeleri, görsel ve etkileşim standartları.	“Başlıklar Bricolage Grotesque, gövde Instrument Sans.”
Bileşen kütüphanesi	Tek tek arayüz parçaları. Her kayıtta ad, açıklama, özellikler, varsayılanıyla durumlar ve kod örneği olur.	Buton: birincil, ikincil; normal, devre dışı.
Kalıp kütüphanesi	Bileşenlerin bir araya gelip bir işi çözdüğü düzenler ve şablonlar.	Adres formu, boş liste ekranı.
Tasarım sistemi	Bunların hepsi, artı onları yöneten ekip ve kurallar.	Hangi bileşen ne zaman eklenir, kim onaylar.

NN/g, bileşen ve kalıp kütüphanesi kelimelerinin bazen birbirinin yerine kullanıldığını da not eder. Yine de aralarında fark var. Bileşen tek bir parçadır, kalıp ise parçaların bir araya gelme biçimidir.

NN/g'nin altını çizdiği bir nokta daha var: sistem, onu yöneten ekip kadar işe yarar. Bana göre bakanı olmayan bir bileşen kütüphanesi zamanla kimsenin güvenmediği bir arşive döner.

Peki ne zaman gerekir? NN/g'ye göre tasarım sistemi en çok, şirket yıllarca sürecek ve tekrar eden tasarım işi öngördüğünde değer üretir. Bir kavram kanıtı ya da erken bir prototip için tam bir sistem kısa vadede büyük olasılıkla karşılığını vermez.

Her şeyi sıfırdan kurmak da tek yol değil. NN/g üç yol sayar: hazır bir sistemi olduğu gibi almak, uyarlamak ya da kendinizinkini kurmak. Hazır sistemi almak en ucuz ve en hızlı yoldur. Uyarladıkça maliyet artar, kendinizinkini kurmak en çok zamanı ve parayı ister.

Katmanlar: token, bileşen, kalıp, sayfa

Bir tasarım sistemini katmanlar halinde düşünmek, neyin neye bağlı olduğunu görmeyi kolaylaştırır. Ben dört katman kullanıyorum ve her katman yalnızca altındakine dayanıyor.

1. Katman 1TokenAdı olan değerler: renk, boşluk, yazı boyutu, köşe yuvarlaklığı.--accent
2. Katman 2BileşenToken okuyan tek parça: buton, rozet, form alanı, kart..btn--primary
3. Katman 3KalıpBileşenlerin bir işi çözmek için birleşmesi: ödeme formu, boş durum.adres formu
4. Katman 4SayfaKalıpların gerçek içerikle yan yana dizildiği ekran./odeme

Şekil: Her katman yalnızca altındaki katmanı kullanır. Bir token değişince değişiklik yukarı doğru bütün sayfalara yayılır.

1. Token

Token, bir değere verilen addır. #FF6B3D yazmak yerine --accent yazarsınız. Design Tokens Community Group'un Ekim 2025'te yayımladığı biçim belgesi tokenı en az bir ad ile bir değerden oluşan bir çift diye tanımlar.

Aynı belge, bir tokenın başka bir tokenı göstermesine de izin verir. Buna takma ad (alias) denir. Örneğin “vurgu rengi” tokenı “turuncu 500” tokenını gösterir. Marka rengi değişince tek satır değişir. Tokenların türlerini ve dosya biçimini sözlükteki design token sayfasında ayrıca anlattım.

2. Bileşen

Bileşen, token okuyan ve tek bir işi yapan parçadır: buton, rozet, form alanı. İyi bir bileşen ham renk bilmez, yalnızca token bilir. Bu yüzden koyu bir bölüme konduğunda da doğru görünür.

Bileşen tasarlanırken en kolay atlanan şey durumlardır. Oysa kullanıcı butonu odaktayken ya da sistem yanıt beklerken de görür. Bu hallerin her biri bileşenin parçasıdır.

3. Kalıp

Kalıp, bileşenlerin bir kullanıcı işini çözmek için birleşmesidir. Etiket, alan, hata mesajı ve butonun birlikte oluşturduğu bir adres formu buna örnektir. Form kurallarını form tasarımı kalıbında topladım.

4. Sayfa

Sayfa, kalıpların gerçek içerikle bir araya geldiği yerdir. Sistemin işe yarayıp yaramadığı da burada anlaşılır. Uzun bir ürün adı ya da boş bir liste, sistemdeki boşlukları hemen gösterir.

Brad Frost'un 2016 tarihli Atomic Design kitabı benzer bir model önerir: atom, molekül, organizma, şablon ve sayfa. Frost bu aşamaların sırayla izlenecek adımlar olmadığını, birlikte düşünülen bir zihinsel model olduğunu yazar. Benim dört katmanım bu modelin sadeleştirilmiş halidir.

Tasarım sistemi nasıl kurulur: adım adım

Sıfırdan bir sistem kurmak, büyük bir tasarım projesi gibi başlamaz. Elinizdeki ürünün içinde zaten gizli bir sistem vardır, sadece dağınıktır. İlk iş onu görünür kılmaktır.

1. Envanter çıkarın. Brad Frost 2013'te buna arayüz envanteri dedi: ürünü oluşturan parçaların toplu bir listesi. Her bileşen türünün ekran görüntüsünü alıp aynı sayfada gruplarsınız. Frost'a göre amaç her örneği yakalamak değil, farklı görünen çeşitleri toplamaktır.

2. Tutarsızlıkları gösterin. Envanter bittiğinde aynı işi yapan birçok farklı butonu yan yana görürsünüz. Frost, bilinçli sapmayı bilinçsiz olandan ayırmanın önemli olduğunu yazar. Ona göre envanter, yöneticinizi ya da müşterinizi bir sisteme ikna etmeye de yarar.

3. Tokenları belirleyin. Renkleri, yazı boyutlarını, boşlukları ve köşe yuvarlaklıklarını sayın, benzer olanları birleştirin. Önce ham değerleri (ilkel tokenlar), sonra anlam taşıyan adları (anlamsal tokenlar) yazın. Kontrastı da bu aşamada kontrol edin. Bunun için kontrast hesaplayıcıyı kullanabilirsiniz.

4. En çok kullanılan bileşenle başlayın. Hepsini birden kurmayın. Envanter, hangi parçanın en sık tekrar ettiğini size gösterir. Her biri için varyantları ve durumları yazın, sonra kodlayın.

5. Dokümantasyonu bileşenin yanına yazın. NN/g'ye göre bileşen kütüphanesindeki bir kayıt ad, açıklama, özellikler, durumlar ve kod örneği içerir. Ben buna bir satır eklerim: ne zaman kullanılmaz.

6. Yönetişimi baştan kurun. Yeni bir bileşeni kim ekler, kim onaylar, eskisi nasıl kaldırılır? NN/g sistemin sürekli bakım ve gözetim istediğini yazar. Yoksa sistem eskir ve dağınıklaşır.

Ekip boyutu konusunda NN/g'nin bir önerisi var: en az bir etkileşim tasarımcısı, bir görsel tasarımcı ve bir geliştirici. Bu roller şirkette varsa ideal ekibe yarı zamanlı çalışan bir araştırmacı, bir mimar ve bir içerik yazarı da eklenir. NN/g ayrıca para ve kaynak sağlayacak bir yönetici sponsor önerir.

Küçük bir girişimde bu rollerin hepsi bir ya da iki kişide toplanır. Bu sorun değil. Önemli olan, birinin sistemin sahibi olduğunu herkesin bilmesidir.

Sistemi kurarken erişilebilirliği sonraya bırakmayın. Bir bileşen bir kez doğru kurulursa her kullanıldığı yerde doğru çalışır. WCAG ölçütlerini bileşen düzeyinde test etmek bence sayfa sayfa düzeltmekten daha ucuzdur.

Sistem işe yarıyor mu?

Kurduğunuz sistemin tuttuğunu anlamanın en kolay yolu, yeni bir ekranın nasıl yapıldığına bakmaktır. Tasarımcı yeni ekranı çoğunlukla hazır parçalardan çıkarıyorsa sistem çalışıyor demektir.

Ters işaret de kolay görülür. Geliştirici bileşeni kullanmak yerine kopyalayıp değiştiriyorsa, bileşen bir ihtiyacı karşılamıyordur. Bunu suç olarak değil, sisteme eklenecek bir istek olarak okuyun.

Ben ayda bir kodda ham renk ve ham ölçü ararım. Her bulduğum, ya eksik bir tokenı ya da sistemin dışına kaçmış bir ekranı gösterir.

Figma'dan koda

Bir tasarım sistemi ancak kodda da aynı adlarla yaşıyorsa sistemdir. Figma'da “Primary/Large” adlı bir buton, kodda BigBlueButton diye geçiyorsa ekip her gün çeviri yapıyor demektir.

Figma bu köprüyü değişkenlerle (variables) kurar. Figma'nın yardım belgesi değişkenleri, farklı tasarım özelliklerine uygulanabilen yeniden kullanılabilir değerler diye tanımlar. Aynı belge, değişkenlerin ve modların tasarım tokenlarını uygulamak için kullanılabileceğini yazar.

Modlar tema işini çözer. Bir değişkene her mod için ayrı bir değer verirsiniz, örneğin açık ve koyu tema. Kodda bunun karşılığı, aynı token adının farklı bir temada farklı değer almasıdır.

Benim akışım şöyle:

1. Figma'da token adlarını koddaki adlarla aynı yazarım. color/accent kodda --accent olur.
2. Bileşenin varyant adlarını kodun modifier adlarıyla eşlerim: Figma'da “Primary”, kodda btn--primary.
3. Geliştirici, Dev Mode'da bir öğeyi incelerken değişkenlere de erişebilir. Figma bunu ayrı bir yardım yazısında anlatır.
4. Kod tarafını tek doğruluk kaynağı yaparım. Figma kodu takip eder, tersi değil.

Son madde herkesin tercihi değil. Kimi ekipler Figma'yı esas alır. Ama kullanıcıya giden şey koddur. Figma ile kod ayrıştığında kullanıcı her zaman kodu görür, bu yüzden ben kodu esas alıyorum.

Figma, değişkenleri REST API ile okuyup yazmaya da izin verir. Belgesinde değişkenleri kod tabanıyla eşitleyen bir GitHub Action örneği var. Küçük ekiplerde buna gerek kalmayabilir. Tokenlar bir avuçsa elle eşitlemek de yeter.

Deneyin: mini bileşen seti

Aşağıdaki set üç bileşenden oluşuyor: buton, rozet ve kart. Her biri aynı token setini okuyor. Bir bileşen, bir varyant ve bir durum seçtiğinizde, bileşen kütüphanesindeki bir kaydın nasıl okunacağını görürsünüz.

Deneyin: mini bileşen seti

Ödemeye geç

Kod: class="btn btn--primary"

Buton, birincil, normal. Ekrandaki ana eylem içindir. Bir ekranda tek birincil buton olur, kullanıcı neye basacağını aramaz.

Normal durumda buton basılmaya hazırdır. Etiket, basınca ne olacağını söyler.

Bu sitenin kendi bileşenleriyle kurulmuş küçük bir set. Bileşen, varyant ve durum seçin: önizleme, kod satırı ve kullanım notu birlikte değişir. Rozet tıklanmadığı için onun durum seçenekleri kapalıdır.

Demodaki kullanım notlarının tamamı aşağıdaki tabloda. Bileşen kütüphanesindeki her kayıt, en az bu kadarını söylemeli.

Bileşen	Varyant	Ne zaman kullanılır
Buton	Birincil	Ekrandaki ana eylem. Bir ekranda tek tane olur.
Buton	İkincil	Ana eylemin yanındaki ikinci seçenek. Daha sakin görünür.
Buton	Uyarı	Geri dönüşü zor eylem. Etiket ne olacağını açıkça yazar.
Rozet	Birincil	Tamamlanmış ya da olumlu durum, örneğin “Kargoda”.
Rozet	İkincil	Nötr etiket, örneğin “Taslak”.
Rozet	Uyarı	Kullanıcıdan adım bekleyen durum, örneğin “Ödeme bekliyor”.
Kart	Birincil	Öne çıkan tek konu. Dolgu rengi önce okunmasını sağlar.
Kart	İkincil	Liste içindeki sıradan kayıt.
Kart	Uyarı	Kullanıcıdan bir adım bekleyen içerik.

Durumlar da varyantlar kadar önemlidir. Örneğin odak halkası, klavye kullanıcısına sayfada nerede olduğunu gösterir. Yükleniyor durumu da ikinci basışı engeller, böylece aynı istek iki kez gitmez.

W3C'nin ARIA uygulama kılavuzu (APG), basılı ve basılı değil diye iki hali olan aç/kapa butonları için aria-pressed özelliğini önerir. Kılavuza göre bu butonun etiketi durum değişince değişmemelidir. Demodaki seçim butonları da bu kurala uyar.

Sık hatalar

Sistemi kütüphane sanmak. Bir Figma dosyası ya da bir npm paketi yayımlamak sistem kurmak değildir. Kimin bakacağı belli değilse kütüphane zamanla eskir.

Envanter çıkarmadan çizmeye başlamak. Mevcut ürünü görmeden çizilen yeni bileşenler, eski butonların yanına bir yenisini ekler. Önce neyin olduğunu sayın.

Yalnızca normal hali tasarlamak. Odak, devre dışı, hata ve yükleniyor halleri çizilmezse geliştirici onları kendisi uydurur. Her ekranda başka bir yükleniyor işareti çıkar.

Ham değerleri bileşene gömmek. Butonun içinde #FF6B3D yazıyorsa koyu tema ya da marka değişikliği her bileşende tek tek düzeltme gerektirir. Bileşen yalnızca anlamsal tokenı okumalı.

Tokenları renge göre adlandırmak. --orange adlı bir token, marka mora dönünce yalan söylemeye başlar. Anlamsal tokenlar işlevi anlatır: --accent, --text-muted.

Her isteği bileşen yapmak. Tek bir ekranda bir kez kullanılan şey bileşen değildir. Bir parçayı en az iki yerde kullanmadan sisteme almam.

Dokümantasyonu ayrı bir siteye gömmek. Kimsenin açmadığı bir belge sitesi, yazılmamış belgeden farksızdır. Kural, bileşenin kodunun hemen yanında durmalı.

Rengi tek ipucu yapmak. Kırmızı rozet tek başına “sorun var” demez. Renkleri ayırt etmekte zorlanan biri yazıya bakar, ekran okuyucu da yazıyı okur. Durumu her zaman kelimeyle de söyleyin.

Benim notum

Okuduğunuz bu sayfa da bir tasarım sistemiyle kuruldu. ux.center'ın sistemi dört katmandan oluşur ve her katman yalnızca altındakine dayanır: tokenlar, bileşenler, bölümler ve sayfa.

Tokenlar tek bir dosyada iki kat halinde durur. İlk katta ham değerler var, örneğin krem, mürekkep ve turuncu tonları. İkinci katta bileşenlerin okuduğu anlamsal adlar var: --bg, --text, --accent. Koyu ya da renkli bir bölüm (mood) yalnızca bu ikinci katı değiştirir.

Bileşenler için kuralım basit: her bileşenin bir CSS dosyası ve bir Python fonksiyonu olur. Bugün 24 bileşen dosyası var, demodaki buton, rozet ve kart da bunlardan. Hiçbiri ham renk bilmez, bu yüzden koyu bir bölüme konduklarında da çalışırlar.

Bölümler bunların üstüne kurulur. Ana sayfadaki her bölüm kendi işaretleme modülünü, stil dosyasını ve gerekiyorsa hareket betiğini taşır. Build betiği hepsini sırayla tek bir CSS ve tek bir JS dosyasında toplar.

Benim için en değerli parça bir test aracı. Görünümü değiştirmemesi gereken her düzenlemeden önce ve sonra, masaüstünde ve mobilde her öğenin stilini ve kutusunu kaydediyorum. İki kayıt birebir aynı çıkmadan işi bitmiş saymıyorum. Bir sistemi korumak, onu kurmaktan daha çok emek istiyor.

Ürününüz için böyle bir sistemi kurmak ya da var olanı koda taşımak isterseniz, Tasarla & Yayınla Sprinti tam bu iş için. Tasarımı da kodu da reponuza teslim ediyorum.