Design System (Tasarım Sistemi) Nedir? Kurumsal Web Projelerinde Neden Şart?

Kurumsal bir web projesinde üç ekip aynı anda çalışıyorsa, birkaç ay sonra sitede dört farklı mavi, altı farklı buton ve birbirini tutmayan form alanları görürsünüz. Tasarım sistemi bu dağılmayı durdurmak için kurulur. 2012'den beri kurumsal web projelerinde çalışıyorum; bu yazıda tasarım sistemini araç anlatısı olarak değil, bir kurumun ortak dili ve karar altyapısı olarak ele alıyorum.

Tasarım sistemi (design system) nedir?

Tasarım sistemi, bir kurumun dijital ürünlerinde kullandığı renk, tipografi, boşluk gibi temel kararları, bu kararlardan üretilen yeniden kullanılabilir bileşenleri, kullanım kurallarını ve bunların nasıl güncelleneceğini tanımlayan ortak kaynaktır. Kısacası tasarımcı ile yazılımcının aynı kararı aynı isimle kullanmasını sağlayan yaşayan bir altyapıdır.

Burada "yaşayan" kelimesi önemli. Bir PDF olarak teslim edilen ve bir daha açılmayan dosya tasarım sistemi değildir. Gerçek bir tasarım sistemi kodda karşılığı olan, sürümü takip edilen ve sahibi belli olan bir üründür. Örneğin İngiltere hükümetinin GOV.UK Design System sitesinde her bileşenin yanında ne zaman kullanılacağı, ne zaman kullanılmayacağı ve erişilebilirlik notları yer alır. Bu yüzden oradaki sistem yalnız bir görsel kütüphane değil, kamu hizmetlerinin ortak dilidir.

Tasarım sistemi hangi katmanlardan oluşur?

Sahada gördüğüm başarılı sistemlerin neredeyse hepsi dört katmanı birlikte taşır. Birini atladığınızda diğerleri de zamanla çürür. Bu nedenle kurulum planını bu dört başlık üzerinden yapmanızı öneririm:

• Tasarım tokenları: renk, yazı boyutu, boşluk, köşe yarıçapı, gölge ve hareket gibi en küçük kararların isimlendirilmiş değerleri.
• Bileşen kütüphanesi: buton, form alanı, kart, modal, tablo gibi hem tasarım dosyasında hem kodda karşılığı olan parçalar.
• Dokümantasyon: her bileşenin amacı, varyantları, doğru ve yanlış kullanım örnekleri, erişilebilirlik ve içerik yazım kuralları.
• Yönetişim: kimin neyi değiştirebileceği, yeni bileşen önerisinin nasıl değerlendirileceği ve sürümlerin nasıl duyurulacağı.

Öte yandan bu katmanların ağırlığı projeye göre değişir. Tek ürünlü bir şirkette tokenlar ve bileşenler öne çıkar; çok markalı bir holdingde ise yönetişim ve tema yapısı asıl işi taşır. Yine de dördünden birini tamamen boş bıraktığınızda sistem bir süre sonra kimsenin güvenmediği bir arşive dönüşür.

Stil rehberi, UI kit ve tasarım sistemi arasındaki fark ne?

Bu üç kavram toplantılarda sık karışıyor, ama aralarındaki fark bütçeyi ve beklentiyi doğrudan etkiliyor. Stil rehberi çoğunlukla markanın görsel kurallarını anlatır. UI kit ise tasarım dosyasında hazır duran bileşenlerdir. Tasarım sistemi ikisini kapsar ve üstüne kod, dokümantasyon ve süreç ekler.

Yani elinizde güzel bir Figma kütüphanesi olması, tasarım sisteminiz olduğu anlamına gelmez. Figma tarafındaki çalışma sürecini Figma ile web arayüz tasarımı yazısında ayrıntılı anlattım; burada o sürecin üzerine kurulan kurumsal düzeni konuşuyoruz.

Tasarım tokenı nedir ve neden bu kadar önemli?

Tasarım tokenı, bir tasarım kararının platformdan bağımsız, isimlendirilmiş hâlidir. "#0B5FFF" yazmak yerine "renk.marka.birincil" dersiniz. Böylece aynı karar web sitesinde CSS değişkenine, mobil uygulamada platform koduna, tasarım dosyasında ise stile dönüşür.

Bu alanda önemli bir gelişme oldu. W3C bünyesindeki Design Tokens Community Group, token dosya biçimini tanımlayan spesifikasyonun ilk kararlı sürümünü (2025.10) Ekim 2025'te duyurdu. Duyuruya göre biçim; tema ve çoklu marka desteği, modern renk uzayları ve tokenlar arası referans gibi yetenekler içeriyor. Figma, Penpot ve Sketch gibi araçlar da standardı desteklediğini ya da uyguladığını açıkladı.

Bu gelişme sizin için şu anlama geliyor: tokenlarınızı standart biçimde tutarsanız, araç değiştirdiğinizde kararlarınızı kaybetmezsiniz. Dolayısıyla token katmanı, sistemin en uzun ömürlü ve en taşınabilir parçasıdır.

Tokenları hangi seviyelere ayırmalısınız?

Tek düz bir renk listesi başlangıçta işe yarar, fakat ikinci marka ya da koyu tema geldiğinde çöker. Bu yüzden kurumsal projelerde tokenları üç seviyede kurguluyorum:

1. Temel (primitive) tokenlar: ham değerler. Örneğin "mavi.600" veya "boşluk.4". Bunlar bir anlam taşımaz, yalnızca paleti tanımlar.
2. Anlamsal (semantic) tokenlar: kararın amacını söyler. Örneğin "arkaplan.vurgu" veya "metin.hata". Temel tokenlara referans verir.
3. Bileşen tokenları: yalnız belirli bir bileşeni ilgilendirir. Örneğin "buton.birincil.arkaplan". Genellikle anlamsal tokenı işaret eder.

Bu yapının faydası tema değişiminde ortaya çıkar. Koyu temaya geçtiğinizde bileşen kodunu değil, yalnız anlamsal tokenların hangi temel değere bağlandığını değiştirirsiniz. Ancak her şeyi bileşen tokenına çevirmek de ayrı bir hatadır; bakım yükü hızla büyür. Pratikte anlamsal seviyeyi zengin, bileşen seviyesini sade tutmak en dengeli sonucu veriyor.

Renk paletini kurarken HTML renk kodları aracı ile ton ve kontrast denemeleri yapabilirsiniz.

Bileşen kütüphanesini nasıl kurgulamalısınız?

Bileşen kütüphanesi, tokenların somut ekranlara dönüştüğü yerdir. Brad Frost'un Atomic Design yaklaşımı burada iyi bir zihinsel model sunar: küçük parçalardan (atom) başlayıp molekül, organizma, şablon ve sayfaya doğru büyürsünüz. Ben bu modeli birebir uygulamaktan çok, ekiplerin ortak bir dil kurması için kullanıyorum.

Pratikte ilk kütüphanede şu sırayı izlemenizi öneririm. İlk olarak en sık kullanılan parçalar: buton, bağlantı, form alanları, uyarı kutusu. Ardından içerik taşıyan yapılar: kart, liste, tablo, sekme. Son olarak sayfa düzenleri: başlık alanı, üst menü, alt bilgi ve form şablonları.

Her bileşen için tasarım dosyası ile kodun aynı isimleri, aynı varyantları ve aynı durumları (hover, odak, pasif, hata) taşıması şart. Tasarımda "Primary Large" olup kodda "btn-main-lg" olan bir buton, altı ay sonra iki ayrı bileşene dönüşür. Üstelik bu ayrışmayı fark etmek çoğu zaman bir kullanıcı şikâyetiyle olur.

Dokümantasyonda neler olmalı?

Dokümantasyonu en çok ihmal edilen katman olarak görüyorum. Ekip, bileşeni yaptıktan sonra "zaten Figma'da var" deyip geçiyor. Oysa yeni katılan bir geliştirici ya da ajans, doğru kararı ancak yazılı kurallarla verebilir.

İyi bir bileşen sayfasında şunları arıyorum:

• Bileşenin ne işe yaradığını anlatan tek cümlelik amaç.
• Ne zaman kullanılır, ne zaman kullanılmaz bölümü.
• Canlı örnek ve kopyalanabilir kod parçası.
• Doğru ve yanlış kullanım görselleri veya açıklamaları.
• Klavye kullanımı, odak sırası ve ekran okuyucu notları.
• Buton metni, hata mesajı gibi içerik yazım kuralları.
• Sürüm geçmişi ve sorumlu kişi ya da ekip.

Özellikle içerik kuralları büyük fark yaratıyor. Aynı sitede "Gönder", "Kaydet", "Tamam" ve "Devam" butonlarının aynı işi yaptığını görürsünüz. Bu tutarsızlık dönüşümü de etkiler; CTA butonu yazısında bunun satışa etkisini örneklerle anlattım.

Yönetişim olmadan tasarım sistemi neden çöker?

Yönetişim, sistemin kurallarının kim tarafından, hangi süreçle değiştirileceğini belirleyen düzendir. Kulağa bürokratik geliyor, ama olmadığında ne olduğunu çok gördüm. Her ekip ihtiyacı olan varyantı kendi kodunda üretir; bir yıl sonra kütüphanede kimsenin kullanmadığı bileşenler, projelerde ise kütüphanede olmayan kopyalar birikir.

Bu nedenle kurumsal projelerde en baştan birkaç soruya yazılı cevap istiyorum. Yeni bileşen önerisini kim yapabilir? Öneriyi kim, kaç gün içinde değerlendirir? Kırıcı (breaking) değişiklik nasıl duyurulur? Eski sürüm ne kadar süre desteklenir? Bu cevaplar yoksa sistem kişilere bağlı kalır ve o kişi ayrıldığında durur.

Öte yandan yönetişimi aşırı sıkı kurmak da ters teper. Ürün ekipleri her küçük ihtiyaç için haftalarca beklerse sistemi atlatmanın yolunu bulur. Sağlıklı denge, katkıya açık ama kalite kontrolü net bir süreçtir.

Hangi yönetişim modelini seçmelisiniz?

Nathan Curtis'in sık alıntılanan sınıflandırması üç modelden söz eder: merkezi, federe ve tek kişi ya da tek ekip odaklı model. Ben kurum ölçeğine göre şu şekilde okuyorum:

• Merkezi model: ayrı bir sistem ekibi kütüphaneyi yönetir, ürün ekipleri kullanır. Kalite yüksek olur, ancak sistem ekibi darboğaza dönüşebilir.
• Federe model: farklı ürün ekiplerinden temsilciler sisteme katkı verir. Sahiplik yayılır, fakat koordinasyon gerektirir.
• Karma model: çekirdeği küçük bir merkezi ekip tutar, ürün ekipleri kurallı bir süreçle katkı sunar. Orta ve büyük kurumlarda en sık işe yarayan yapı budur.

Hangi modeli seçerseniz seçin, yazılı bir katkı rehberi ve düzenli bir inceleme toplantısı olmalı. Örneğin iki haftada bir yapılan kısa bir toplantı, birikmiş önerileri eritmeye çoğu zaman yeter. Bu sıklık saha tecrübesine dayalı bir başlangıç önerisidir, garanti değildir.

Kurumsal web projelerinde tasarım sistemi neden şart?

Kurumsal projelerin ortak özelliği, tek bir ekibin tek bir sayfayı yapmaması. Pazarlama ekibi kampanya sayfası açar, ürün ekibi müşteri panelini geliştirir, bir ajans kariyer sitesini yapar, İK bir başvuru formu ister. Tasarım sistemi olmadığında bu ekiplerin her biri kendi kararını verir.

Sonuç olarak üç sorun ortaya çıkar. Birincisi marka tutarsızlığı: kullanıcı aynı kurumun sitesinde farklı dünyalarda geziyormuş gibi hisseder. İkincisi hız kaybı: her ekip butonu, formu, tabloyu yeniden tasarlar ve yeniden test eder. Üçüncüsü kalite açığı: erişilebilirlik ve performans kuralları bir ekipte uygulanırken diğerinde unutulur.

Tasarım sistemi bu üç sorunu aynı anda çözer, çünkü kararı bir kez verip her yerde yeniden kullanırsınız. Bu yüzden kurumsal ölçekte tasarım sistemini lüks değil, altyapı olarak görüyorum. Web tasarım projelerimde de çok ekipli yapılarda ilk teslimatlardan biri token ve temel bileşen setidir.

Çok ekipli yapılarda tutarlılığı nasıl sağlar?

Tutarlılık, herkesin aynı kaynağı kullanmasıyla gelir. Tasarım sistemi bu kaynağı paket hâline getirir: ekipler bileşenleri kopyalamaz, sürümlü bir paketten içeri alır. Böylece bir renk düzeltmesi ya da odak stili değişikliği, paket güncellendiğinde bütün projelere yayılır.

Burada sık yapılan bir hata var: paketi yayınlayıp ekiplerin güncellemesini beklemek. Oysa ekipler yoğun dönemlerde güncellemeyi erteler ve farklı projeler farklı sürümlerde kalır. Bu nedenle güncelleme takvimini sürüm notlarıyla birlikte duyurmanızı ve eski sürümler için net bir bitiş tarihi koymanızı öneririm.

Mimari tarafta da benzer bir tablo var. Ön yüzü bağımsız parçalara bölen yapılarda ortak görsel dil ancak paylaşılan bir tasarım sistemiyle korunabilir. Bu ilişkiyi micro frontend yazısında mimari açıdan ele aldım.

Tasarım sistemi projeyi gerçekten hızlandırır mı?

Kısa cevap evet, ama ilk günden değil. Kurulum döneminde ekip yavaşlar, çünkü mevcut ekranları envanterler, kararları tartışır ve bileşenleri yeniden yazar. Hız kazancı genellikle sistem oturduktan ve birkaç proje onu kullandıktan sonra görünür.

Sahada gördüğüm hızlanma üç yerden geliyor. İlk olarak tasarımcı sıfırdan çizmek yerine hazır bileşenleri birleştirir. Ardından geliştirici, test edilmiş bileşeni kullandığı için hata ayıklamaya daha az zaman harcar. Son olarak inceleme turları kısalır, çünkü "bu buton neden farklı" tartışması ortadan kalkar.

Yine de kesin bir yüzde vermekten kaçınıyorum. Kazancın büyüklüğü ekip sayısına, ekran çeşitliliğine ve sistemin ne kadar benimsendiğine bağlı. Bu yüzden kazancı iddia etmek yerine ölçmenizi öneririm; aşağıda hangi metriklere bakabileceğinizi anlatıyorum.

Tasarım sistemi erişilebilirliği nasıl etkiler?

Erişilebilirlik, tasarım sisteminin en güçlü kaldıraçlarından biri. Bir bileşeni bir kez doğru kurduğunuzda, o bileşeni kullanan her sayfa aynı doğruluğu miras alır. Örneğin odak göstergesi, form etiketi ve hata mesajı ilişkisi kütüphanede çözülmüşse, ürün ekiplerinin bunu her seferinde hatırlaması gerekmez.

Referans olarak W3C'nin WCAG 2.2 yönergelerini kullanıyorum. Yönergeler metin kontrastı, klavye erişimi, odak görünürlüğü ve hedef boyutu gibi konularda ölçülebilir başarı kriterleri tanımlar. Bu kriterleri token seviyesinde (renk çiftlerinin kontrastı) ve bileşen seviyesinde (klavye davranışı) test etmek, sayfa sayfa düzeltmekten çok daha verimli.

Ancak sistem tek başına yeterli değil. Doğru bileşeni yanlış bağlamda kullanmak hâlâ mümkün. Bu nedenle dokümantasyonda erişilebilirlik notlarını açıkça yazmanızı ve içerik ekiplerine de kısa bir eğitim vermenizi öneririm.

SEO ve performans tarafında ne kazandırır?

Tasarım sistemi doğrudan bir sıralama faktörü değil; Google tasarım sisteminiz olup olmadığını bilmez. Fakat sistemin dolaylı etkileri SEO ve kullanıcı deneyimi metriklerine yansır. Tutarlı başlık hiyerarşisi, anlamlı HTML kullanan bileşenler ve kontrollü CSS boyutu arama motorları açısından da temiz bir zemin hazırlar.

Performans tarafında en belirgin kazanç, tekrar eden stil ve script kodunun azalmasıdır. Her ekip kendi buton stilini yazdığında CSS dosyaları şişer. Ortak bileşenler ise tek bir yerde optimize edilebilir. Örneğin görsel bileşenine sabit en boy oranı eklediğinizde, düzen kaymasını bütün sitede birden azaltırsınız.

Bu konuda site hızının SEO'ya etkisi ve SEO ile UX uyumu yazılarım daha ayrıntılı bilgi veriyor. Kısacası tasarım sistemi, teknik SEO kurallarını bileşenlere gömmenin en pratik yoludur.

Marka kimliği ile tasarım sistemi nasıl bağlanır?

Marka kimliği, kurumun nasıl göründüğünü ve nasıl konuştuğunu tanımlar. Tasarım sistemi ise bu kimliği dijital ürünlerde uygulanabilir kurallara çevirir. İkisi arasındaki köprü tokenlardır: markanın ana rengi, yazı karakteri ve görsel dili, token olarak sisteme girer.

Sık karşılaştığım sorun, basılı kimlik kılavuzundaki kararların ekranda karşılığının olmaması. Örneğin basılı kılavuzda tanımlı bir renk, beyaz zemin üzerinde metin rengi olarak yeterli kontrastı vermeyebilir. Bu durumda sistem, markayı bozmadan ekrana uygun anlamsal tonlar türetmelidir. Bu dönüşümü basılı kurumsal kimliği dijitale taşıma yazısında adım adım anlattım.

Dolayısıyla marka çalışması ile tasarım sistemi kurulumunu ayrı projeler olarak değil, birbirini besleyen iki aşama olarak planlamanızı öneririm. Marka kimliği tarafında verilen her karar, sistemde bir token karşılığı bulmalıdır.

Tasarım sistemi kurulumu nasıl adım adım ilerler?

Kurumsal projelerde izlediğim akış genellikle şöyle. Sıra projeye göre esner, ama adımları atlamamaya çalışıyorum:

1. Envanter: mevcut sitelerdeki bütün buton, renk, yazı boyutu ve form örneklerini ekran görüntüsüyle toplarsınız. Bu adım tutarsızlığın boyutunu herkese gösterir.
2. Karar oturumları: tasarım, yazılım ve marka temsilcileriyle temel kararları netleştirirsiniz.
3. Token katmanı: temel ve anlamsal tokenları tanımlar, kod çıktısını otomatikleştirirsiniz.
4. Pilot bileşenler: en sık kullanılan beş ila on bileşeni tasarım ve kodda birlikte üretirsiniz.
5. Pilot proje: sistemi gerçek bir sayfada veya küçük bir üründe denersiniz.
6. Dokümantasyon ve yönetişim: katkı süreci, sürüm politikası ve sorumlulukları yazıya dökersiniz.
7. Yaygınlaştırma: diğer ekipleri sırayla sisteme taşır, geri bildirimle kütüphaneyi genişletirsiniz.

Burada kritik nokta pilot projedir. Sistemi yalnız kâğıt üzerinde tasarlayıp gerçek bir ekrana uygulamadan yaygınlaştırmak, sahada karşılığı olmayan kararlar üretir.

Hangi araçlarla çalışılır?

Araç seçimi ikincil bir konu, ama sorulduğu için kısaca değiniyorum. Tasarım tarafında Figma ya da Penpot gibi bir araç bileşen kütüphanesini tutar. Token yönetimi için Tokens Studio gibi eklentiler ve Style Dictionary gibi dönüştürücüler, token dosyasını CSS, iOS ve Android çıktısına çevirir. Bileşenlerin kod tarafında izole geliştirilmesi ve belgelenmesi için Storybook yaygın bir tercihtir.

Ancak araçlar sistemi kurmaz. Aynı araç setini kullanan iki kurumdan biri çalışan bir sistem, diğeri terk edilmiş bir kütüphane sahibi olabilir. Fark, yukarıda anlattığım yönetişim ve dokümantasyon disiplinidir.

Google'ın Material Design 3 token dokümantasyonu gibi açık sistemleri incelemek, kendi yapınızı kurarken iyi bir referans verir. Yine de başkasının sistemini olduğu gibi kopyalamak yerine, kendi ürün ihtiyaçlarınızdan yola çıkmanızı öneririm.

Tema ve çoklu marka desteğini nasıl kurgulamalısınız?

Holding yapılarında sık gördüğüm senaryo şu: ana marka, iki alt marka ve bir de kampanya markası aynı altyapıyı paylaşmak istiyor. Her marka için ayrı kütüphane kurarsanız bakım maliyeti marka sayısıyla katlanır. Bunun yerine bileşenleri ortak tutup yalnız tema katmanını değiştirmek çok daha sürdürülebilir bir yol.

Pratikte her marka kendi temel paletini ve yazı karakterini getirir. Anlamsal tokenlar ise bütün markalarda aynı isimle kalır; yalnız hangi değere bağlandıkları değişir. Böylece "metin.birincil" her markada doğru rengi alır, ama bileşen kodu tek kalır.

Koyu tema da aynı mantıkla çalışır. Ancak koyu temayı renkleri ters çevirmek olarak görmeyin. Kontrast oranlarını her tema için ayrıca doğrulamanız, gölge ve derinlik tokenlarını da yeniden düşünmeniz gerekir. Bu yüzden tema sayısını ihtiyaç kadar tutmanızı öneririm; her yeni tema, test edilecek yeni bir kombinasyon demektir.

Dış ajanslar ve tedarikçilerle nasıl çalışırsınız?

Kurumsal projelerde işin önemli bir kısmını dış ajanslar yapar. Kampanya sayfası bir ajanstan, mobil uygulama başka bir ekipten, kariyer sitesi üçüncü bir tedarikçiden gelir. Ortak bir kaynak olmadığında her tedarikçi markayı kendi yorumuyla uygular.

Bu noktada sistemi sözleşmenin bir parçası yapmanızı öneririm. Teklif aşamasında ajansa kütüphaneye erişim verin, teslimatta hangi bileşenleri kullandığını ve hangi yeni parçaları ürettiğini listelemesini isteyin. Yeni ürettiği parçalar faydalıysa katkı sürecinden geçirip kütüphaneye alabilirsiniz.

Üstelik bu yaklaşım onboarding süresini de kısaltır. Yeni ajans, yazılı kurallar ve hazır bileşenlerle ilk haftadan üretken olur. Kısacası iyi belgelenmiş bir sistem, tedarikçi değiştirmenin maliyetini de düşürür.

Sürümleme ve değişiklik yönetimi nasıl olmalı?

Bileşen paketini yazılım paketi gibi yönetmelisiniz. En yaygın yöntem anlamsal sürümlemedir: küçük düzeltmeler yama, geriye uyumlu yenilikler küçük sürüm, kırıcı değişiklikler ise büyük sürüm olarak çıkar. Böylece ekipler bir güncellemenin risk seviyesini sürüm numarasından okuyabilir.

Her sürümle birlikte kısa ve anlaşılır bir değişiklik notu yayınlayın. Notta neyin değiştiğini, kimin etkilendiğini ve geçiş için ne yapması gerektiğini yazın. Özellikle kırıcı değişikliklerde eski davranışı bir süre uyarıyla korumak, ekiplere nefes alanı bırakır. Örneğin eski bileşeni hemen silmek yerine, konsolda uyarı veren bir geçiş sürümüyle iki ay kadar yaşatabilirsiniz. Bu süre saha tecrübesine dayalı bir öneridir, garanti değildir.

Ayrıca görsel regresyon testlerini sürece eklemenizi öneririm. Bir token değişikliğinin hangi ekranları etkilediğini otomatik ekran görüntüsü karşılaştırmasıyla görmek, canlıda sürpriz yaşamanızı önler.

Ekiplerin sistemi benimsemesini nasıl sağlarsınız?

En iyi kurgulanmış kütüphane bile kullanılmadığında hiçbir işe yaramaz. Benimsenme, teknik bir konudan çok insan ve alışkanlık meselesidir. Ekipler yeni bir yapıya ancak işlerini kolaylaştırdığını gördüklerinde geçer.

Bu yüzden duyuru e-postası yerine uygulamalı oturumlar düzenlemenizi öneririm. Her ürün ekibiyle kendi ekranlarından birini birlikte sisteme taşıyın. Böylece ekip hem bileşenleri tanır hem de eksikleri ilk elden bildirir. Ayrıca her ekipten bir "sistem elçisi" belirlemek, soruların tek bir kanaldan akmasını sağlar.

Öte yandan zorlamayla benimsenme gelmez. Kod incelemelerinde kütüphane dışı bileşenleri yasaklamak yerine, neden özel çözüme ihtiyaç duyulduğunu sorun. Çoğu zaman bu soru, kütüphanede eksik olan bir varyantı ortaya çıkarır. Kısacası her istisna, sistemi geliştirmek için bir veri noktasıdır. Düzenli bir iletişim kanalı, kısa demo videoları ve görünür bir yol haritası da güveni artırır; ekipler neyin ne zaman geleceğini bildiğinde kendi çözümlerini üretme ihtiyacı azalır.

Başarıyı hangi metriklerle ölçebilirsiniz?

Tasarım sistemine yatırım yapan yönetim haklı olarak sonuç görmek ister. Bu yüzden kurulumla birlikte birkaç basit ölçüm başlatmanızı öneririm:

• Benimsenme oranı: projelerde kütüphane bileşeni ile özel yazılmış bileşenin oranı.
• Sürüm yayılımı: projelerin kaçının güncel sürümde olduğu.
• Tasarım teslim süresi: benzer bir sayfanın tasarımdan canlıya geçiş süresi, öncesi ve sonrası.
• Arayüz hata kayıtları: görsel tutarsızlık ve erişilebilirlik kaynaklı hata sayısı.
• Katkı sayısı: ürün ekiplerinden gelen öneri ve katkıların sayısı.

Bu metrikleri bir panoda toplayıp üç ayda bir gözden geçirmek yeterli. Böylece sistemin gerçekten kullanılıp kullanılmadığını ve hangi alanın desteğe ihtiyaç duyduğunu görürsünüz. KPI seçimi yazısındaki mantık burada da geçerli: az ama karar aldıran metrik seçin.

En sık yapılan tasarım sistemi hataları neler?

Yıllar içinde aynı hataların farklı kurumlarda tekrarlandığını gördüm. En sık karşılaştıklarım şunlar:

• Sistemi bir kerelik proje gibi teslim edip sahipsiz bırakmak.
• Yalnız tasarım dosyasında kurup kod karşılığını üretmemek.
• İlk günden yüzlerce bileşenle başlamaya çalışmak.
• Ürün ekiplerini sürece dahil etmeden sistemi dayatmak.
• Token isimlerini değerle kurmak ("mavi-buton"), anlamla kurmamak.
• Dokümantasyonu sonraya bırakmak.

Bu hataların ortak noktası, tasarım sistemini ürün olarak değil, çıktı olarak görmek. Oysa bir ürün gibi kullanıcısı (ekipler), yol haritası ve bakım bütçesi olmalı. Arayüz tarafındaki genel kusurların satışa etkisini merak ediyorsanız UX hataları yazısına göz atabilirsiniz.

Küçük bir şirketin tasarım sistemine ihtiyacı var mı?

Her şirketin kurumsal ölçekte bir tasarım sistemine ihtiyacı yok. Tek bir web sitesi olan, tek tasarımcı ve tek geliştiriciyle çalışan bir işletme için tam teşekküllü sistem, getirisinden fazla bakım yükü doğurabilir.

Yine de küçük ölçekte bile hafif bir versiyon işe yarar. Birkaç temel token (renk, yazı, boşluk), on civarında temel bileşen ve bir sayfalık kullanım notu, ileride büyüdüğünüzde sağlam bir başlangıç sağlar. Özellikle ikinci bir site, bir mobil uygulama ya da dış ajansla çalışma planınız varsa bu hafif yapıyı erkenden kurmanız, ileride pahalı bir temizlikten sizi kurtarır.

Karar verirken şu soruya bakın: arayüze dokunan kaç ekip veya kişi var ve bu sayı önümüzdeki bir yılda artacak mı? Cevap evetse, tasarım sistemi yatırımını şimdi planlamanın zamanı gelmiştir. Hizmet almadan önce sorulacak soruları UI/UX tasarım hizmeti rehberinde topladım.