Design Token ve Multi-Brand Dijital Ekosistemler İçin Web Altyapısı

Design token, bir tasarım kararını kodun anlayacağı “değişken” formatına dönüştürür. Renk paleti, font boyutu, spacing aralığı, border radius gibi kurallar token’lara taşındığında, UI “rastgele” değil “sistematik” olur. Token’lar, design system’in temel katmanıdır: komponentlerin nasıl görüneceğini token’lar belirler; komponentler de sayfaların nasıl görüneceğini.

Design token nedir, kurumsal/multi-brand sitelerde nasıl kullanılır?

Design token; renk, tipografi, spacing gibi stil kararlarını platform bağımsız biçimde tanımlayan, Figma ve kodda aynı isimlerle yaşayan değişkenlerdir. Multi-brand yapılarda token’lar “tema varyantı” olarak çoğalır: aynı component kütüphanesi, farklı token setleriyle farklı markalara uyarlanır. Böylece kopya tema/kod yerine tek sistemden yönetim sağlanır.

Mini Check

• •Token’lar “tasarım kararı”nı mı temsil ediyor, yoksa rastgele değerler mi?
• •Token isimlendirme standardı var mı?
• •Aynı component farklı markalarda “kopyalanmadan” çalışabilir mi?

Token’ları seviyelendirmezseniz sistem kısa sürede şişer. En iyi pratik: token’ı “ham değer”den “anlamlı karar”a doğru taşımak.

Core tokens (ham değerler)

• •Renk skalası: brand-500, neutral-900 vb.
• •Spacing scale: 4, 8, 12, 16…
• •Font scale: sm, md, lg, xl

Semantic tokens (anlam katmanı)

• •color.text.primary
• •color.bg.surface
• •color.action.primary
• •Bu katman, multi-brand’de asıl sihirli yerdir: her marka semantic token’ları farklı core değerlerle map eder.

Component tokens (bileşen kararları)

• •Button padding, radius, hover state
• •Card shadow, border
• •Form input focus ring
• •Bu katman, component library’nin stabil kalmasını sağlar.

Mini Check

• •Core ile semantic ayrılmış mı?
• •“Primary button” rengi her markada semantic token’dan mı geliyor?
• •Component token’ları dokümante mi?

Tek kod tabanı demek “tek tasarım” demek değildir. Amaç, aynı component kütüphanesini farklı token setleriyle giydirmek (theme variants). Böylece her markanın “farklılığı” korunurken, sistemin çekirdeği (component library + erişilebilirlik + performans) ortak kalır.

Marka A/B/C için varyantlar (theme variants)

• •Brand A: premium (daha geniş spacing, farklı typography)
• •Brand B: resort (daha canlı palette)
• •Brand C: business (daha sade)

Bu varyantlar “theme config” olarak yönetilir; sayfalar aynı komponentleri kullanır, sadece token seti değişir.

Competitor Gap – fark yaratan mini bölüm

TR’de multi-brand yapıların çoğu “tema kopyalama + ufak CSS oynama” ile çözülüyor. Bu kısa vadede hızlı gibi görünür; ama uzun vadede yeni marka ekleme süresi uzar, UI tutarsızlıkları artar ve bakım maliyeti yükselir. Token tabanlı sistem, kopya kodu azaltarak bu kaosu önler.

Mini Check

• •Yeni marka eklemek “kopyala-yapıştır” mı, yoksa “yeni token seti” mi?
• •Shared component library tek yerde mi?
• •Brand varyantları versioning ile yönetiliyor mu?

Otel gruplarında “marka” çoğu zaman yalnız logo değil; hedef kitle, konsept ve içerik dili de farklıdır. Token stratejisi, bu farkları UI’da yönetilebilir hale getirir.

Otel grupları için pratik token seti

• •brand.primary, brand.secondary
• •typography.heading, typography.body
• •radius.card, shadow.card
• •spacing.section, spacing.card

Mini örnek: Antalya’daki resort markası için daha sıcak palette; şehir oteli markası için daha minimal palette aynı component setiyle yönetilebilir.

Holding/B2B için pratik token seti

• •Ürün/dash ekranlarında okunabilirlik odaklı typography
• •Plan/fiyat kartlarında tutarlı grid
• •Case study bloklarında aynı yapı

Key Statistics / Data Point (sheet): Token tabanlı yaklaşıma geçen ekiplerde, yeni marka/otel ekleme süresi ve UI tutarsızlıkları anlamlı şekilde azalıyor. (Gözlemsel veri noktası olarak kullanıldı.)

Mini Check

• •Otel markalarında “konsept farkı” token setine yansıyor mu?
• •Holdingde ürün/dash sayfalarında typography standardı var mı?
• •Tek bir component setiyle farklı brand hissi verebiliyor musunuz?

Token sistemi sadece kodda yaşarsa, tasarım tarafında kopar. Sadece Figma’da yaşarsa, implementasyonda kopar. İdeal hedef: Figma ↔ kod token senkronu ve CMS’te marka teması seçimi.

Figma’daki token’ları koda nasıl aktarırım?

En iyi pratik; token’ları tek kaynakta (JSON gibi) tutup hem Figma hem kod tarafında bu kaynaktan üretmektir. Böylece renk/tipografi güncellemeleri iki tarafta da senkron kalır. Senkron bozulursa “tasarımda var, kodda yok” problemi büyür.

CMS tarafında marka teması yönetimini nasıl kurgularım?

CMS’te içerik, “brand” alanıyla etiketlenebilir; front-end bu etikete göre doğru token setini (theme) uygular. Böylece aynı içerik modeli, doğru markanın UI’ı ile sunulur. Bu yapı, multi-brand ekosistemde içerik operasyonunu hızlandırır ve tutarlılık sağlar.

Mini Check

• •Token’lar tek kaynaktan mı yönetiliyor?
• •CMS’te brand/tema seçimi alanı var mı?
• •Theme seçimi “sayfa bazında mı”, “site/brand bazında mı” net mi?

Token sistemi bir “ürün”dür: bakım, sürüm ve değişiklik yönetimi ister. Aksi halde token’lar çoğalır, isimler bozulur, component’ler farklılaşır.

Token değişikliği nasıl yönetilir?

• •Değişiklik tipi: minor (renk tonu) vs major (semantic mapping değişimi)
• •Deprecation: eski token’ı kaldırma planı
• •Release notları: hangi brand etkilendi?

Multi-brand governance (kısa çerçeve)

Token sistemi, style guide ve governance dokümanlarıyla birlikte yürümelidir. Bu yüzden UI/UX tasarım ve CMS entegrasyon içerikleriyle bağ önemlidir.

Mini Check

• •Token changelog’u var mı?
• •Yeni token ekleme kuralı var mı?
• •Brand A/B/C etkisi test ediliyor mu?

Çok markalı yapılarda sürdürülebilir web altyapısı, her siteyi ayrı ayrı kopyalamaktan değil; ortak component kütüphanesi, design token hiyerarşisi ve marka bazlı tema varyantlarından gelir. Bu yaklaşım, yeni marka ekleme süresini kısaltır, UI tutarsızlıklarını azaltır ve bakım maliyetini daha yönetilebilir hale getirir.

Otel grupları ve holding ekosistemlerinde design token sistemi yalnızca tasarım düzeni değil; Figma, kod, CMS, release ve governance süreçlerini birbirine bağlayan bir operasyon modelidir. Token’lar doğru seviyelendirilip versioning ile yönetildiğinde, tek kod tabanında farklı marka deneyimleri üretmek çok daha kontrollü ve ölçeklenebilir olur.