# Marka Sistemi Nedir ve Neden Önemlidir? > Marka sisteminin kılavuzdan farkı, bileşenleri, rol bazlı token isimlendirmesi, envanterle kurulumu, yönetişim ve sürümlemeyle bakımı. > > Yayın: 30 Haziran 2026 · Yazar: The Whale Creative · Kaynak: https://thewhalecreative.co/dergi/marka-sistemi-nedir-neden-onemlidir ## Kısaca * Marka sistemi, bir markanın tüm varlıklarının nasıl üretilip ölçekleneceğini belirleyen modüler kurallar, şablonlar ve kod kütüphaneleridir; statik bir PDF kılavuzun ötesindedir. * Marka sistemi önemlidir çünkü tutarlılığı kişilerin hafızasına değil altyapıya bağlar; ekip ya da ajans değiştiğinde markayı ayakta tutan sistemin kendisidir. * Marka kılavuzu neyin doğru olduğunu anlatır, marka sistemi doğru olanı üretmeyi varsayılan hâle getirir; kurala uymak, uymamaktan daha kolay olmalıdır. * Tokenları renge göre değil role göre adlandırın; açık yeşil gibi bir isim marka rengi değiştiğinde yanlış olur, yüzey ya da vurgu gibi rol isimleri doğru kalır. * Bir marka sistemini canlı tutmak için tek bir sahip, öneri yolu, karar ritmi ve kayıt yeri gerekir; değişiklikler Semantic Versioning mantığıyla sürümlenebilir. Şirketler büyüdükçe, farklı tasarımcılar, ajanslar ve ekiplerle çalışmaya başlarlar. Bu süreçte en büyük tehlike, görsel tutarlılığın kaybolmasıdır. Instagram gönderileri farklı, web sitesi farklı, ambalajlar bambaşka bir dilden konuşmaya başladığında marka algısı zayıflar. İşte bu karmaşayı önleyen ve markanın tek bir kaynaktan yönetilmesini sağlayan yapıya marka sistemi diyoruz. Bu yazıda marka sisteminin ne olduğunu, klasik marka kılavuzundan farkını, hangi parçalardan oluştuğunu, token isimlendirmesinin neden kritik olduğunu, nasıl kurulduğunu ve kurulduktan sonra yönetişim ile sürümleme yoluyla nasıl canlı tutulacağını ele alıyoruz. ## Marka Sistemi Nedir? Marka sistemi (veya tasarım sistemi), bir markanın dijital ve fiziksel tüm varlıklarının nasıl oluşturulacağını, yerleştirileceğini ve ölçekleneceğini belirleyen modüler kurallar, şablonlar ve kod kütüphaneleri bütünüdür. Statik bir PDF marka kılavuzunun ötesinde, yaşayan ve sürekli güncellenen bir rehberdir. Buradaki anahtar kelime modülerliktir. Sistem size her durum için hazır bir tasarım vermez; birbirine takılabilen parçalar ve bu parçaların nasıl birleştirileceğine dair kurallar verir. Yeni bir kampanya çıktığında sıfırdan tasarım yapmak yerine mevcut parçaları yeni bir düzende birleştirirsiniz. Bu yaklaşımın en bilinen kuramsal çerçevesi, Brad Frost'un ortaya koyduğu atomic design yöntemidir: en küçük ögelerden (renk, tipografi, ikon) başlayıp bileşenlere, oradan da tam sayfa şablonlarına ilerleyen bir hiyerarşi kurulur. Büyük şirketlerin kamuya açık sistemleri de aynı mantıkla çalışır; Google'ın Material Design'ı, IBM'in Carbon'ı ve Shopify'ın Polaris'i bu yaklaşımın herkesin inceleyebileceği örnekleridir. Küçük ölçekte sistem kelimesi gözünüzü korkutmasın. İki şubeli bir kahveci için sistem, bir yazılım şirketinin bileşen kütüphanesi kadar büyük olmak zorunda değildir: dört renk rolü, üç başlık basamağı, iki sosyal medya şablonu, bir menü şablonu ve bunların nerede kullanılacağını anlatan yarım sayfalık bir not da bir sistemdir. Belirleyici olan boyut değil, kararların bir yerde toplanmış ve tekrar kullanılabilir olmasıdır. **Bir marka sistemi tasarımı güzelleştirmez, tasarım kararlarını tekrar edilebilir hale getirir.** ## Marka Kılavuzu ile Marka Sistemi Arasındaki Fark Marka kılavuzu neyin doğru olduğunu anlatan bir belgedir; marka sistemi ise doğru olanı üretmeyi kolaylaştıran bir araç setidir. Kılavuz okunur, sistem kullanılır. Farkı somutlaştıralım. Klasik bir kılavuz "başlıklarda 32 punto kullanın" der ve tasarımcının bunu her dosyada elle uygulamasını bekler. Bir sistemde ise aynı kural bir stil ya da bileşen olarak tanımlıdır; tasarımcı başlığı seçer, değer otomatik gelir. Kılavuzda kurala uymak disiplin gerektirir, sistemde kurala uymak varsayılan davranıştır. Bu farkın pratikteki sonucu ölçülebilir: kılavuzda kuralı uygulamamak serbesttir ve kimse fark etmez, sistemde ise kuralın dışına çıkmak ayrı bir çaba gerektirir. İnsanlar genellikle en az dirençli yolu seçtiği için, doğru davranışı kolay olan yol haline getirmek en etkili yönetim aracıdır. Bu yüzden PDF kılavuzlar zamanla eskir. Sistemde ise güncelleme kaynakta yapılır ve o kaynağa bağlı tüm dosyalara yansır. Kılavuz hâlâ gereklidir, ancak artık sistemin yanında duran açıklayıcı bir katman olarak işe yarar; tek başına yeterli değildir. **Kural yazmak yetmez; kurala uymayı, uymamaktan daha kolay hale getirmek gerekir.** ## Neden Önemlidir? Marka sistemi önemlidir çünkü tutarlılığı kişilerin hafızasına değil altyapıya bağlar. Ekip değiştiğinde, ajans değiştiğinde veya iş hacmi arttığında markayı ayakta tutan şey kişisel özen değil, sistemin kendisidir. * **Hız ve Operasyonel Verimlilik:** Ekipler her yeni kampanya için sıfırdan tasarım yapmaz. Hazır ızgaraları, renk rollerini, tipografi kurallarını ve dijital bileşenleri kullanarak işleri belirgin şekilde daha hızlı üretir. * **Görsel Tutarlılık:** Marka sistemi sayesinde işi kimin ürettiğinden bağımsız olarak çıktı, markanın aynı karakterini ve kalite seviyesini taşır. * **Tasarım Borcunu (Design Debt) Engeller:** Rastgele eklenen yeni yazı tipleri, farklı düğme stilleri veya tutarsız renk tonları zamanla sistemi kirletir. Sistem bu kirliliği sınırlayarak kod ve tasarım temizliğini korur. * **Müşteri Güvenini Destekler:** Her arayüzde ve basılı materyalde aynı profesyonel disiplini gören müşteri için markanın güvenilir görünmesi kolaylaşır. * **Devir Maliyetini Düşürür:** Yeni bir tasarımcı ya da geliştirici işe başladığında, markayı öğrenmek için kimseye uzun uzun soru sormak zorunda kalmaz. * **Kaliteyi Tabana Yayar:** Erişilebilirlik ve okunabilirlik kararları bileşen seviyesinde bir kez çözüldüğünde, o bileşeni kullanan herkes doğru sonucu üretir. Listenin son maddesi çoğu zaman en değerlisidir. Kontrast oranı, buton yüksekliği, dokunma alanı ya da form hata mesajı gibi konular tek tek dosyalarda tartışıldığında her seferinde farklı sonuç verir. Bileşen içinde çözüldüğünde ise doğru davranış varsayılan hale gelir ve kalite, ekibin en deneyimli kişisine bağlı olmaktan çıkar. Bunu somut bir örnekle görelim. Üç kişilik bir ekibin buton kararını sistemsiz verdiği durumda üç farklı yükseklik, iki farklı köşe yarıçapı ve renk kontrastı yetersiz bir varyant ortaya çıkar; sorun ancak bir kullanıcı şikâyetiyle fark edilir. Aynı ekip butonu bir kez bileşen olarak kurduğunda, WCAG 2.2'nin AA seviyesinde tanımladığı 24'e 24 CSS piksellik asgari dokunma hedefi ve 4,5:1 metin kontrast oranı bir kez sağlanır ve sonraki her sayfada kendiliğinden doğru gelir. **Kalite, en deneyimli kişinin dikkatine bağlı olduğu sürece rastlantısaldır; bileşene yazıldığında kurumsallaşır.** ## Bir Marka Sisteminin Bileşenleri Bir marka sistemi üç katmandan oluşur: temel değerler, bileşenler ve kullanım kuralları. Bu katmanlar hem tasarım dosyasında hem de kodda birbirinin karşılığı olacak şekilde tanımlanmalıdır. * **Temel değerler:** Renk rolleri, tipografi ölçeği, boşluk ölçeği, köşe yarıçapları, gölge seviyeleri ve hareket süreleri. Bunlar genellikle token olarak isimlendirilir. * **Bileşenler:** Buton, form alanı, kart, gezinme çubuğu, uyarı kutusu, tablo gibi tekrar eden yapılar ve bunların durumları. * **Şablonlar:** Ana sayfa, ürün sayfası, blog yazısı, sosyal medya gönderisi, sunum sayfası ve e-posta düzenleri. * **İçerik kuralları:** Buton metinleri, hata mesajları, başlık uzunlukları, büyük harf kullanımı ve ses tonu örnekleri. * **Varlık kütüphanesi:** Logo seti, ikon ailesi, illüstrasyon dili, fotoğraf yönü ve örnek kullanım görselleri. * **Yönetişim:** Kimin değişiklik önerebileceği, kimin onayladığı ve sürümlerin nasıl takip edildiği. Pratikte bu katmanlar iki yerde yaşar. Tasarım tarafında Figma kütüphaneleri ve değişkenleri, kod tarafında ise CSS özel değişkenleri, Tailwind gibi bir yardımcı sınıf sistemi veya Storybook ile belgelenmiş bir bileşen kütüphanesi kullanılır. İkisi aynı isimlendirmeyi paylaştığında tasarımcı ile geliştirici arasındaki çeviri kaybı büyük ölçüde ortadan kalkar. Bileşenlerde en sık atlanan şey durumlardır. Bir buton yalnızca "normal hâli" ile tanımlanmaz; üzerine gelindiğinde, tıklandığında, odaklandığında, yüklenirken ve devre dışıyken nasıl göründüğü de tanımlanmalıdır. Klavyeyle gezinen kullanıcılar için odak hâlinin görünür olması özellikle önemlidir ve bu, çoğu sistemde unutulan tek durumdur. Şablon katmanında ise sayı sınırı koymak faydalıdır. Elli şablonu olan bir sistemde kimse doğru şablonu bulamaz. Küçük ve orta ölçekli bir işletme için beş ile on arası şablon, gerçek ihtiyacın büyük bölümünü karşılar ve listeyi taranabilir tutar. **Bir bileşen, yalnızca duran hâliyle değil altı durumuyla birlikte tanımlandığında bileşen olur.** ## Token İsimlendirme: Sistemin En Çok Küçümsenen Parçası Token isimlendirmesi, sistemin uzun ömürlü olup olmayacağını belirleyen tek karardır. Bir rengi "açık yeşil" diye adlandırırsanız, marka rengi değiştiğinde isim yalan söylemeye başlar; role göre adlandırıldığında isim doğru kalır ve yalnızca değeri değiştirmeniz yeterli olur. İşleyen isimlendirmeler genellikle üç katmanlıdır ve bu katmanları ayırmak sistemin ileride büyümesini kolaylaştırır: * **Temel katman:** Ham değerlerin adlandırıldığı yer. Buradaki isimler rengi tarif eder, görevini değil; örneğin bir gri skalasının basamakları. * **Anlamsal katman:** Rolü tarif eden isimler. Yüzey, metin, sessiz metin, kenarlık, birincil, vurgu, uyarı, başarı gibi. * **Bileşen katmanı:** Yalnızca belirli bir bileşene ait değerler. Buton zemin rengi, buton metin rengi gibi. Tasarımcı ve geliştirici günlük işte yalnızca anlamsal katman ile bileşen katmanını kullanır; temel katman perde arkasında kalır. Marka rengi değiştiğinde tek yapmanız gereken, anlamsal katmanın hangi temel değere baktığını değiştirmektir ve değişiklik tüm dosyalara yayılır. İsimlendirmede üç yaygın hata vardır. Birincisi, ismin içine değeri yazmaktır; bu, değer değiştiği an ismi geçersiz kılar. İkincisi, ismin içine kullanım yerini yazmaktır; "ana sayfa başlık rengi" gibi bir isim, aynı rengin başka sayfada kullanılmasını mantıksız gösterir. Üçüncüsü ise isimlendirme dilini karıştırmaktır; Türkçe ve İngilizce isimlerin aynı kütüphanede karışması, arama yapmayı ve eşleştirmeyi zorlaştırır. Tek bir dil seçin ve tüm katmanlarda ona sadık kalın. **İyi bir token adı değeri değiştiğinde hâlâ doğru olan addır.** ## Marka Sistemi Nasıl Kurulur? Marka sistemi sıfırdan icat edilerek değil, mevcut işlerin envanteri çıkarılarak kurulur. Önce elinizde ne olduğunu görür, sonra tekrar edenleri standartlaştırırsınız. * **Envanter:** Son bir yılda üretilen tüm dijital ve basılı materyali bir araya getirin. Kaç farklı buton, kaç farklı yeşil tonu, kaç farklı başlık boyutu kullanıldığını sayın. * **Ayıklama:** Tekrar edenleri birleştirin, tek seferlik olanları ayıklayın. Bu aşamanın değeri, neyin gerçekten gerekli olduğuna tahminle değil sayarak karar vermenizi sağlamasıdır. * **Temelleri tanımlayın:** Renk rolleri, tipografi ölçeği ve boşluk ölçeği. Sistemin geri kalanı bu üç karara yaslanır. * **Bileşenleri kurun:** En sık kullanılan beş ya da altı bileşenle başlayın. Tamamını baştan kurmaya çalışmak projeyi bitmez hâle getirir. * **Gerçek bir işte test edin:** Sistemi yeni bir sayfa veya kampanya üretirken kullanın. Eksikler ancak gerçek bir teslim tarihinin baskısı altında ortaya çıkar. * **Belgeleyin ve devredin:** Her bileşenin ne zaman kullanılacağını ve ne zaman kullanılmayacağını yazın. Kullanılmama koşulları, kullanım koşulları kadar önemlidir. Envanter adımını somutlaştıralım. Tek bir çalışma alanı açın, son bir yılın ekran görüntülerini ve basılı işlerini buraya yapıştırın, sonra yalnızca dört şeyi ayrı ayrı gruplayın: butonlar, başlıklar, renkler ve kart benzeri kutular. Bu gruplama yarım gün sürer ve neredeyse her zaman aynı sonucu verir: gereken sayının üç ya da dört katı varyant vardır ve bunların çoğu kasıtlı değil, kopyalama yoluyla oluşmuştur. Bu sürecin en sık yapılan hatası, sistemi mükemmelleştirmeden yayına almamaktır. Eksik ama kullanılan bir sistem, eksiksiz ama kimsenin açmadığı bir dosyadan her zaman daha değerlidir. Bu hatanın nedeni genellikle iyi niyettir: ekip, yarım bir sistemin kafa karıştıracağını düşünür. Düzeltmesi ise sistemin ilk sürümünü açıkça "birinci sürüm" diye adlandırmak ve neyin henüz kapsam dışında olduğunu aynı sayfaya yazmaktır. **Kullanılan eksik bir sistem, kullanılmayan mükemmel bir sistemden her zaman daha değerlidir.** ## Marka Sistemine Ne Zaman İhtiyaç Duyarsınız? Marka sistemine, aynı tasarım kararını ikiden fazla kişi verdiğinde ihtiyaç duyarsınız. Tek kişilik bir işletmede tutarlılık zaten kurucunun kafasındadır; ikinci kişi işin içine girdiği anda o bilgi dışarı yazılmak zorundadır. * Birden fazla kanal düzenli olarak içerik üretiyor. * Dış kaynak bir tasarımcı veya ajansla çalışıyorsunuz. * Web siteniz ile basılı materyaliniz farklı kişiler tarafından hazırlanıyor. * Ürün ya da hizmet yelpazeniz alt markalara ayrılıyor. * Aynı işi farklı dillerde veya farklı pazarlarda yayınlıyorsunuz. * Tasarım revizyonlarının çoğu "bu renk hangisiydi" tarzı sorularla geçiyor. Bu maddelerin hiçbiri sizin için geçerli değilse, tam kapsamlı bir sistem kurmak erken olabilir. Bu durumda tek sayfalık bir temel kurallar belgesi ve üç hazır şablon, ihtiyacın büyük kısmını karşılar. Sisteme geçişin doğru anını yakalamanın basit bir göstergesi var: aynı soruyu üçüncü kez cevapladığınızda o kararı yazın. "Başlık hangi puntoydu", "bu maviyi nereden aldık", "buton köşeleri yuvarlak mıydı" gibi sorular üçüncü tekrarında artık kişisel bilgi değil, kurumsal bilgidir ve kurumsal bilgi belgeye yazılır. **Aynı soruyu üçüncü kez cevapladığınızda, o cevabı artık yazmanız gerekiyor demektir.** ## Sistemi Canlı Tutmak: Yönetişim ve Güncelleme Bir marka sistemi, bakımı yapılmadığında kurulduğu gün en iyi halindedir ve sonrasında sürekli değer kaybeder. Sistemi canlı tutan şey tasarımın kalitesi değil, güncelleme kurallarının net olmasıdır. Pratikte üç soruya yazılı cevap vermeniz yeterlidir. Yeni bir bileşen ihtiyacı doğduğunda bunu kim önerir, kim karar verir ve karar nereye yazılır. Bu üç cevabı belirlemeyen ekiplerde sistem birkaç ay içinde ikiye ayrılır: bir tarafta resmî kütüphane, diğer tarafta insanların kopyalayıp kendi dosyalarında değiştirdiği gayriresmî sürümler. Yönetişimi küçük bir işletmede kurmak için ağır bir süreç gerekmez. Dört madde yeterlidir: * **Sahip:** Sistemden sorumlu tek bir kişi. Rol paylaşıldığında kimse bakmaz. * **Öneri yolu:** Değişiklik isteğinin nereye yazılacağı; ortak bir liste, bir form ya da tek bir kanal. * **Karar ritmi:** Önerilerin ne sıklıkla gözden geçirileceği. Ayda bir kısa bir toplantı çoğu ekip için yeterlidir. * **Kayıt yeri:** Kararın ve gerekçesinin yazıldığı tek bir sayfa. Gerekçe, altı ay sonra aynı tartışmanın yeniden açılmasını engeller. En sık yapılan yönetişim hatası, onayı yavaşlatmaktır. Değişiklik önerisi haftalarca beklediğinde insanlar sistemi beklemeyi bırakır ve kendi çözümlerini üretir; bu noktadan sonra sistemi geri toplamak, baştan kurmaktan zordur. Düzeltmesi, küçük değişiklikler için onay eşiğini düşürmek ve yalnızca temel katmana dokunan değişiklikleri sahip onayına bağlamaktır. Son olarak sistemin bir de kullanım ölçümü olmalıdır. Kaç dosyanın kütüphaneye bağlı olduğunu, kaç sayfanın güncel bileşenleri kullandığını ara ara kontrol edin. Kullanılmayan bir bileşen ya yanlış tasarlanmıştır ya da varlığından kimsenin haberi yoktur; iki durumda da müdahale gerekir. **Sahipsiz sistem, herkesin sorumlu olduğu ve kimsenin bakmadığı bir dosya yığınına dönüşür.** ## Sürümleme: Bir Değişiklik Nasıl Yayınlanır? Sürümleme, bir değişikliğin kimleri etkileyeceğini önceden söylemenin yoludur. Bir bileşen değiştiğinde en kritik soru "daha güzel oldu mu" değil, "mevcut kullanımlar bozuluyor mu" sorusudur ve bu sorunun cevabı sürüm numarasında görünmelidir. Yazılım tarafında yaygın olarak kullanılan Semantic Versioning yaklaşımı burada doğrudan işe yarar. Bu yaklaşımın resmî tanımına göre sürüm numarası üç parçadan oluşur: geriye dönük uyumu bozan değişikliklerde birinci sayı, uyumu bozmadan yeni işlev eklendiğinde ikinci sayı, uyumlu düzeltmelerde ise üçüncü sayı artırılır. Aynı mantığı bir tasarım kütüphanesine uyarlamak kolaydır. Pratikte şöyle görünür. Butonun gölgesini yumuşatmak üçüncü sayıyı artırır ve kimseyi uyarmanıza gerek kalmaz. Butona yeni bir boyut varyantı eklemek ikinci sayıyı artırır ve ekibe duyurulur. Buton bileşeninin adını değiştirmek ya da bir varyantı kaldırmak ise birinci sayıyı artırır ve önceden haber verilmesi gerekir, çünkü mevcut dosyalar kırılacaktır. Değişiklik günlüğü tutmak için karmaşık bir araca ihtiyaç yoktur. Tek bir sayfada, en yeni en üstte olacak şekilde şu üç bilgiyi yazın: tarih, ne değişti ve ne yapılması gerekiyor. Üçüncü sütun en önemlisidir, çünkü ekip "bu beni ilgilendiriyor mu" sorusunu ancak orada cevaplayabilir. Eski sürümlerin nasıl emekliye ayrılacağını da baştan kararlaştırın. Bir bileşen kaldırılacaksa önce "kullanımdan kaldırılacak" olarak işaretlenir, yerine ne geleceği yazılır ve bir süre ikisi birlikte yaşar. Doğrudan silmek en hızlı yol gibi görünür, ancak o bileşeni kullanan dosyaları bulup düzeltme işini planlanmamış bir acil duruma çevirir. **Sürüm numarası bir etiket değil, bir uyarıdır: "bu değişiklik senin dosyanı bozar" demenin en kısa yoludur.** ## Sistem Ne Zaman Fayda Getirmez? Marka sistemi, üretim hacmi olmayan bir işletmeye fayda getirmez. Sistemin değeri tekrardan doğar; ayda bir görsel üreten bir işletmede standartlaştırılacak bir tekrar yoktur ve sistem kurma çabası, o çabayla üretilebilecek işten daha pahalıya gelir. Şu durumlarda sistem kurmayı erteleyin: * Üretim hacminiz düşük ve tüm tasarım kararlarını tek bir kişi veriyor. * Marka konumlandırmanız önümüzdeki aylarda değişebilir; sistem, yanlış kararları da ölçekler. * Sistemi uygulayacak araç ya da beceri ekipte yok; kimsenin açmadığı bir kütüphane maliyet üretir, fayda üretmez. * Asıl sorununuz tutarsızlık değil, işin kendisinin az olması. Bir sınır daha var: kampanya ve özel projeler. Sistem günlük üretimi hızlandırmak için vardır, her yaratıcı işi kalıba sokmak için değil. Yıllık bir kampanya ya da özel bir lansman için sistemin dışına çıkmak meşrudur; önemli olan bu istisnanın bilinçli olması ve kampanya bittiğinde varsayılan sisteme geri dönülmesidir. İstisnayı önceden tanımlamak, sistemin sessizce aşınmasını engeller. **Sistem doğru kararları hızlandırır, ama yanlış kararları da aynı hızla çoğaltır.** ## Bizim Yaklaşımımız Marka sistemi kurarken işe mevcut varlıkların envanteriyle başlıyoruz, çünkü çoğu markanın sorunu eksik tasarım değil, fazla ve birbirinden habersiz tasarım. Kaç farklı buton, kaç farklı gri tonu ve kaç farklı başlık boyutu kullanıldığını saydığımızda tartışma zevk meselesi olmaktan çıkıyor. Temelleri role göre adlandırıyoruz ve aynı isimlendirmeyi hem Figma tarafında hem de kod tarafında kullanıyoruz. Böylece bir renk kararı değiştiğinde tasarım dosyası ile canlı site arasında ayrışma olmuyor. Bileşenleri ise tamamını birden değil, gerçek bir teslim işinin ihtiyaç duyduğu sırayla kuruyoruz; sistem böylece kullanılmadan büyümüyor. Bileşenlerin durumlarını baştan tanımlıyoruz: normal, üzerine gelme, tıklama, odak, yükleniyor ve devre dışı. Odak hâli özellikle önemli, çünkü klavyeyle gezinen kullanıcılar için tek yönlendirme odur ve sistemlerde en sık atlanan durum odur. Teslimde kütüphanenin yanına kısa bir yönetişim notu bırakıyoruz: değişiklik önerisini kim açar, kim onaylar, sürüm nereye yazılır. Bu tek sayfa, sistemin altı ay sonra hâlâ kullanılıyor olmasını belirleyen en somut parça. **Bir sistemin başarısı teslim gününde değil, altıncı ayda kaç dosyanın hâlâ kütüphaneye bağlı olduğunda görülür.** ## Sık Sorulan Sorular ### Marka sistemi ile tasarım sistemi aynı şey midir? Büyük ölçüde örtüşürler ama kapsamları farklıdır. Tasarım sistemi genellikle dijital arayüzü kapsar; marka sistemi bunun üzerine basılı materyal, ambalaj, mekân uygulamaları ve ses tonu gibi katmanları da ekler. Küçük ve orta ölçekli işletmelerde ikisi tek bir yapı olarak kurulur. ### Küçük bir işletmenin marka sistemine ihtiyacı var mı? Kapsamlı bir kütüphaneye değil ama asgari bir sisteme ihtiyacı vardır. Renk rolleri, tipografi ölçeği ve üç ile beş arasında hazır şablon, küçük bir işletmedeki tutarsızlığın büyük kısmını çözer. Sistem büyüdükçe genişletilir. ### Marka sistemi ne sıklıkla güncellenmeli? Takvime göre değil, ihtiyaca göre. Yeni bir kanal, yeni bir ürün tipi ya da tekrarlayan bir tasarım ihtiyacı ortaya çıktığında sistem genişletilir. Bunun dışında yılda bir kez envanter tekrarı yapıp sistemin dışına çıkmış kullanımları toplamak yeterlidir. ### Sistem yaratıcılığı kısıtlar mı? Kısıtladığı şey keyfîliktir, yaratıcılık değil. Renk ve tipografi gibi tekrar eden kararlar sabitlendiğinde, zaman ve dikkat fikir, kurgu ve anlatım tarafına kayar. Kampanyalara özel istisnalar ise sistemin içinde tanımlı bir alan olarak planlanabilir. ### Sistemi kurmak için hangi araçlar gerekir? Tasarım tarafında kütüphane ve değişken desteği olan bir araç (yaygın tercih Figma), kod tarafında ise CSS özel değişkenleri veya benzer bir token yapısı yeterlidir. Bileşenleri belgelemek için Storybook gibi araçlar kullanılabilir, ancak küçük ekiplerde iyi düzenlenmiş tek bir sayfa da iş görür. ### Sistemin sahibi kim olmalı? Tek bir kişi olmalı ve bu kişi tasarımcı olmak zorunda değil. Sahip, kararları toplayan, gözden geçirme ritmini işleten ve kaydı tutan kişidir. Küçük işletmelerde bu rol çoğu zaman pazarlamadan sorumlu kişiye ya da doğrudan kurucuya düşer; önemli olan rolün adı değil, tek bir adrese bağlı olması. ### Sistemi kurmak ne kadar sürer? Kapsamı siz belirlediğiniz için süre de büyük ölçüde sizin elinizde. Renk rolleri, tipografi ölçeği ve beş bileşenden oluşan çalışır bir ilk sürüm, çoğu küçük işletmede birkaç hafta içinde kurulabilir. Tam kapsamlı bir kütüphane ise aylara yayılır ve zaten tek seferde bitirilmesi hedeflenmemelidir. ### Ajans değiştirirsek sistem elimizde kalır mı? Ancak dosyaların mülkiyeti ve erişimi sizdeyse kalır. Sözleşmede kaynak dosyaların işletmeye ait olduğu, kütüphanenin işletmenin hesabında barındırıldığı ve yazı tipi lisanslarının işletme adına alındığı yazılı olmalıdır. Bu üç madde yoksa, elinizde sistem değil yalnızca çıktılar kalır.