Design System Nedir, Ne Zaman Gerekir?

Bir ürün büyüdükçe ekranlar çoğalır, ekipler bölünür ve aynı soru farklı masalarda yeniden sorulur: Bu buton hangi renkte, hata mesajı nerede duracak, tablo boşken ne görünecek? Design system bu soruların cevabını bir kez verip herkesin aynı cevabı kullanmasını sağlayan yapıdır. Ama her şirketin her aşamada bir design system'e ihtiyacı yoktur. Bu yazı design system'in parçalarını, kamuya açık iki örneği ve bir şirketin ne zaman hazır olduğunu gösteren işaretleri anlatıyor.

Design system tam olarak nedir?

Nielsen Norman Group design system'i, tasarımı ölçekli biçimde yönetmek için yeniden kullanılabilir bileşenler ve kalıplar kullanan eksiksiz bir standartlar bütünü olarak tanımlar 1. Tanımdaki kritik kelime "ölçek"tir: sistem, tek bir ekranı güzelleştirmek için değil, onlarca ekranın ve birden fazla uygulamanın tutarlı kalması için vardır.

NN/g bir design system'in deposunu üç parçaya ayırır 1:

• Stil rehberi: Renk, tipografi gibi görsel kararlar, tasarım ilkeleri ve ses tonu gibi içerik kuralları.
• Bileşen kütüphanesi: Buton, form alanı, menü gibi önceden tanımlanmış öğeler; her birinin adı, açıklaması, özellikleri, durumları ve kod karşılığı.
• Kalıp kütüphanesi: Bileşenlerin bir araya gelerek oluşturduğu, tekrar kullanılabilir düzenler ve şablonlar.

Aynı kaynak, bu depoların kendi kendine yaşamadığını da vurgular: sistemin arkasında etkileşim ve görsel tasarımcılar ile geliştiricilerden, ideal olarak araştırmacı ve içerik yazarından oluşan bir ekip gerekir 1. Yani design system bir dosya değil, bir ürün gibi yönetilen bir varlıktır.

Dört yapı taşı: bileşen, token, dokümantasyon, yönetişim

Bileşenler ve durumları

Bir bileşenin tasarımı yalnız varsayılan görünümünden ibaret değildir. Odaklanma, üzerine gelme, devre dışı, yükleniyor, hata ve boş durumları da tanımlanmazsa her ekip eksik durumu kendi yorumuyla tamamlar. NN/g'nin bileşen kütüphanesi tarifinde durumların ve kod parçacıklarının açıkça yer alması bu yüzdendir 1. Boş durum ve hata durumlarının nasıl yazılacağını boş durumlar ve hata mesajları yazısında ayrıca ele aldık.

Design token'lar

Material Design 3, design token'ları tüm arayüz öğelerinin yapı taşları olarak tanımlar ve aynı token'ların tasarımda, araçlarda ve kodda kullanıldığını belirtir 5. Token'lar sayesinde "birincil eylem rengi" gibi bir karar tek bir yerde değişir ve tüm ürünlere yayılır. W3C Design Tokens Community Group, Ekim 2025'te token formatının ilk kararlı sürümünü (2025.10) topluluk raporu olarak yayımladı 6. Formatın ayrıntılarını ve katmanlı token yapısını design token nedir yazısında anlattık.

Dokümantasyon

Dokümantasyon, bir bileşenin neye benzediğini değil, ne zaman ve neden kullanılacağını anlatır. İyi bir bileşen sayfası şu soruları cevaplar: Bu bileşen hangi problemi çözer, hangi durumda başka bir bileşen tercih edilmeli, klavye ve ekran okuyucuyla nasıl çalışır, içindeki metin nasıl yazılır? NN/g stil rehberinin ses tonu ve dil önerileri gibi içerik standartlarını da kapsadığını vurgular 1. Türkçe ürünlerde bu bölüm hitap, buton fiilleri ve değişkenli metinlerdeki ekler gibi konuları içermelidir; ayrıntılar Türkçe arayüz metni rehberinde.

Yönetişim

Yönetişim, sisteme neyin gireceğine, neyin değişeceğine ve neyin kaldırılacağına kimin nasıl karar verdiğidir. GOV.UK Design System bu konuda iyi bir kamu örneğidir. Bir bileşen ya da kalıp önerisi önce iki ölçüte göre değerlendirilir: birçok ekip veya hizmet için yararlı olduğuna dair kanıt bulunmalı ve sistemde zaten var olan bir şeyi tekrar etmemelidir 3. Yayımlanmadan önce ise engelli kullanıcılar dahil temsili bir kullanıcı örneğiyle test edilmiş olması, mevcut stil ve bileşenlerle tutarlı olması ve farklı hizmetlerde, tarayıcılarda ve yardımcı teknolojilerde çalışacak kadar esnek olması beklenir 3.

GOV.UK ayrıca bileşenlere yaşam döngüsü durumu verir: tüm katkı ölçütlerini henüz karşılamayan, daha fazla test gerektiren yeni ya da büyük ölçüde değişmiş bileşenler "deneme" etiketiyle yayımlanır ve önemli ölçüde değişebilir; olgunlaşanlar "kararlı" kabul edilir 4. Bu ayrım, sistemi kullanan ekiplere hangi bileşene ne kadar güvenebileceklerini açıkça söyler.

Kamuya açık iki referans: GOV.UK ve Material

Kendi sisteminizi tasarlarken kamuya açık sistemleri incelemek, neyin nasıl belgelendiğini görmenin en hızlı yoludur. İki örnek farklı ihtiyaçları temsil eder:

• GOV.UK Design System, devlet hizmetlerinin GOV.UK ile tutarlı olmasını ve ekiplerin birbirlerinin araştırma ve deneyiminden yararlanıp aynı işi tekrar yapmamasını amaçlar 2. Stiller, bileşenler, kalıplar ve topluluk olmak üzere dört bölümden oluşur ve Government Digital Service bünyesindeki bir ekip tarafından sürdürülür 2. Özellikle kalıp bölümü, tek tek bileşenlerden çok "kullanıcının bir görevi tamamlaması" etrafında düzenlendiği için ürün ekiplerine iyi bir model sunar.
• Material Design 3, çok sayıda platformda ve markada kullanılmak üzere tasarlanmış genel amaçlı bir sistemdir; token'lar sistemin merkezinde yer alır ve tasarımdan koda aynı adlarla taşınır 5.

Bu sistemleri birebir kopyalamak yerine yapılarını incelemek daha yararlıdır: bir bileşen sayfası hangi başlıklardan oluşuyor, erişilebilirlik notları nerede, bir değişiklik nasıl duyuruluyor? Kendi ürününüze uyarlarken bu iskelet, içerikten daha değerlidir.

Ne zaman gerekir? Hazır olduğunuzu gösteren işaretler

Design system bir maliyet kalemidir ve NN/g'nin de belirttiği gibi sürekli bakım, zaman yatırımı ve yönetim desteği ister 1. Yatırımın karşılığını vermesi için tekrar eden bir problemin olması gerekir. Aşağıdaki işaretlerden birkaçı aynı anda varsa sistemleştirme zamanı gelmiş demektir:

1. Birden fazla ürün ya da platform aynı markayı taşıyor. Müşteri uygulaması, yönetim paneli ve web sitesi gibi yüzeyler ayrı ayrı tasarlanıyor ve birbirinden uzaklaşıyor.
2. Birden fazla ekip paralel çalışıyor. Aynı tarih seçiciyi ya da tabloyu iki ekip farklı biçimde yapıyor.
3. Aynı tartışma tekrar ediyor. Tasarım incelemelerinde hangi gri tonunun ya da hangi boşluk değerinin kullanılacağı her seferinde yeniden konuşuluyor.
4. Erişilebilirlik düzeltmeleri ekran ekran yapılıyor. Kontrast ya da odak görünürlüğü sorunu tek bir bileşende çözülmek yerine her ekranda ayrı ayrı düzeltiliyor.
5. Tema ihtiyacı doğdu. Karanlık mod, alt marka ya da kurumsal müşteriye özel tema gibi talepler var.
6. Sahiplenecek biri var. Sistemi sürdürecek kişi ya da ekip ve buna ayrılmış zaman belli.

Son madde diğerlerinden önemlidir. Sahibi olmayan bir sistem kısa sürede ürünün gerisinde kalır; ekipler kütüphanedeki eski bileşeni beğenmez ve yeniden kendi çözümlerini üretmeye başlar.

Ne zaman erken?

Tek bir ürün ekibinin, kullanıcıların gerçekten neye ihtiyaç duyduğunu hâlâ aradığı erken bir dönemde kapsamlı bir design system genellikle erkendir. Arayüz her hafta değişirken her bileşeni belgelemek, değişmeyecek kararlar için zaman harcamak anlamına gelir.

GOV.UK'nin katkı ölçütleri burada da yol gösterir: bir şeyin sisteme girmesi için birçok ekibin ihtiyacı olduğuna dair kanıt aranır 3. Aynı mantığı kendi ürününüze uygulayabilirsiniz. Bir çözüm üç farklı yerde tekrar etmeden onu sistemleştirmeyin. Erken dönemde yeterli olan hafif bir başlangıç şudur:

• Renk, boşluk ve yazı ölçeği için kısa bir token listesi,
• En sık kullanılan birkaç bileşen (buton, form alanı, uyarı kutusu) ve durumları,
• Her biri için bir paragraflık kullanım notu.

Bu temel, ileride sistemi büyütmek istediğinizde dağınık bir arayüzü toplamaktan çok daha kolay bir başlangıç noktası sağlar. Erken aşamadaki ürünlerde nelerin önceliklendirileceğini MVP tasarımı yazısında tartıştık.

Küçükten büyüğe: bir başlangıç planı

Sistemi bir kerede kurmaya çalışmak yerine aşamalı ilerlemek riski düşürür:

1. Envanter: Mevcut ekranlardaki renkleri, yazı boyutlarını ve bileşen çeşitlerini toplayın. Aynı işi yapan kaç farklı buton ya da uyarı kutusu olduğunu görmek, önceliği kendiliğinden belirler. Bu iş bir UX denetimi ile birlikte yapılabilir.
2. Token'lar: Envanterdeki değerleri sadeleştirip adlandırın; önce ham değerler, sonra anlam taşıyan adlar.
3. Çekirdek bileşenler: En çok kullanılan bileşenleri tüm durumlarıyla tasarlayın ve kodda aynı adla karşılık bulduklarından emin olun.
4. Dokümantasyon: Her bileşen için kullanım, kullanmama, erişilebilirlik ve içerik notlarını yazın.
5. Katkı ve sürüm kuralları: Yeni bileşen önerisinin nasıl yapılacağını, değişikliklerin nasıl duyurulacağını ve eski bileşenlerin nasıl kaldırılacağını belirleyin.
6. Benimsetme: Ekiplerin sistemi gerçekten kullanıp kullanmadığını izleyin; kullanılmayan bir bileşen, ya ihtiyaca cevap vermiyor ya da bulunamıyor demektir.

Sık yapılan hatalar

• Sistemi yalnız bir tasarım dosyası sanmak. Kod karşılığı olmayan bileşenler geliştirici tarafında yeniden yorumlanır.
• Her şeyi baştan belgelemek. Hiç kullanılmayacak bileşenler için harcanan zaman, çekirdeğin olgunlaşmasını geciktirir.
• Erişilebilirliği sonraya bırakmak. Bir bileşende çözülmeyen kontrast ya da klavye sorunu, o bileşenin kullanıldığı her ekrana kopyalanır.
• Yönetişimsiz büyümek. Herkesin istediğini eklediği bir kütüphane, bir süre sonra kendi içinde tutarsızlaşır.
• Benimsetmeyi ihmal etmek. Sistemi kurmak işin yarısıdır; ekiplerin onu kolayca bulup kullanabilmesi diğer yarısıdır.

Design system'in kapsamını, token yapısını ve geliştirici devrini nasıl ele aldığımızı design system hizmeti sayfamızda bulabilirsiniz.