Tailwind CSS ile Kurumsal Kimlik ve Tema Yönetimi

Bir kurumsal arayüzde marka rengini değiştirmek kolaydır, fakat gerçek bir tema sisteminde iş yalnızca renkle bitmez. Font ailesi, boşluk düzeni, radius, gölge, ikon dili, hareket davranışları, logo varyantları, erişilebilirlik ve dark mode aynı kimliğin parçalarıdır. Tailwind CSS ile Kurumsal Kimlik ve Tema Yönetimi yaklaşımında asıl hedef, bu kararları yüzlerce component içine dağıtmak yerine merkezi bir token sistemine taşımaktır. Tailwind CSS v4 bu konuda CSS-first configuration, theme variables ve runtime CSS custom property kullanımını daha doğal hale getirerek özellikle multi-brand ve white-label projelerde güçlü bir temel sunar. Bu rehberde design token mimarisinden dark mode yönetimine, Figma senkronizasyonundan multi-tenant SaaS temalarına ve rebranding süreçlerine kadar kurumsal ölçekte sürdürülebilir bir model kuracağız.

Tailwind CSS ile Kurumsal Kimlik Yönetimi Nedir?

Tailwind CSS ile kurumsal kimlik yönetimi, markanın görsel kararlarını rastgele utility kombinasyonlarından çıkarıp kontrollü tasarım kurallarına bağlamak anlamına gelir. Amaç geliştiricilerin her ekranda farklı renk, padding veya radius seçmesi değil, önceden tanımlanmış token ve component kurallarını kullanmasıdır. Bu yaklaşım birden fazla uygulamanın aynı marka dilini korumasını kolaylaştırır. Rebranding sırasında yüzlerce component'i tek tek düzenlemek yerine merkezi semantic token'lar değiştirilir. Büyük ekiplerde asıl kazanç CSS yazma hızından çok tasarım kararlarının tutarlı, paylaşılabilir ve denetlenebilir hale gelmesidir.

Kurumsal Kimlik Neden Sadece Marka Renginden İbaret Değildir?

Bir markayı yalnızca ana renk üzerinden tanımlamak gerçek kullanıcı deneyiminin önemli bölümünü görmezden gelir. Kullanıcı bir ürünü font karakterinden, boşluk ritminden, köşe yapısından, gölge kullanımından ve animasyon hızından da tanır. İki uygulama aynı logoyu ve aynı mavi rengi kullansa bile biri sert köşeli ve yoğun, diğeri yuvarlak ve ferah tasarlanmışsa farklı marka hissi üretir. Bu nedenle kurumsal design system görsel dilin bütün tekrar eden kararlarını kapsamalıdır. Tailwind tarafında bu kararların mümkün olduğunca token ve tema değişkenlerine bağlanması component'lerin marka davranışından bağımsızlaşmasını sağlar.

Renk

Renk sistemi yalnızca logo renginden oluşmaz ve background, surface, foreground, border, status ve interaction renklerini birlikte kapsar. Ana marka rengi bir button üzerinde kullanılabilirken aynı değer geniş sayfa arka planı için uygun olmayabilir. Hover ve active durumlarının da rastgele koyulaştırılmış renklerle değil, önceden belirlenmiş bir ölçekle yönetilmesi gerekir. Light ve dark modda semantic anlam aynı kalırken gerçek renk değerleri değişebilir. Bu nedenle component içinde doğrudan belirli bir HEX değeri yazmak yerine primary, surface veya foreground gibi semantic token kullanmak uzun vadede daha güvenli sonuç verir.

Tipografi

Tipografi markanın tonunu kullanıcıya en sürekli aktaran öğelerden biridir çünkü neredeyse her ekranda bulunur. Kurumsal sistem font family dışında font size, weight, line-height ve letter-spacing kararlarını da merkezi hale getirmelidir. Heading, body, caption ve label gibi semantic typography rollerinin belirlenmesi tasarımcı ve geliştirici arasında ortak dil oluşturur. Bir rebranding sırasında ana font ailesi değiştiğinde component kodunun yeniden düzenlenmemesi hedeflenmelidir. Tailwind theme değişkenleri ve CSS custom properties bu değerlerin merkezi şekilde dağıtılmasını kolaylaştırır.

Spacing

Spacing görsel ritmi oluşturan ve çoğu zaman renk kadar fark edilmeyen fakat hissedilen bir marka öğesidir. Aynı component farklı geliştiriciler tarafından sürekli p-3, p-5 ve özel piksel değerleriyle yazılırsa sistem zaman içinde dağınık görünmeye başlar. Primitive spacing scale temel ölçüleri sunarken semantic token'lar card padding veya section gap gibi kullanım amaçlarını ifade edebilir. Böylece boşluk kararı geliştiricinin o anki tercihinden çıkar ve design system tarafından yönetilir. Kurumsal ürünlerde tutarlı spacing hem görsel kaliteyi hem de component reuse oranını yükseltir.

Border Radius

Border radius küçük bir CSS özelliği gibi görünse de marka karakteri üzerinde güçlü etkisi vardır. Keskin köşeler daha teknik veya resmi bir algı oluşturabilirken yüksek radius daha yumuşak ve dostça bir görünüm verebilir. Her component'in kendi radius kararını vermesi kurumsal kimliğin parçalanmasına neden olur. Bu nedenle radius-sm, radius-md veya semantic component token'ları üzerinden sınırlı bir ölçek oluşturmak daha sağlıklıdır. Marka sıfır radius kullanıyorsa bu karar yalnızca tasarım dokümanında değil, token sisteminde de zorunlu hale getirilebilir.

Shadow

Shadow yüzey hiyerarşisini ve component'lerin birbirine göre derinliğini anlatır. Bazı markalar yoğun elevation kullanırken bazı kurumsal tasarımlar neredeyse tamamen gölgesiz ve border tabanlı olabilir. Geliştiricilerin kendi blur ve opacity değerlerini üretmesi kısa sürede tutarsız yüzeyler oluşturur. Tasarım sistemi küçük ve anlamlı bir shadow scale tanımlamalıdır. Dark mode'da aynı gölge değerleri her zaman iyi çalışmadığı için shadow token'larının tema bağlamında ayrıca değerlendirilmesi gerekir.

Iconography

İkon sistemi stroke kalınlığı, köşe dili, dolu veya outline kullanımı ve boyut ölçeği açısından markayla uyumlu olmalıdır. Aynı uygulamada birbirinden farklı görsel dillere sahip ikon setleri kullanmak arayüz bütünlüğünü zayıflatır. SVG ikonlarda currentColor kullanımı renk davranışını semantic foreground token'larına bağlamayı kolaylaştırır. Böylece ikon component'inin marka rengini kendi içinde bilmesine gerek kalmaz. Tasarım sistemi ikon boyutları ve durum renkleri için de sınırlı, anlaşılır kurallar sunmalıdır.

Motion

Motion bir markanın kullanıcıya ne kadar hızlı, sakin veya enerjik hissettirdiğini etkileyebilir. Her component farklı duration ve easing kullandığında deneyim parçalı görünür. Duration, easing ve transition değerlerini token haline getirmek bu davranışı merkezi yönetilebilir yapar. Kullanıcıların azaltılmış hareket tercihleri de tasarım kararının ayrılmaz parçası olmalıdır. İyi motion sistemi dekoratif animasyon eklemekten çok kullanıcıya değişikliklerin nerede ve neden gerçekleştiğini anlaşılır biçimde göstermeyi hedefler.

Logo ve Görsel Varlıklar

Logo yönetimi multi-brand ve dark mode projelerinde yalnızca tek SVG dosyası import etmekten daha kapsamlıdır. Açık ve koyu zemin için farklı logo varyantları gerekebilir. White-label ürünlerde tenant'a göre tamamen farklı logo, favicon ve görsel varlık seti yüklenebilir. Component'in belirli marka dosya yolunu hard-code etmesi bu nedenle doğru değildir. Merkezi asset registry veya tenant configuration üzerinden varlık çözümleme yapmak marka değişikliklerini component kodundan ayırır.

Tailwind CSS'in Kurumsal Tasarım Sistemindeki Rolü

Tailwind CSS design system'ın kendisi değil, tasarım kararlarını geliştirici workflow'una taşıyan güçlü bir uygulama katmanıdır. Theme variables renk, typography, spacing ve benzeri değerlerin utility API'sine bağlanmasını sağlar. Component library ise bu token ve utility'leri daha yüksek seviyeli davranışlara dönüştürür. Governance, Figma token yönetimi ve accessibility gibi konular Tailwind dışında da süreç gerektirir. Kurumsal tasarım sistemi bu nedenle Tailwind'i merkezi kaynak olarak değil, ortak token modelinin web uygulamasındaki tüketicilerinden biri olarak konumlandırdığında daha esnek hale gelir.

Utility-First Yaklaşım Kurumsal Tutarlılığı Nasıl Sağlar?

Utility-first yaklaşımın temel avantajı component stilinin doğrudan markup yakınında görünür olmasıdır. Ancak kurumsal tutarlılık yalnızca utility kullanıldığı için otomatik oluşmaz. Eğer ekip sınırsız arbitrary value kullanıyorsa utility-first yapı da dağınık bir sisteme dönüşebilir. Tutarlılık, utility API'nin design token ve style guide tarafından sınırlandırılmasıyla sağlanır. Böylece geliştirici hızlı çalışırken yalnızca kurumun onayladığı renk, spacing, radius ve typography seçeneklerinden yararlanır.

Hard-Coded Stil Değerleri Neden Ölçeklenmez?

Hard-coded değerler küçük projede hızlı görünür fakat ürün büyüdükçe marka değişikliğini pahalı hale getirir. Onlarca dosyada aynı HEX renginin farklı yazımları bulunabilir ve hangi kullanımın gerçekten marka rengi olduğu anlaşılamayabilir. Arbitrary spacing ve radius değerleri de zamanla tasarım sisteminin görsel ritmini bozar. Semantic token kullanıldığında component yalnızca rolü bilir ve gerçek değer merkezi katmanda değişir. Rebranding, dark mode ve multi-brand desteğinin kolaylaşması için ilk adımlardan biri ham değerleri component seviyesinden çıkarmaktır.

Tailwind CSS v4 Tema Mimarisi Nasıl Çalışır?

Tailwind CSS v4, tema yapılandırmasını CSS'e daha yakın hale getiren CSS-first yaklaşımı kullanır. Güncel Tailwind dokümantasyonunda theme variables, @theme içinde tanımlanan ve hangi utility veya variant API'lerinin oluşacağını etkileyen özel CSS değişkenleri olarak açıklanır. Theme variable'lar aynı zamanda normal CSS custom property olarak çıktıda kullanılabildiği için runtime tema mimarileri açısından önemli avantaj sağlar. Bu model JavaScript configuration bağımlılığını azaltır fakat eski config dosyaları gerektiğinde uyumluluk amacıyla kullanılabilir. Kurumsal projede asıl önemli konu, hangi değerlerin Tailwind utility üretmesini gerektirdiğini ve hangilerinin yalnızca runtime CSS variable olarak kalacağını bilinçli biçimde ayırmaktır. :contentReference[oaicite:1]{index=1}

CSS-First Configuration Yaklaşımı

CSS-first configuration, tema ve utility genişletmelerinin büyük bölümünü doğrudan CSS içinde tanımlamayı mümkün hale getirir. Bu yaklaşım tasarım token'larının runtime CSS değişkenleriyle daha doğal biçimde birlikte çalışmasını sağlar. Kurumsal theme package ayrı bir CSS dosyası olarak monorepo içindeki farklı uygulamalar tarafından import edilebilir. Böylece JavaScript framework veya build configuration ayrıntıları tasarım token dağıtımının zorunlu parçası olmaktan çıkar. Tailwind v4'ün resmi dokümantasyonu eski JavaScript config dosyalarının hâlâ desteklenebildiğini, ancak otomatik algılanmadığını ve gerektiğinde @config ile açıkça yüklenmesi gerektiğini belirtiyor. :contentReference[oaicite:2]{index=2}

@theme Direktifi Nedir?

@theme, Tailwind'e belirli CSS custom property'lerinin framework theme variable'ı olduğunu bildirir. Örneğin --color-brand-500 tanımlandığında buna bağlı renk utility'leri üretilebilir. Bu nedenle @theme içinde tanımlanan değişkenler yalnızca normal CSS variable değildir ve Tailwind'in utility API'sini de şekillendirir. Tailwind'in güncel dokümantasyonu theme variable'ların üst seviyede tanımlanmasını ve başka selector veya media query içine yerleştirilmemesini gerektirir. Kurumsal sistemde @theme, geliştiricilerin utility olarak kullanması gereken primitive veya framework-facing token'ları tanımlamak için uygundur. :contentReference[oaicite:3]{index=3}

Theme Variable ile Normal CSS Variable Arasındaki Fark

Normal CSS variable tarayıcı tarafından runtime'da çözülen genel bir custom property'dir. Tailwind theme variable ise buna ek olarak utility ve variant üretimiyle ilişkilidir. Resmi dokümantasyon, utility üretmesi istenmeyen değişkenler için :root altında normal CSS variable kullanımının uygun olduğunu açıkça belirtir. Bu ayrım multi-brand sistemlerde çok değerlidir çünkü semantic runtime değişkenler :root veya [data-brand] altında tutulabilirken Tailwind-facing alias'lar @theme inline içinde tanımlanabilir. Böylece her tenant rengi için ayrı utility set üretmek yerine tek utility API farklı runtime değerlerine bağlanabilir. :contentReference[oaicite:4]{index=4}

@theme Ne Zaman Kullanılmalı?

Bir token Tailwind utility veya variant üretimini etkileyecekse @theme doğal seçimdir. Renk, font, spacing, radius, shadow ve breakpoint gibi framework API'sine bağlanan değerler bu kapsama girer. Örneğin özel --color-primary tanımı bg-primary ve text-primary gibi utility'lerin oluşmasını sağlayabilir. Yalnızca JavaScript veya custom CSS tarafından kullanılacak runtime değerin @theme içine konması gerekmeyebilir. Kurumsal modelde @theme katmanını mümkün olduğunca stabil tutmak ve tenant'a göre sürekli değişen değerleri normal custom property katmanında yönetmek çoğu zaman daha sade sonuç verir.

:root Ne Zaman Kullanılmalı?

:root utility üretmesini istemediğiniz global CSS custom property'leri için uygundur. Semantic runtime token'ları burada tanımlayıp marka veya dark mode selector'larında override etmek oldukça kullanışlıdır. Örneğin --ui-primary değeri :root altında tanımlanabilir ve [data-brand="b"] altında farklı değer alabilir. Ardından @theme inline içindeki --color-primary bu semantic değişkene bağlanabilir. Bu model component'lerin bg-primary kullanmaya devam etmesini ve gerçek marka renginin runtime'da değişmesini mümkün hale getirir. :contentReference[oaicite:5]{index=5}

Tailwind Theme Namespace'leri

Tailwind theme variable namespace'leri hangi değişken grubunun hangi utility veya variant ailesini oluşturacağını belirler. Güncel dokümantasyonda renk, font, text, font-weight, tracking, leading, breakpoint, container, spacing, radius, shadow, blur, ease ve animation dahil çok sayıda namespace bulunur. Bu yapı kurumsal token modelini Tailwind API'siyle sistematik biçimde eşleştirmeyi kolaylaştırır. Her design token'ın doğrudan Tailwind namespace'ine taşınması gerekmez ve semantic katmanın framework bağımsız kalması yararlı olabilir. Framework-facing mapping katmanı cross-platform token yapısının web tarafındaki adaptörü gibi çalışabilir. :contentReference[oaicite:6]{index=6}

--color-*

--color-* namespace'i Tailwind renk utility'lerinin temelini oluşturur. Özel bir color theme variable tanımlandığında background, text, border, fill ve benzeri renk utility'lerinde kullanılabilir. Kurumsal sistemde primitive palette değerleri bu namespace'e taşınabilir, ancak component'lerin doğrudan primitive isimleri kullanması zorunlu değildir. Semantic renkler de --color-primary veya --color-surface gibi isimlerle utility API'sine bağlanabilir. Marka değişiminin kolay olması için gerçek renk değerleriyle kullanım anlamı arasındaki ayrım korunmalıdır.

--font-*

--font-* namespace'i font family utility'lerini üretir. Kurumsal tasarımda font-brand, font-body veya font-display gibi anlamlı isimler tercih edilebilir. Multi-brand yapıda gerçek font ailesi runtime custom property üzerinden değiştirilebilir. Font dosyalarının yükleme performansı ayrıca planlanmalıdır çünkü her marka için bütün fontları aynı anda indirmek gereksiz maliyet oluşturabilir. Font token isimlerinin tasarım tarafındaki Figma variable veya token isimleriyle eşleşmesi bakım maliyetini azaltır.

--text-*

--text-* theme namespace'i font size utility'leriyle ilişkilidir. Kurumsal typography scale burada teknik boyut seviyelerini tanımlayabilir. Bunun üzerinde heading veya caption gibi semantic style kombinasyonları component veya custom utility seviyesinde oluşturulabilir. Font size tek başına typography stilini tamamlamadığı için line-height ve letter-spacing kararları da birlikte düşünülmelidir. Ölçeğin sınırlı tutulması uygulamanın her ekranında rastgele text size seçilmesini önler.

--spacing-*

--spacing-* namespace'i padding, margin, sizing ve gap gibi çok sayıda utility üzerinde etkili olabilir. Bu nedenle spacing scale'de yapılan değişiklik geniş çaplı görsel etki oluşturabilir. Kurumsal sistemde temel grid yaklaşımıyla uyumlu sınırlı bir scale tercih edilmelidir. Component-specific spacing ihtiyaçları semantic component token katmanında tutulabilir. Arbitrary değerlerin yoğun kullanımı bu merkezi scale'in değerini azaltacağı için linting ile takip edilmesi yararlı olur.

--radius-*

--radius-* namespace'i border radius utility'lerini kontrol eder. Marka sert ve köşeli bir görsel dil kullanıyorsa bütün ölçek daha düşük değerlere çekilebilir. Daha yumuşak bir marka için aynı semantic component'ler farklı radius değerleri alabilir. Component'in doğrudan rounded-[13px] gibi değer kullanması rebranding maliyetini yükseltir. Radius değerleri marka kimliğinin gerçek token'larından biri olarak değerlendirilmelidir.

--shadow-*

--shadow-* box shadow utility'lerini kurumsal elevation scale'e bağlamayı sağlar. Bir tasarım sistemi birkaç açık seviye belirleyerek yüzeylerin ilişkisini daha anlaşılır hale getirebilir. Light ve dark mode için aynı gölge fiziksel olarak aynı algıyı yaratmayabilir. Semantic surface veya component token katmanı gerektiğinde mode bazlı shadow override sağlayabilir. Shadow-free marka için değerler merkezi olarak sıfırlanabilir ve component koduna müdahale edilmeden yeni kimlik uygulanabilir.

--breakpoint-*

--breakpoint-* namespace'i responsive variant'ların hangi eşiklerde etkinleşeceğini belirler. Kurumsal breakpoint sistemi yalnızca tasarım aracındaki popüler cihaz genişliklerini kopyalamamalıdır. Layout'un gerçekten kırıldığı noktalar ve ürünün kullanım koşulları değerlendirilmelidir. Design system component'lerinde container queries kullanıldığında global viewport breakpoint bağımlılığı azaltılabilir. Tailwind theme değişkenlerinin responsive variant'larla doğrudan ilişkili olması breakpoint kararlarını da tema API'sinin parçası haline getirir. :contentReference[oaicite:7]{index=7}

@theme, @theme inline ve @theme static Arasındaki Fark

Bu üç kullanım aynı tema sisteminin farklı ihtiyaçlarını çözer ve özellikle runtime multi-brand tasarımında doğru ayrım önemlidir. Standart @theme Tailwind utility üretimine bağlanan theme variable'ları tanımlar. @theme inline, başka custom property'lere referans veren theme variable'larda utility'nin referansı ara theme variable yerine doğrudan hedef değere bağlamasını sağlar. @theme static ise kullanılmayan theme variable'ların da final CSS çıktısında üretilmesini ister. Kurumsal tema paketinde bu davranışları bilinçli kullanmak runtime override, package paylaşımı ve derlenmiş CSS boyutu arasındaki dengeyi kontrol etmeye yardımcı olur. :contentReference[oaicite:8]{index=8}

Standart @theme Nasıl Çalışır?

Standart @theme içinde tanımlanan değişkenler Tailwind'in utility ve variant sistemine katılır. Örneğin color namespace altındaki theme variable uygun renk utility'lerinin oluşmasına imkan verir. Tailwind ayrıca bu theme variable'ları CSS custom property olarak kullanıma açar. Varsayılan üretim davranışında gerçekten kullanılan değerler final CSS açısından önemlidir. Kurumsal projede standard @theme stabil primitive scale ve framework-level token tanımlarında kullanılabilir.

@theme inline Ne Yapar?

@theme inline, bir theme variable başka CSS variable'a referans verdiğinde utility'nin değer zincirini daha güvenilir biçimde kurmak için kullanılır. Tailwind dokümantasyonu özellikle CSS variable resolution kapsamı nedeniyle başka değişkene referans verirken inline seçeneğini önerir. Bu kullanım multi-brand semantic alias modeli için oldukça değerlidir. Örneğin Tailwind'in --color-primary theme variable'ı runtime'da değişebilen --brand-primary custom property'ye bağlanabilir. Component yalnızca bg-primary kullanır ve marka seçimi component katmanına taşınmaz. :contentReference[oaicite:9]{index=9}

Başka CSS Değişkenlerine Alias Vermek

Alias yaklaşımında Tailwind-facing token gerçek rengi kendi içinde saklamak yerine başka semantic variable'a referans verir. Bu yöntem design token hiyerarşisindeki primitive ve semantic katmanı CSS tarafında yansıtabilir. Örneğin --color-primary değerini var(--semantic-primary) üzerinden bağlamak mümkündür. Marka değiştiğinde yalnızca --semantic-primary override edilir. Component, utility veya markup üzerinde marka adını değiştirmek gerekmez.

Runtime Override'ın Hangi Değişkene Uygulandığını Anlamak

Runtime tema değiştirirken hangi custom property'nin gerçekten utility tarafından okunduğunu bilmek önemlidir. Alias zinciri yanlış kurulursa marka selector'ında yapılan override final component'e yansımayabilir. Bu nedenle browser developer tools ile computed style zinciri incelenmelidir. Derlenmiş utility'nin doğrudan hangi CSS variable'a referans verdiği kontrol edilmelidir. Özellikle @theme inline kullanımı bu noktada utility'nin hedef runtime variable'a nasıl bağlandığını netleştirir.

@theme static Ne Zaman Kullanılmalı?

@theme static, tanımlanan bütün theme variable'ların kullanılan utility bulunmasa bile final çıktıda yer almasını istediğiniz durumlarda yararlıdır. Resmi Tailwind dokümantasyonu varsayılan olarak yalnızca kullanılan CSS değişkenlerinin çıktıda üretildiğini, static seçeneğinin ise tamamını üretmek için kullanılabileceğini belirtiyor. Paylaşılan theme package başka custom CSS veya runtime JavaScript tarafından token değerlerine doğrudan erişecekse bu davranış anlamlı olabilir. Buna karşılık gereksiz binlerce token üretmek CSS boyutunu artırabilir. Bu nedenle static kullanımını bütün projeye varsayılan yapmak yerine token tüketim modeline göre seçmek daha sağlıklıdır. :contentReference[oaicite:10]{index=10}

Runtime Theme Switching İçin Doğru Modeli Seçmek

Runtime switching için en sade model çoğu zaman semantic normal CSS variable'ları selector bazında değiştirmek ve Tailwind utility'lerini bu semantic katmana bağlamaktır. Brand ve color scheme ayrı data attribute'larıyla temsil edilebilir. Tailwind build bütün marka kombinasyonlarını ayrı ayrı üretmek zorunda kalmaz. JavaScript yalnızca root attribute veya kontrollü custom property set'ini değiştirir. Tema davranışının büyük bölümü CSS cascade tarafından yönetildiği için component kodu daha sade kalır.

Derlenmiş CSS'i İnceleyerek Tema Davranışını Doğrulamak

Theme architecture tasarım kağıdı üzerinde doğru görünse bile final build'in nasıl üretildiği mutlaka kontrol edilmelidir. Utility'nin hangi variable'a referans verdiği, kullanılmayan token'ın çıktıda olup olmadığı ve selector cascade sırası derlenmiş CSS üzerinde görülebilir. Browser computed styles runtime override'ın gerçekten çalışıp çalışmadığını gösterir. Production minification öncesi ve sonrası build karşılaştırması da faydalı olabilir. Tema sorunlarında yalnızca source CSS'e bakmak yerine final cascade ve computed value zincirini incelemek çoğu zaman en hızlı teşhis yöntemidir.

Design Token Nedir?

Design token, tekrar eden tasarım kararını isimlendirilmiş ve taşınabilir bir veri olarak temsil eder. Bir renk kodunun yalnızca #1455ff olması yerine color.action.primary gibi anlamlı bir token üzerinden kullanılması buna örnektir. Token'lar renk dışında spacing, typography, shadow, radius ve motion değerlerini de kapsar. Kurumsal tasarımda amaç, tasarımcı ve geliştiricinin aynı kavramları farklı isimlerle tekrar üretmesini önlemektir. Token sistemi ne kadar iyi yapılandırılırsa rebranding, multi-platform dağıtım ve accessibility kontrolü o kadar merkezi hale gelir.

Design Token'ın Kurumsal Kimlikteki Rolü

Design token marka kararlarını component dosyalarının içinden çıkarıp yönetilebilir veri modeline taşır. Bu sayede aynı semantic karar web, mobil ve tasarım aracında farklı teknik çıktılarla temsil edilebilir. Örneğin primary action rengi bir web CSS variable, iOS color asset ve Android resource olarak üretilebilir. Marka değişikliğinde component logic değişmeden token değeri güncellenir. Token'lar bu nedenle kurumsal kimliğin yalnızca dokümantasyonu değil, çalıştırılabilir uygulama kontratı gibi davranır.

Token Kullanmak ile CSS Variable Kullanmak Aynı Şey midir?

Her CSS variable bir design token olmak zorunda değildir ve her design token yalnızca CSS variable olarak yaşamak zorunda değildir. Token daha yüksek seviyeli tasarım kararıdır, CSS variable ise web platformundaki uygulama yöntemlerinden biridir. Aynı token JSON kaynak dosyasından CSS, Swift ve Android çıktısına dönüştürülebilir. Ayrıca geçici layout hesaplamalarında kullanılan custom property'lerin tasarım sisteminde karşılığı bulunmayabilir. Bu ayrım cross-platform kurumlarda token modelini Tailwind veya CSS'e aşırı bağlamayı önler.

Single Source of Truth Yaklaşımı

Single Source of Truth, aynı tasarım kararının Figma, CSS ve mobil projelerde ayrı ayrı manuel düzenlenmemesini hedefler. Merkezi token kaynağı değişikliğin kontrollü biçimde farklı platformlara dağıtılmasını sağlar. Bu kaynak JSON repository, design token platformu veya belirlenmiş başka bir sistem olabilir. Önemli olan hangi sistemin yetkili kaynak olduğunun ekip tarafından bilinmesidir. İki farklı taraf aynı token değerini bağımsız güncelliyorsa senkronizasyon problemi kaçınılmaz hale gelir.

Tasarımcı ve Geliştirici Arasında Ortak Dil Oluşturmak

Token isimleri tasarımcı ve geliştirici için ortak konuşma dili oluşturabilir. “Şu maviyi biraz koyulaştıralım” yerine “primary action hover token'ını güncelleyelim” denildiğinde kapsam daha net olur. Figma variable isimleri ile kod tarafındaki semantic token isimleri yakın tutulursa handoff maliyeti azalır. Component review sırasında hangi tasarım kararının kullanıldığı kolayca görülür. Ortak dil yalnızca araç entegrasyonu değil, ekiplerin aynı kavramsal model üzerinden çalışması açısından da değerlidir.

Kurumsal Bir Design Token Hiyerarşisi Nasıl Kurulur?

Kurumsal token sistemi bütün değerleri tek düz listede tutmak yerine farklı anlam seviyelerine ayırdığında daha kolay yönetilir. Primitive token'lar ham tasarım değerlerini, semantic token'lar kullanım amacını, component token'ları ise belirli component kararlarını temsil eder. Her proje üç katmanın tamamına ihtiyaç duymayabilir. Büyük multi-brand yapılarda bu katman ayrımı marka ile component arasındaki bağı ciddi ölçüde azaltır. Zincir ne kadar açık olursa bir değerin neden değiştiği ve hangi yüzeyleri etkileyeceği o kadar kolay anlaşılır.

Primitive Tokens

Primitive token'lar henüz kullanım amacı taşımayan temel tasarım değerleridir. Renk skalaları, ham spacing ölçüleri ve font size seviyeleri bu gruba girer. Örneğin blue.600 veya space.4 primitive olabilir. Component'in doğrudan primitive kullanması bazı basit sistemlerde kabul edilebilir fakat multi-brand yapıda semantic katman daha esnek olur. Primitive token değiştiğinde onu referans alan bütün semantic rollerin etkilenebileceği unutulmamalıdır.

Ham Renkler

Ham renk token'ları marka veya neutral paletin doğrudan renk değerlerini tutar. Örneğin belirli bir OKLCH ton skalası primitive color set olarak tanımlanabilir. Bu değerlerin isimleri kullanım amacını ifade etmek zorunda değildir. Primary action'ın hangi ham rengi kullandığı semantic katmanda belirlenir. Böylece marka değiştiğinde primary rolü başka primitive renge bağlanabilir ve component kodu etkilenmez.

Ham Spacing Değerleri

Primitive spacing token'ları temel ölçü skalasını tanımlar. Dört piksel tabanlı sistemde 4, 8, 12, 16 gibi ritmik değerler bulunabilir. Semantic spacing token daha sonra card padding veya form gap için bu değerleri referans alır. Böylece temel scale korunurken kullanım anlamı ayrı katmanda yönetilir. Ekip arbitrary değer eklemek istediğinde gerçekten yeni primitive gerekip gerekmediğini değerlendirebilir.

Ham Typography Değerleri

Font size, line-height ve font weight gibi temel ölçüler primitive typography token olarak tutulabilir. Bunlar doğrudan “heading” veya “body” anlamı taşımaz. Semantic typography style farklı primitive değerleri kombinleyerek ürün dilini oluşturur. Bir markanın heading ağırlığı değiştiğinde semantic alias güncellenebilir. Bu yapı variable font axis kullanımı gibi ileri typography ihtiyaçlarını da daha kontrollü hale getirir.

Semantic Tokens

Semantic token gerçek değerden çok kullanım anlamını ifade eder. background, foreground, primary veya danger gibi isimler bu gruba örnektir. Light ve dark mode değiştiğinde semantic anlam korunur fakat referans verilen primitive değer değişebilir. Multi-brand sistemde her marka aynı semantic kontratı farklı renk paletiyle doldurur. Component'lerin büyük bölümünün doğrudan semantic token kullanması rebranding ve tema yönetimini önemli ölçüde kolaylaştırır.

Background

Background token sayfanın veya geniş layout yüzeyinin temel arka planını ifade eder. Light modda açık neutral, dark modda koyu neutral primitive'e bağlanabilir. Marka rengiyle doğrudan eş anlamlı değildir. Background üzerinde kullanılacak foreground token ayrıca tanımlanmalıdır. Bu ayrım erişilebilir contrast tasarımını daha kontrollü hale getirir.

Surface

Surface card, panel ve modal gibi sayfa üzerinde yükselen veya ayrışan yüzeyleri temsil eder. Background ile aynı renkte olabilir fakat semantic olarak ayrı tutulması ileride tema değişikliğine esneklik sağlar. Dark mode'da elevation yalnızca shadow yerine farklı surface tonlarıyla anlatılabilir. Multi-brand sistemde bazı markalar daha yüksek tonal fark kullanabilir. Component yalnızca surface rolünü bildiği için gerçek palette kararına bağlanmaz.

Foreground

Foreground temel text ve icon rengini temsil eder. Background veya surface ile birlikte contrast çifti olarak değerlendirilmelidir. Light modda koyu, dark modda açık primitive kullanabilir. Muted foreground için ayrı semantic token gerekebilir. Text rengini her component'te gray-900 gibi primitive seviyede sabitlemek tema değişimini zorlaştırır.

Primary Action

Primary action kullanıcının ana işlem çağrısını temsil eder. Brand palette içindeki belirli tonla eşleşebilir fakat semantic rol marka değişse de aynı kalır. Hover, active ve disabled durumları ayrı token ailesi olarak tanımlanabilir. Primary background üzerinde kullanılacak foreground token ayrıca belirlenmelidir. Bu model button, link ve seçili navigation gibi farklı component'lerde aynı interaction dilini korumayı kolaylaştırır.

Border

Border token divider, input ve container sınırlarında kullanılan genel çizgi rengini temsil eder. Tek border token bütün durumları karşılamayabilir ve subtle, strong veya focus border varyantları gerekebilir. Dark mode'da aynı opacity ve renk algısı farklı sonuç verebilir. Bu nedenle border değerleri semantic mode override üzerinden değiştirilebilir. Component'in doğrudan neutral palette tonuna bağlanması yerine border rolünü kullanması daha dayanıklı model oluşturur.

Success

Success semantic token olumlu işlem sonucu, tamamlanmış durum veya başarılı doğrulama gibi anlamları taşır. Sadece yeşil renk seçmek yeterli değildir ve foreground, background ve border varyantları birlikte düşünülmelidir. Renk körlüğü nedeniyle yalnızca renk üzerinden durum anlatılmamalıdır. İkon ve metin desteği sağlanmalıdır. Light ve dark mode contrast testleri ayrı yapılmalıdır.

Warning

Warning dikkat gerektiren fakat doğrudan hata olmayan durumları ifade eder. Sarı veya amber tonları sık kullanılsa da gerçek renk markaya ve contrast ihtiyacına göre değişebilir. Warning surface üzerinde readable foreground için ayrı token gerekir. Icon ve text ile anlam desteklenmelidir. Semantic isim component'i belirli renk ailesine bağımlı olmaktan kurtarır.

Danger

Danger hata, destructive action veya kritik risk durumlarını temsil eder. Delete button ve error alert aynı semantic aileden farklı component token'lar kullanabilir. Strong ve subtle danger surface ayrımı yararlı olabilir. Foreground contrast özellikle açık kırmızı yüzeylerde kontrol edilmelidir. Component içinde doğrudan red palette kullanmak yerine danger token kullanmak tema ve brand değişimini kolaylaştırır.

Component Tokens

Component token belirli UI component'inin tasarım kararını semantic katmanın üzerinde temsil eder. Büyük design system'lerde button background veya input border gibi değerler burada yönetilebilir. Her küçük component property için token üretmek ise gereksiz yönetim yükü oluşturabilir. Component token özellikle aynı semantic role rağmen component'e özel farklılık gerekiyorsa değerlidir. Kurum token derinliğini gerçek değişim ve varyasyon ihtiyacına göre seçmelidir.

Button Background

Button background token primary action semantic rengine referans verebilir. Böylece ileride button'ın diğer primary yüzeylerden farklı tona ihtiyaç duyması durumunda component kodu değişmeden token bağlantısı güncellenir. Hover ve active durumları component token set'inde açıkça tanımlanabilir. Multi-brand marka dosyası semantic primary değerini değiştirirken component layer aynı kalabilir. Bu separation özellikle büyük component library'lerde tasarım evrimini daha kontrollü hale getirir.

Card Surface

Card surface genel surface token'ına bağlanabilir veya özel elevation surface kullanabilir. Border ve shadow kararı da card component token set'ine eklenebilir. Böylece marka A shadow kullanırken marka B yalnızca border ile aynı card component'ini çalıştırabilir. Component markup marka isminden habersiz kalır. Theme matrix testleri card'ın bütün brand ve mode kombinasyonlarında doğru göründüğünü doğrular.

Input Border

Input border default, hover, focus, invalid ve disabled durumlarında farklı semantic kaynaklara bağlanabilir. Focus durumunun yalnızca renk değil outline veya ring davranışıyla birlikte tasarlanması gerekir. Accessibility için focus görünürlüğü korunmalıdır. Component token bu state mapping'i tek noktada toplar. Uygulama ekranı geliştiricisi her form alanında tekrar border renk seçmek zorunda kalmaz.

Navigation Active State

Navigation active state seçili sayfa veya menü öğesini görsel olarak ayırır. Background, foreground ve indicator token'ları ayrı olabilir. Marka rengi doğrudan component içinde kullanılmaz ve active semantic role üzerinden çözülür. Dark mode'da active background daha subtle bir tona çevrilebilir. Bu yaklaşım navigation component'inin bütün product ve brand varyantlarında aynı davranış mantığını korumasını sağlar.

Primitive → Semantic → Component Zinciri

Bu zincirde primitive gerçek değeri, semantic kullanım anlamını ve component token bağlamsal uygulamayı temsil eder. Örneğin ham mavi ton blue.600, semantic olarak action.primary ve component katmanında button.primary.background şeklinde bağlanabilir. Rebranding sırasında primitive ve semantic mapping değişirken button kodu aynı kalır. Dark mode semantic mapping'i farklı primitive'e yönlendirebilir. Zincirin amacı her projeyi çok katmanlı hale getirmek değil, değişikliklerin doğru seviyede yapılmasını sağlamaktır.

Hangi Projede Kaç Token Katmanı Kullanılmalı?

Küçük tek markalı uygulamada primitive ve semantic olmak üzere iki katman yeterli olabilir. Büyük component library ve birden fazla marka bulunan kurumda component token katmanı ek esneklik sağlar. Her CSS property için component token üretmek yönetimi zorlaştırır ve anlamı azaltır. Token ancak değişim, reuse veya governance değeri sağlıyorsa eklenmelidir. Sistem büyüdükçe katman eklemek mümkündür, bu nedenle başlangıçta gereğinden fazla soyutlama yapmak zorunlu değildir.

Token İsimlendirme Stratejisi

Token isimleri uzun vadeli tema yönetiminin en önemli mimari kararlarından biridir. Değere göre verilen isimler ilk gün anlaşılır görünür fakat rebranding ve dark mode sırasında anlamını kaybedebilir. Semantic isimler token'ın neden kullanıldığını ifade eder ve gerçek değer değişse bile stabil kalır. Marka adı da component kodundan mümkün olduğunca uzak tutulmalıdır. Naming convention yazılı hale getirilirse yeni token ekleyen farklı ekipler aynı dil üzerinde çalışabilir.

Değere Göre İsimlendirme Neden Sorunludur?

Değer odaklı isim token'ın ne için kullanıldığını değil o anda hangi görsel değeri taşıdığını anlatır. blue-500 bugün primary action olabilir fakat rebranding sonrasında primary renk turuncuya dönebilir. Component kodunda yüzlerce blue-500 kullanımının hangisinin marka amaçlı olduğunu belirlemek zorlaşır. Primitive palette seviyesinde değer odaklı isim kabul edilebilir. Ancak consumer component'lerde semantic isim kullanmak rebranding maliyetini azaltır.

blue-500

blue-500 primitive palette adı olarak faydalıdır çünkü belirli renk skalasındaki konumu ifade eder. Sorun bu token'ın doğrudan button, navigation ve badge gibi bütün component'lerde kullanılmaya başlamasıdır. Böyle bir durumda görsel değerin business anlamı kodda görünmez hale gelir. Marka rengi değiştiğinde bütün blue kullanımlarının aynı şekilde değişip değişmeyeceği bilinmez. Bu nedenle primitive token semantic alias arkasında tutulmalıdır.

gray-100

gray-100 neutral palette içindeki ham tonu ifade etmek için uygundur. Ancak card background, disabled state ve border aynı primitive'i kullanıyor olabilir. Dark mode'da bu üç semantic rolün farklı koyu tonlara gitmesi gerekebilir. Component doğrudan gray token'a bağlıysa bu ayrım zorlaşır. Semantic surface, disabled ve border token'ları aynı primitive'i referans alsa bile bağımsız roller olarak tanımlanmalıdır.

Anlama Göre İsimlendirme

Semantic naming token'ın kullanım rolünü ifade eder. primary, surface, foreground ve destructive gibi isimler gerçek renk değerinden bağımsızdır. Light mode veya başka marka aynı rol için farklı primitive seçebilir. Component yalnızca anlamı kullandığı için tema mantığı markup içine sızmaz. Semantic isimlendirme tasarımcı ve geliştiricinin aynı kavramlar üzerinden konuşmasını da kolaylaştırır.

primary

primary ürünün temel accent veya ana action rolünü temsil edebilir. Bu ismin tam anlamı naming convention belgesinde açıkça tanımlanmalıdır. Bazı sistemlerde primary brand rengini, bazılarında yalnızca interactive action rengini ifade eder. Belirsiz semantic token isimleri farklı ekiplerde farklı yorumlanabilir. Tanım ve kullanım örnekleri bu nedenle token kadar önemlidir.

surface

surface card, panel veya menu gibi arka planın üzerinde yer alan yüzeyleri temsil edebilir. Background ile aynı primitive'i kullanması semantic ayrımı gereksiz yapmaz. İleride dark mode veya elevation sistemi değiştiğinde surface bağımsız override edilebilir. Subtle ve elevated surface varyantları gerekebilir. Component'lerin hangi surface seviyesini kullanacağı design system documentation'da gösterilmelidir.

foreground

foreground yüzey üzerinde temel okunabilir içerik rengini ifade eder. Text ve icon bu token'ı paylaşabilir. Muted ve subtle foreground ayrı semantic seviye olarak tanımlanabilir. Dark mode'da foreground otomatik olarak açık tona bağlanır. Component'in özel dark utility yazmasına ihtiyaç önemli ölçüde azalır.

destructive

destructive geri dönüşü zor veya riskli işlemleri ifade eder. Rengi kırmızı olmak zorunda değildir, ancak kullanıcı beklentileri ve erişilebilirlik birlikte değerlendirilmelidir. Delete, revoke veya reset gibi action'lar bu semantic role bağlanabilir. Background ve foreground çiftleri ayrı token olabilir. Bu isim component'in gerçek palette değerine değil davranış anlamına bağlı kalmasını sağlar.

Marka İsmini Component Kodundan Ayırmak

Component class veya prop içinde marka adı bulunması multi-brand yapıyı hızla zorlaştırır. brandAButton veya text-companyBlue gibi kullanımlar ortak component library'nin reuse değerini düşürür. Component primary, surface ve foreground gibi semantic rolleri kullanmalıdır. Marka mapping root theme layer'da çözülmelidir. Böylece yeni marka eklendiğinde component koduna özel koşul eklemek gerekmez.

Semantic Naming Rebranding'i Nasıl Kolaylaştırır?

Rebranding sırasında eski primary rengin yerine tamamen farklı palette kullanılabilir. Component'ler semantic token kullanıyorsa değişiklik merkezi mapping seviyesinde yapılır. Surface, border ve typography token'ları da aynı şekilde yeni kimliğe yönlendirilebilir. Kod arayıp eski HEX değerlerini tek tek değiştirme ihtiyacı azalır. Visual regression testleri yeni mapping'in bütün component'lerde beklenen sonucu verdiğini kontrol eder.

Token Naming Convention Belgesi Oluşturmak

Naming convention hangi token seviyelerinin bulunduğunu ve isimlerin nasıl oluşturulacağını açıklar. Primitive, semantic ve component token örnekleri belgeye eklenmelidir. Yasaklanan belirsiz isimler de örneklenebilir. Yeni token request'i bu standarda göre review edilir. Belge yalnızca tasarım ekibinde kalmamalı ve kod repository'siyle birlikte erişilebilir olmalıdır.

Kurumsal Renk Sistemi Nasıl Tasarlanır?

Kurumsal renk sistemi marka palette, neutral tonlar, durum renkleri ve interactive state'lerden oluşur. Her rengin yalnızca görsel değeri değil, nerede kullanılacağı ve hangi foreground ile eşleşeceği de tanımlanmalıdır. Dark mode için semantic mapping ayrıca test edilmelidir. Brand palette ile success veya danger gibi semantic palette birbirine karıştırılmamalıdır. Token katmanı bu farklı rolleri merkezi ve ölçülebilir hale getirir.

Brand Palette

Brand palette kurumun temel görsel karakterini taşıyan renk ailesidir. Ana accent rengi ve gerektiğinde destekleyici secondary renkler bulunabilir. Tek HEX yerine kullanım ihtiyaçlarını karşılayacak ton skalası oluşturmak interaction state'leri kolaylaştırır. Her tonun component tarafından doğrudan kullanılması yerine semantic role mapping yapılmalıdır. Brand palette marketing ve product UI kullanımında farklı yoğunluklara ihtiyaç duyabilir.

Neutral Palette

Neutral palette background, surface, border ve text hiyerarşisinin önemli bölümünü taşır. Çoğu ürün ekranında brand renginden daha fazla neutral renk kullanılır. Neutral tonların temperature ve chroma karakteri marka algısını etkileyebilir. Dark palette basitçe light palette'in tersine çevrilmesi olmamalıdır. Surface ayrımları ve text contrast gerçek ekranlar üzerinde test edilmelidir.

Semantic / Status Palette

Success, warning, danger ve information gibi durum renkleri semantic palette'i oluşturur. Her durum için yalnızca tek renk değil, background, border ve foreground eşleşmesi gerekebilir. Renk tek başına mesaj taşımamalıdır. Icon, text ve gerektiğinde şekil farklılıkları anlamı desteklemelidir. Brand palette ile status palette çakıştığında semantic okunabilirlik öncelikli olmalıdır.

Surface Renkleri

Surface renkleri sayfa, card, modal ve overlay gibi farklı yüzey seviyelerini ayırır. Light theme'de beyaza yakın tonlar kullanılabilirken dark theme'de hafif luminance farkları elevation hissi verebilir. Her yüzeye ayrı keyfi renk üretmek yerine sınırlı surface hierarchy belirlemek daha tutarlı sonuç verir. Border ve shadow sistemi bu hiyerarşiyle uyumlu olmalıdır. Semantic surface token'ları multi-brand modellerde genellikle marka accent'inden daha stabil tutulabilir.

Interactive Renkler

Interactive renk seti kullanıcının hover, active, focus ve disabled gibi durumları ayırt etmesini sağlar. Bu state'ler yalnızca görsel süs değil, component'in davranış geri bildirimidir. Tonlar palette içinde sistematik ilişki taşımalıdır. Pointer olmayan cihazlarda hover davranışının bulunmadığı unutulmamalıdır. Focus state özellikle klavye erişilebilirliği için ayrı ve yüksek görünürlüklü biçimde tasarlanmalıdır.

Default

Default interaction state component'in normal, işlem beklemeyen görünümüdür. Primary button için semantic action rengi burada kullanılır. Default foreground ve background contrast yeterli olmalıdır. Disabled veya selected state ile kolay karışmamalıdır. Tasarım sisteminde bu durum bütün interactive component'lerde tutarlı başlangıç davranışı sağlamalıdır.

Hover

Hover kullanıcı pointer ile component üzerine geldiğinde ek geri bildirim sağlar. Ton farkı fark edilebilir olmalı fakat component'in tamamen farklı semantic role geçmesine neden olmamalıdır. color-mix() veya belirli palette adımıyla sistematik renk türetilebilir. Touch cihazlarda hover'a bağımlı bilgi verilmemelidir. Hover contrast'ı da normal state kadar erişilebilir olmalıdır.

Active

Active state kullanıcı component'i basarken veya seçili interaction anında gösterilen durumdur. Hover'dan daha güçlü tonal değişiklik tercih edilebilir. Motion ve scale kullanılıyorsa reduced-motion tercihi düşünülmelidir. Active state selected state ile kavramsal olarak karıştırılmamalıdır. Token isimlerinde bu ayrım açık tutulmalıdır.

Focus

Focus state klavye ve yardımcı teknoloji kullanan kullanıcılar için kritik yönlendirme sağlar. Sadece background rengini hafif değiştirmek çoğu zaman yeterli değildir. Outline veya ring yüksek görünürlük sağlamalıdır. focus-visible pointer ve keyboard deneyimini daha dengeli yönetmek için kullanılabilir. Focus token'ları bütün brand ve theme kombinasyonlarında contrast testinden geçmelidir.

Disabled

Disabled state component'in geçici olarak etkileşime kapalı olduğunu gösterir. Yalnızca opacity düşürmek bazı durumlarda text readability sorununa yol açabilir. Disabled foreground ve background token'ları ayrı tanımlanabilir. Kullanıcıya neden disabled olduğu gerektiğinde açıklanmalıdır. Disabled kontrol keyboard focus davranışı açısından HTML semantics ile uyumlu uygulanmalıdır.

Foreground / Background Renk Çiftleri

Background rengini tek başına tokenlaştırmak contrast problemini tamamen çözmez. Her önemli surface veya action için uygun foreground eşleşmesi düşünülmelidir. on-primary, on-danger veya surface-foreground gibi token'lar bu ilişkiyi açık hale getirir. Multi-brand sistemde marka rengi çok açık veya çok koyu olabilir ve sabit beyaz text her zaman çalışmaz. Pair token yaklaşımı accessibility kararını component kodundan merkezi tema katmanına taşır.

OKLCH ile Kurumsal Renk Paleti Oluşturmak

OKLCH renk uzayı lightness, chroma ve hue bileşenleri üzerinden algısal olarak daha anlamlı palette üretmeye yardımcı olabilir. Modern CSS desteği sayesinde web theme token'larında doğrudan kullanılabilir. Aynı lightness adımları HSL veya RGB tabanlı türetmelere göre daha tutarlı görsel sonuç verebilir. Buna rağmen marka palette'i yalnızca matematiksel formülle üretmek yeterli değildir. Gerçek ekran, contrast ve brand perception testleri otomatik üretimin sonucunu doğrulamalıdır.

HEX, RGB, HSL ve OKLCH Arasındaki Fark

HEX temelde RGB kanal değerlerinin kompakt gösterimidir. RGB ekran ışığı bileşenlerini ifade ederken HSL hue, saturation ve lightness üzerinden daha insan dostu manipülasyon sunar. HSL lightness değeri farklı hue'larda aynı algısal açıklığı garanti etmez. OKLCH perceptual lightness ve chroma yaklaşımıyla ton skalası üretiminde daha dengeli kontrol sağlayabilir. Format seçimi tek başına iyi palette üretmez, ancak doğru model tasarım token otomasyonunu kolaylaştırır.

Algısal Olarak Tutarlı Renk Skalaları

Kurumsal palette'de ton adımlarının görsel olarak dengeli ilerlemesi önemlidir. Yalnızca RGB kanalına sabit sayı eklemek bazı tonlarda ani parlaklık değişimi yaratabilir. OKLCH lightness değerlerini kontrollü değiştirmek daha düzenli basamaklar üretmeye yardımcı olur. Chroma koyu ve çok açık uçlarda azaltılabilir. Palette yine tasarımcı tarafından gerçek UI surface'lerinde değerlendirilmelidir.

Marka Renginden Ton Skalası Üretmek

Tek brand renginden açık ve koyu tonlar üretmek için lightness ve chroma kontrollü değiştirilebilir. Hue mümkün olduğunca stabil tutulabilir fakat bazı renklerde görsel denge için küçük düzeltmeler gerekebilir. Üretilen scale primary hover, subtle background ve border gibi farklı rollere aday olur. Semantic mapping tüm tonların component'lerde kullanılacağı anlamına gelmez. Gereksiz palette genişliği geliştiricilerin seçim yükünü artırabilir.

color-mix() ile Türetilmiş Renkler

color-mix() mevcut CSS renklerini belirli oranlarda karıştırarak türetilmiş değerler üretmeyi sağlar. Runtime kullanıcı rengi bulunan white-label sistemlerde hover veya subtle surface üretmek için yararlı olabilir. Ancak tüm browser hedefleri ve istenen color space davranışı test edilmelidir. Otomatik karışım contrast garantisi sağlamaz. Critical text ve action state'leri yine accessibility doğrulamasından geçmelidir.

Hover ve Active Tonlarını Sistematik Oluşturmak

Hover ve active renklerini her component geliştiricisinin elle seçmesi yerine belirli token kuralına bağlamak daha tutarlıdır. Lightness belirli oran azaltılabilir veya predefined palette adımları kullanılabilir. Dark theme'de aynı yönlü değişiklik her zaman doğru olmayabilir. Semantic interaction token'ları mode bazında farklı mapping kullanabilir. Sistematik üretim tasarım kararlarını tekrarlanabilir hale getirir fakat visual review ihtiyacını ortadan kaldırmaz.

Otomatik Üretilen Paletlerin Sınırları

Algoritma marka renginden teknik olarak düzenli bir scale üretebilir, ancak brand perception ve accessibility kararlarını tamamen veremez. Çok yüksek chroma değerleri belirli ekranlarda rahatsız edici olabilir. Bazı hue'lar aynı lightness değerinde farklı algılanabilir. Marketing ve product UI ihtiyaçları farklı ton davranışları isteyebilir. Otomatik palette bu nedenle iyi başlangıç olarak görülmeli ve gerçek kullanım bağlamında doğrulanmalıdır.

WCAG Uyumlu Marka Renkleri

Marka renginin görsel olarak çekici olması, üzerinde kullanılan metnin erişilebilir olduğu anlamına gelmez. Contrast değerlendirmesi foreground ve background çiftine göre yapılmalıdır. Özellikle açık sarı, açık yeşil veya canlı cyan gibi renklerde otomatik text-white kullanımı ciddi okunabilirlik problemi oluşturabilir. Semantic on-primary yaklaşımı uygun foreground rengini merkezi olarak seçmeye yardımcı olur. Light, dark ve kullanıcı tarafından belirlenen marka renkleri aynı accessibility pipeline'ından geçirilmelidir.

Contrast Ratio Nedir?

Contrast ratio foreground ile background luminance farkını ölçen erişilebilirlik göstergesidir. Okunabilirlik yalnızca renklerin farklı görünmesiyle değerlendirilmemelidir. Metin boyutu ve kullanım bağlamına göre hedefler farklı olabilir. Design token pipeline belirli token çiftlerini otomatik contrast testine sokabilir. Tasarım review sırasında yalnızca ana palette değil hover, disabled ve dark theme kombinasyonları da kontrol edilmelidir.

Açık Marka Renklerinde text-white Problemi

Birçok button component'i primary background üzerinde doğrudan beyaz text varsayar. Marka primary rengi yeterince açık olduğunda bu varsayım çalışmaz. White-label sistemde tenant'ın color picker üzerinden açık bir renk seçmesi problemi daha sık ortaya çıkarır. Foreground renginin marka renginden bağımsız semantic token olması bu nedenle önemlidir. Sistem background değerine göre güvenli foreground seçebilir veya erişilebilir olmayan marka rengini yayınlamayı engelleyebilir.

on-primary Token Yaklaşımı

on-primary token primary yüzey üzerinde kullanılacak foreground rengini açık biçimde tanımlar. Marka A için bu değer beyaz, marka B için koyu neutral olabilir. Button component yalnızca primary ve on-primary çiftini kullanır. Contrast kararı component seviyesinden theme configuration'a taşınır. Aynı pattern danger, success ve surface gibi diğer semantic yüzeylere de uygulanabilir.

Foreground Rengini Arka Plandan Bağımsızlaştırmak

Foreground'u background token'ın türevi gibi varsaymak bazı palette'lerde güvenli sonuç üretmez. İki token ayrı değerlendirildiğinde accessibility için daha fazla kontrol elde edilir. Runtime kullanıcı rengi seçildiğinde foreground otomatik hesaplanabilir veya önceden doğrulanmış iki seçenekten biri atanabilir. Bu değer database'de doğrudan kullanıcı tarafından kontrol edilen serbest CSS olarak tutulmamalıdır. Theme service yalnızca doğrulanmış token set üretmelidir.

Light ve Dark Tema İçin Ayrı Kontrast Testleri

Light theme'de başarılı olan token çifti dark theme override sonrası aynı contrast seviyesini garanti etmez. Surface ve foreground değerleri her mode için ayrı test edilmelidir. Visual regression test contrast testinin yerine geçmez çünkü gözle benzer görünen değişiklik teknik olarak yetersiz olabilir. CI token değişikliğinde bütün theme matrix için otomatik erişilebilirlik kontrolü çalıştırabilir. Yeni marka eklendiğinde aynı test set'i tekrar kullanılmalıdır.

Kullanıcı Tarafından Belirlenen Renklerin Doğrulanması

Tenant admin color picker üzerinden marka rengi seçebiliyorsa değer yalnızca CSS syntax açısından değil accessibility açısından da doğrulanmalıdır. Sistem primary ve foreground kombinasyonunu kontrol edebilir. Gerekirse önerilen en yakın güvenli tona yönlendirme yapılabilir. Preview ekranı light ve dark mode örneklerini göstermelidir. Publish işlemi başarısız contrast kombinasyonunu engelleyecek policy ile korunabilir.

Kurumsal Tipografi Sistemini Tailwind'e Aktarmak

Kurumsal typography sistemi font family seçmekten daha geniştir ve boyut, ağırlık, line-height, tracking ve semantic role kombinasyonlarını içerir. Tailwind theme namespace'leri primitive typography değerlerini utility API'sine bağlayabilir. Semantic text style'lar gerektiğinde custom utility veya component primitive olarak oluşturulabilir. Variable font kullanımı çok sayıda weight dosyasını azaltabilir, fakat loading ve browser behavior test edilmelidir. Responsive typography için clamp() kontrollü fluid scale oluşturmak üzere kullanılabilir.

Font Family Tokens

Font family token body, display veya mono gibi semantic rollerle isimlendirilebilir. Multi-brand yapıda aynı font-body utility'si farklı markalarda farklı gerçek font ailesine bağlanabilir. Font fallback zinciri düzgün tanımlanmalıdır. Web font yüklenirken layout shift ve rendering davranışı değerlendirilmelidir. Marka değişiminde component class'larını güncellemek yerine token mapping değişmelidir.

Font Size Tokens

Font size scale rastgele piksel değerleri yerine sınırlı primitive basamaklardan oluşmalıdır. Çok sık boyut eklemek hiyerarşiyi zayıflatır. Semantic heading veya body style bu primitive basamaklara referans verebilir. Mobile ve desktop için fluid veya breakpoint tabanlı değişim kullanılabilir. Token adı gerçek boyuttan çok sistemdeki yerini açıkça göstermelidir.

Font Weight Tokens

Weight token regular, medium, semibold ve bold gibi kontrollü seviyeleri tanımlar. Aynı numeric değerin farklı font ailelerinde farklı algı oluşturabileceği unutulmamalıdır. Variable font kullanıldığında daha ayrıntılı weight axis mümkün olabilir. Buna rağmen design system sınırsız weight seçeneği sunmamalıdır. Semantic style hangi weight'in ne zaman kullanılacağını belirlemelidir.

Line Height Tokens

Line height okunabilirlik ve dikey ritim üzerinde font size kadar etkilidir. Heading ve uzun body metni aynı oranı kullanmak zorunda değildir. Relative veya unitless değerler font ölçeğine daha iyi uyum sağlayabilir. Figma ve web rendering arasında farklar test edilmelidir. Semantic typography style line-height'i font size ile birlikte tanımlamalıdır.

Letter Spacing Tokens

Letter spacing özellikle büyük display text, uppercase label ve bazı brand fontlarında önemli rol oynar. Her component'in tracking değerini ayrı seçmesi tipografik tutarlılığı bozar. Birkaç semantic tracking token yeterli olabilir. Font değiştiğinde mevcut letter-spacing değerleri yeniden gözden geçirilmelidir. Typography token migration yalnızca family değişikliğinden ibaret değildir.

Semantic Typography Styles

Semantic typography style birden fazla primitive değeri kullanım amacı altında birleştirir. Display, heading, body, caption ve label gibi roller ekipler arasında anlaşılır bir dil oluşturur. Bu style'lar component library, custom utility veya reusable CSS pattern olarak uygulanabilir. Teknik isimlerin business design rolüne dönüşmesi tasarım ile kod parity'sini güçlendirir. Yeni markada aynı role farklı font family veya weight bağlanabilir.

Display

Display style büyük hero başlıkları veya yüksek görsel vurgu gereken alanlar için kullanılabilir. Font size kadar line-height ve letter-spacing de birlikte tanımlanmalıdır. Her sayfa başlığının display olması hiyerarşiyi zayıflatır. Responsive ölçekte mobile taşma durumları test edilmelidir. Multi-brand sistemde display font ailesi body fontundan tamamen farklı olabilir.

Heading

Heading style içerik hiyerarşisini kullanıcıya açık biçimde gösterir. H1, H2 gibi semantic HTML seviyesi ile görsel heading token birebir aynı olmak zorunda değildir. Accessibility için doğru document outline korunmalıdır. Tasarım sistemi birkaç heading size seviyesi sunabilir. Component görsel style seçerken HTML semantics'i kaybetmemelidir.

Body

Body style ürünün en çok kullanılan metin biçimidir ve uzun süreli okunabilirliği desteklemelidir. Font size, line-height ve foreground contrast birlikte değerlendirilmelidir. Çok ince weight küçük ekranlarda okunabilirliği azaltabilir. Body-small gibi sınırlı varyantlar gerekebilir. Marka karakteri body okunabilirliğinin önüne geçmemelidir.

Caption

Caption yardımcı veya ikincil bilgileri daha düşük görsel ağırlıkta sunar. Küçük font nedeniyle contrast özellikle önemlidir. Yalnızca opacity düşürerek caption üretmek erişilebilirliği zayıflatabilir. Semantic muted foreground token kullanılmalıdır. Caption kritik talimatların tek taşıyıcısı olmamalıdır.

Label

Label form alanı, button veya kısa control metinlerinde kullanılır. Weight ve letter-spacing body metninden farklı olabilir. Form label erişilebilir isimlendirme amacıyla gerçek HTML label semantics'iyle eşleşmelidir. Görsel token semantik bağlantının yerine geçmez. Disabled veya error durumunda color mapping ayrıca uygulanabilir.

Variable Font Kullanımı

Variable font tek font dosyasında weight, width veya başka axis değerleri sunabilir. Bu durum çok sayıda ayrı font dosyası yükleme ihtiyacını azaltabilir. Design system yine izin verilen axis kombinasyonlarını token'larla sınırlandırmalıdır. Her browser ve platformda font rendering sonucu test edilmelidir. Multi-brand theme package font URL veya family mapping'i marka bazında değiştirebilir.

Fluid Typography ve clamp()

clamp() minimum, preferred ve maximum değer üzerinden viewport'a göre akışkan typography oluşturabilir. Bu yaklaşım her küçük breakpoint için ayrı text size tanımlama ihtiyacını azaltır. Ancak çok agresif fluid scaling okunabilirliği bozabilir. Design token içinde formula veya önceden belirlenmiş semantic style olarak saklanabilir. Component placement container'a bağlıysa viewport yerine container-aware çözümler ayrıca değerlendirilmelidir.

Spacing Sistemi ile Kurumsal Görsel Ritmi Korumak

Spacing sistemi arayüzde elemanların birbirleriyle ilişkisini düzenler ve marka hissinin önemli bir bölümünü oluşturur. Dört veya sekiz piksel tabanlı grid geliştiricilere tekrar eden bir ritim sağlar. Primitive spacing token'ları genel scale'i, semantic token'lar ise card padding veya form gap gibi kullanım kararlarını ifade eder. Arbitrary değerlerin yoğun kullanımı bu ritmi zaman içinde bozar. Kurum spacing sistemini design review, linting ve component primitive'leriyle desteklemelidir.

4px veya 8px Grid Yaklaşımı

Dört piksel grid daha ince ayar imkanı sunarken sekiz piksel grid seçenek sayısını azaltır. Birçok sistem her ikisini bir arada kullanarak dört piksel temel ve sekiz piksel ağırlıklı layout oluşturabilir. Burada önemli olan belirli bir sayının evrensel doğruluğu değil, ekiplerin ortak ölçü sistemi kullanmasıdır. Typography ve icon boyutları grid ile birlikte değerlendirilmelidir. Legacy arayüzlerde migration sırasında bütün spacing değerlerini tek seferde değiştirmek yerine aşamalı tokenization daha güvenlidir.

Primitive Spacing Tokens

Primitive spacing token küçükten büyüğe tutarlı ölçü scale'i sunar. Token isimleri numeric veya t-shirt size yaklaşımı kullanabilir. Kurum hangi modelin Figma ve kod tarafında daha kolay eşleştiğini belirlemelidir. Primitive scale responsive davranışı kendi içinde taşımak zorunda değildir. Semantic layout token gerekirse breakpoint veya container bağlamında farklı primitive değer kullanabilir.

Semantic Spacing Tokens

Semantic spacing token belirli layout amacını temsil eder. card-padding, section-gap veya form-gap gibi isimler geliştiricinin neden belirli boşluğu kullandığını açıklar. Rebranding veya density mode sırasında bu değerler topluca değiştirilebilir. Çok fazla component-specific spacing token yönetim yükü oluşturabilir. Ortak pattern gerçekten tekrarlandığında semantic token eklemek daha doğru olur.

Card Padding

Card padding bütün card varyantlarında tutarlı iç boşluk sağlar. Compact ve comfortable density gerekiyorsa iki semantic seçenek oluşturulabilir. Component doğrudan p-5 gibi primitive'e bağlanmak yerine tokenized utility kullanabilir. Responsive card içinde padding container boyutuna göre değişebilir. Marka density karakteri de bu token üzerinden yönetilebilir.

Section Gap

Section gap sayfa içindeki büyük içerik bloklarının arasındaki ritmi belirler. Card içi gap ile aynı ölçekte olmak zorunda değildir. Mobile ekranda daha düşük, geniş layout'ta daha yüksek değer tercih edilebilir. Semantic section token responsive CSS ile yönetilebilir. Uygulama geliştiricisinin her sayfada farklı mt-* kombinasyonu üretmesi önlenir.

Form Gap

Form gap label, input, helper text ve field grupları arasındaki spacing'i tutarlı hale getirir. Hata mesajı görünür olduğunda layout davranışı önceden tasarlanmalıdır. Compact admin ekranları ile consumer form'ları farklı density kullanabilir. Semantic token bu farkı explicit hale getirir. Form component library bu spacing kararını uygulama ekranından gizleyebilir.

Arbitrary Spacing Değerlerinden Kaçınmak

Tailwind arbitrary value desteği istisnai tasarım ihtiyaçlarında değerlidir. Ancak her geliştirici istediği piksel değerini kullanırsa spacing token sistemi etkisini kaybeder. Linter belirli arbitrary spacing pattern'lerini warning veya error olarak işaretleyebilir. Gerçek istisna varsa gerekçe code review'da görünür hale getirilebilir. Tekrarlanan arbitrary değer yeni primitive veya semantic token ihtiyacına işaret edebilir.

Radius ve Shadow Kurallarını Marka Kimliğinin Parçası Yapmak

Radius ve shadow çoğu tema sisteminde renk kadar önemsenmez, ancak marka algısında doğrudan rol oynar. Bir marka tamamen düz ve keskin yüzeyler kullanabilirken başka marka yüksek radius ve yumuşak elevation tercih edebilir. Component'lerin bu değerleri hard-code etmesi multi-brand reuse'u zorlaştırır. Radius ve shadow token'ları brand theme içinde override edilebilir. Böylece aynı Button ve Card component'i farklı görsel karakterlerde yeniden kullanılabilir.

Border Radius Marka Algısını Nasıl Etkiler?

Köşe geometrisi arayüzün resmi, teknik, oyuncu veya yumuşak görünmesine katkı sağlar. Çok yüksek radius her markaya uygun değildir. Button, input ve card'da farklı rastgele radius değerleri kullanmak görsel dili parçalar. Design system sınırlı scale ve component mapping tanımlamalıdır. Kullanıcı feedback'i yalnızca estetik değil, touch target ve layout davranışı açısından da değerlendirilmelidir.

Radius Scale Oluşturmak

Radius scale none, small, medium ve large gibi birkaç seviyeden oluşabilir. Pill form gerektiğinde ayrı full radius token kullanılabilir. Her primitive değer component tarafından doğrudan tüketilmek zorunda değildir. Semantic component mapping hangi seviyenin nerede kullanılacağını tanımlar. Rebranding sırasında scale veya mapping değiştirilebilir.

Shadow Scale Oluşturmak

Shadow scale elevation seviyelerini sınırlı sayıda standard haline getirir. Blur, spread, offset ve opacity birlikte düşünülmelidir. Light theme için tasarlanan shadow dark theme'de görünmez veya fazla ağır olabilir. Mode-specific shadow token kullanılabilir. Surface color farkları yeterliyse dark theme'de daha düşük shadow tercih edilebilir.

Elevation ve Surface Hiyerarşisi

Elevation yalnızca shadow ile anlatılmak zorunda değildir. Surface color, border ve stacking context birlikte depth algısı oluşturabilir. Modal, dropdown ve card gibi component'ler belirli elevation seviyelerine bağlanabilir. Z-index ayrı sistem olarak yönetilmelidir. Marka kimliği flat tasarımı tercih ediyorsa elevation semantic olarak korunup görsel uygulama border veya tonal surface ile yapılabilir.

Kurumsal Bir Kuralı Token Katmanında Zorunlu Kılmak

Tasarım kuralı yalnızca dokümanda yazıyorsa geliştirici istemeden farklı değer kullanabilir. Token namespace'i izin verilmeyen radius veya shadow seviyelerini hiç sunmayacak şekilde sınırlandırılabilir. Arbitrary utility kullanımı linting ile kontrol edilir. Component library standard token dışında değer kabul etmeyebilir. Böylece görsel kurallar geliştiricinin hafızasına bağlı olmaktan çıkar.

Zero-Radius Marka Örneği

Bir marka bütün yüzeylerde keskin köşe kullanıyorsa radius theme variable'ları sıfıra çekilebilir. Ortak component markup değişmeden kalabilir. Markaya özel if koşulları eklemek gerekmez. Storybook brand matrix bütün component'lerde radius'un gerçekten sıfırlandığını doğrulayabilir. Yeni marka yalnızca token package üzerinden bu karakteri kazanır.

Shadow-Free Marka Örneği

Gölge kullanmayan marka için shadow token'ları merkezi olarak none değerine bağlanabilir. Component'in shadow-md gibi primitive utility yerine semantic elevation utility kullanması burada önemlidir. Aynı component başka markada gerçek shadow alabilir. Border ve surface contrast elevation görevini üstlenebilir. Bu yapı görsel karakter değişikliğini component refactor'ı olmaktan çıkarır.

Motion ve Animasyonu Design Token'a Dönüştürmek

Motion token'ları animasyon süresi ve easing kararlarını kurum genelinde standardize eder. Button hover ile modal açılışının aynı duration kullanması gerekmez, fakat sınırlı bir timing scale olması yararlıdır. Brand karakteri daha hızlı veya daha sakin transition değerleriyle ifade edilebilir. Reduced-motion tercihi bütün motion sisteminin üzerinde çalışmalıdır. Component geliştiricisi kendi keyfi duration değerlerini üretmek yerine tasarım sisteminin motion primitives'ini kullanmalıdır.

Duration Tokens

Duration token instant, fast, normal ve slow gibi anlamlı seviyelerle tanımlanabilir. Gerçek millisecond değerleri primitive katmanda tutulabilir. Micro interaction ile page transition aynı duration kullanmak zorunda değildir. Çok uzun animasyon kullanıcı verimliliğini düşürebilir. Reduced-motion durumunda bazı duration değerleri sıfıra veya çok düşük seviyeye indirilebilir.

Easing Tokens

Easing hareketin hızlanma ve yavaşlama karakterini belirler. Entrance, exit ve standard interaction için farklı eğriler gerekebilir. Her component'in kendi cubic-bezier değerini yazması tutarsızlık oluşturur. Theme variable veya CSS custom property üzerinden merkezi easing token tanımlanabilir. Marka değişikliğinde motion karakteri bu seviyede güncellenebilir.

Transition Tokens

Transition token duration ve easing dışında hangi property'lerin animasyona dahil olacağını da standardize edebilir. Color transition, transform transition ve opacity transition ayrı pattern olabilir. transition-all kolay görünse de gereksiz property animasyonlarına neden olabilir. Component yalnızca değişmesi gereken property'leri animate etmelidir. Motion token sistemi performans ve erişilebilirlik ilkeleriyle birlikte tanımlanmalıdır.

Marka Karakterini Motion ile Yansıtmak

Finans veya enterprise ürün daha sakin ve öngörülebilir motion kullanabilir. Genç tüketici markası daha hızlı ve enerjik transition tercih edebilir. Bu fark component logic'ine marka koşulu eklenerek değil token mapping ile uygulanmalıdır. Aynı modal component farklı brand duration ve easing değerleri alabilir. Böylece marka karakteri shared component library korunarak değiştirilebilir.

prefers-reduced-motion Desteği

prefers-reduced-motion kullanıcıların hareket azaltma tercihine saygı göstermeyi sağlar. Dekoratif ve büyük hareketler azaltılabilir veya kaldırılabilir. Kritik state feedback tamamen kaybolmamalı ve alternatif görsel değişiklik sunulmalıdır. Motion utility veya global token layer bu tercihi merkezi uygulayabilir. Accessibility testleri reduced-motion modunda component davranışını da kapsamalıdır.

Logo, İkon ve Görsel Varlık Yönetimi

Multi-brand theme yalnızca CSS token değişimi değildir çünkü logo, icon ve illustration gibi asset'ler de marka kimliğinin parçasıdır. Runtime marka switching yapılıyorsa doğru asset set'inin aynı anda çözülmesi gerekir. Light ve dark theme logo kontrastını etkileyebilir. Merkezi asset registry component'lerin dosya yollarını bilmesini engeller. Tenant configuration yalnızca izin verilen kayıtlı asset kimliklerine referans vermelidir.

Light ve Dark Tema Logo Varyantları

Tek logo her background üzerinde okunabilir olmayabilir. Light theme koyu wordmark, dark theme açık wordmark kullanabilir. Logo varyantı CSS filter ile zorla dönüştürülmek yerine tasarım tarafından hazırlanmış doğru asset olabilir. Theme resolver color scheme'e göre uygun kaynağı seçer. Layout shift'i azaltmak için logo boyutları mümkün olduğunca stabil tutulmalıdır.

Multi-Brand Logo Registry

Logo registry marka kimliğini asset URL ile merkezi olarak eşleştirir. Component yalnızca aktif brand key'i üzerinden gerekli logo rolünü ister. Header, login ve email gibi farklı kullanım yerleri için asset rolleri tanımlanabilir. Marka eklendiğinde registry genişletilir ve component kodu aynı kalır. Tenant tarafından serbest URL alınacaksa güvenlik ve content policy ayrıca uygulanmalıdır.

SVG'de currentColor Kullanımı

currentColor SVG icon'un parent text color değerini kullanmasını sağlar. Bu yaklaşım semantic foreground token'larıyla doğal şekilde çalışır. Icon component her theme için ayrı fill prop taşımak zorunda kalmaz. Multi-color brand logo için currentColor her zaman uygun değildir ve özel asset gerekebilir. Monochrome system icon'larında ise tema bağımsızlığı önemli ölçüde artar.

Marka Rengini Icon Sistemine Aktarmak

Interactive icon semantic primary veya foreground token kullanabilir. Her icon içinde belirli brand HEX yazılmamalıdır. Status icon'ları success veya danger semantic rengini kullanır. Decorative icon brand accent kullanabilir fakat contrast ve anlam ilişkisi değerlendirilmelidir. Icon system token mapping'i text ve component renk sistemiyle aynı naming modelini takip etmelidir.

Component İçinde Logo Hard-Code Etmemek

Header component doğrudan /brand-a-logo.svg yolunu kullanırsa white-label reuse zorlaşır. Bunun yerine logo component veya asset resolver aktif brand context'ten doğru kaynağı döndürmelidir. Server-side render varsa brand request sırasında belirlenebilir. Client switching gerekiyorsa registry runtime context ile çalışır. Component yalnızca logo rolünü bilir ve marka ayrıntısını bilmez.

Tenant Bazlı Asset Resolution

Tenant configuration logo, favicon ve diğer görsel asset kimliklerini saklayabilir. Request tenant domain veya tenant ID üzerinden çözülür. Server cache sık kullanılan config'i hızlandırabilir. Geçersiz veya eksik asset durumunda default brand fallback bulunmalıdır. Tenant'ın yüklediği dosyalar content type, boyut ve güvenlik açısından doğrulanmalıdır.

Tailwind CSS ile Dark Mode Yönetimi

Tailwind'in güncel dark mode yaklaşımında dark: variant varsayılan olarak prefers-color-scheme davranışını temel alabilir. Manuel seçim gerektiğinde @custom-variant ile .dark class'ı veya data-theme="dark" gibi bir selector kullanılabilir. Bu sayede Light, Dark ve System seçenekleri aynı uygulamada desteklenebilir. Kurumsal component library'de her component'e doğrudan dark override yazmak yerine semantic token değerlerini mode bazında değiştirmek çoğu durumda daha temizdir. Tailwind'in resmi dokümantasyonu class ve data attribute tabanlı selector kullanımını ve system tercihi için matchMedia() yaklaşımını açıkça örnekliyor. :contentReference[oaicite:11]{index=11}

prefers-color-scheme Yaklaşımı

prefers-color-scheme işletim sistemi veya tarayıcı düzeyindeki light-dark tercihine göre style uygulamayı sağlar. Kullanıcı uygulamada ayrı seçim yapmıyorsa bu davranış iyi varsayılan olabilir. Tailwind dark variant varsayılan kullanımında sistem tercihini destekler. Ancak kullanıcı “Light” seçtiği halde işletim sistemi dark ise explicit app tercihi sistem değerinin önüne geçmelidir. Üçlü seçim modelinde stored preference ve system media query birlikte çözülmelidir.

Class Tabanlı Tema

Class tabanlı model root element'e dark class'ı ekler ve custom dark variant bu selector'a bağlanır. Basit, yaygın ve debugging açısından anlaşılırdır. JavaScript yalnızca root class'ını değiştirir. SSR kullanılıyorsa class ilk HTML'e server tarafından yazılarak FOUC azaltılabilir. Brand için ayrı class kullanmak mümkün olsa da data attribute daha okunabilir tema boyutları sunabilir.

data-theme Tabanlı Tema

data-theme attribute light ve dark state'i açık semantic değerle ifade eder. Tailwind dokümantasyonu dark variant'ın data selector üzerinden özelleştirilebildiğini gösterir. Bu model brand ve color scheme'i ayrı attribute'larda tutmak için özellikle uygundur. Örneğin root element aynı anda data-brand ve data-theme değerlerine sahip olabilir. CSS cascade iki bağımsız tema boyutunu daha anlaşılır yönetir. :contentReference[oaicite:12]{index=12}

Custom Variant Kullanımı

@custom-variant belirli selector durumunu reusable Tailwind variant'a dönüştürür. Dark mode dışında özel theme veya state variant'ları da oluşturulabilir. Güncel Tailwind dokümantasyonunda data attribute tabanlı özel theme selector örnekleri bulunur. Bu özellik utility-level theme override gereken özel component'lerde yararlı olabilir. Buna rağmen semantic token override ile çözülebilen bütün renkleri variant class'larına taşımak component markup'ını gereksiz büyütebilir. :contentReference[oaicite:13]{index=13}

Light / Dark / System Üçlü Seçimi

Üçlü model kullanıcıya açık Light, açık Dark veya sistem tercihini takip etme seçeneği sunar. Stored state “system” ise gerçek mode matchMedia() üzerinden çözülür. System preference değiştiğinde uygulama canlı olarak güncellenebilir. Kullanıcı explicit Light veya Dark seçtiğinde sistem değişikliği uygulamayı etkilememelidir. Tailwind dokümantasyonundaki örnek de local storage ve media query kombinasyonuyla bu yaklaşımı gösterir. :contentReference[oaicite:14]{index=14}

Light

Light seçeneği kullanıcının sistem temasından bağımsız olarak açık görünümü tercih ettiğini ifade eder. Root theme state açık biçimde light olarak yazılabilir. Browser native form control'larının da uygun color-scheme davranışı alması gerekir. Light theme token set'i background, surface ve foreground değerlerini birlikte tanımlar. Tercih sonraki ziyaret için güvenli storage mekanizmasında saklanabilir.

Dark

Dark seçeneği kullanıcının işletim sistemi light olsa bile koyu görünümü kullanmasını sağlar. Semantic token'lar dark values ile override edilir. Image, logo ve shadow gibi yalnızca renk olmayan asset kararları da bu state'ten etkilenebilir. Native form ve scrollbar color scheme davranışı test edilmelidir. Dark theme contrast yalnızca light değerleri tersine çevrilerek varsayılmamalıdır.

System

System seçeneği uygulamanın işletim sistemi preference'ını takip etmesini sağlar. Uygulama stored explicit theme yerine media query sonucunu aktif değer olarak kullanır. İşletim sistemi değiştiğinde açık sayfa yeniden yüklenmeden theme güncellenebilir. SSR sırasında sistem tercihi server tarafından bilinmeyebilir. Bu durumda küçük pre-paint script veya client hint gibi farklı stratejiler değerlendirilebilir.

Kullanıcı Tercihini Saklamak

Theme preference local storage, cookie veya kullanıcı profile ayarı olarak saklanabilir. Cookie SSR sırasında theme'i ilk HTML'e yansıtmayı kolaylaştırır. Account-based preference farklı cihazlarda senkron deneyim sunabilir. System seçeneğini saklarken resolved mode değil kullanıcının “system” tercihi saklanmalıdır. Security açısından tema tercihi hassas veri olmasa da storage stratejisi uygulamanın genel mimarisiyle uyumlu olmalıdır.

Dark Mode'da Her Component'e dark: Yazmak Zorunda mıyız?

Hayır, özellikle semantic token mimarisinde her component'e dark: eklemek zorunlu değildir. Token-level dark mode yaklaşımında component bg-surface ve text-foreground gibi aynı utility'leri kullanır. Root theme değiştiğinde bu semantic token'ların gerçek değerleri CSS cascade ile değiştirilir. Böylece component markup theme state'inden habersiz kalır. dark: variant yalnızca gerçekten layout, asset veya davranış açısından mode-specific istisna gerektiğinde kullanılabilir.

Utility-Level Dark Mode

Utility-level model component içinde bg-white dark:bg-gray-900 gibi açık karşılıklar yazar. Küçük proje veya birkaç özel component için oldukça anlaşılırdır. Ancak yüzlerce component'li multi-brand sistemde renk mapping'i markup'a dağıtır. Rebranding ve semantic redesign sırasında çok sayıda dosya değişebilir. Bu nedenle kurumsal design system'de temel renklerin token-level override'a taşınması daha sürdürülebilir olabilir.

Token-Level Dark Mode

Token-level model aynı semantic isimlerin light ve dark karşılıklarını root selector altında değiştirir. Component yalnızca semantic token kullanır. Dark mode logic merkezi theme dosyasında kalır. Yeni component otomatik olarak iki mode'u destekleyebilir. Bu yaklaşım visual regression test matrix ve brand switching mimarisiyle de daha kolay ölçeklenir.

Semantic Token Override Yaklaşımı

:root light semantic values tanımlayabilir ve [data-theme="dark"] aynı variable'ları override edebilir. Tailwind-facing @theme inline alias'ları bu runtime semantic custom property'lere bağlanabilir. Böylece bg-surface utility her theme'de aynı kalır. Component testinde yalnızca root attribute değiştirilir. Tailwind'in resmi renk dokümantasyonunda da normal custom property'nin data-theme altında değiştirilip @theme inline ile Tailwind rengine bağlandığı bir model gösterilir. :contentReference[oaicite:15]{index=15}

Component Kodunu Temadan Bağımsız Tutmak

Theme-independent component daha kolay reuse edilir ve test edilir. Button component'in light veya brand A diye özel condition taşımaması hedeflenmelidir. Component semantic variant bilgisini bilir, gerçek görsel değer theme layer tarafından çözülür. Bu ayrım Storybook matrix oluşturmayı kolaylaştırır. Yeni marka eklemek component release gerektirmeden yalnızca theme package değişikliğiyle mümkün olabilir.

Hangi Durumlarda dark: Hâlâ Gerekli?

Bazı durumlarda dark mode yalnızca color token değişikliği değildir. Dark theme'de farklı logo asset'i, farklı image treatment veya özel blend mode gerekebilir. Bu tür gerçek mode-specific davranışlar için dark: variant anlaşılır çözüm olabilir. Semantic token ile ifade edilemeyen layout veya visibility değişikliği de variant kullanabilir. Yine de dark utility kullanımının istisna mı yoksa temel tema mimarisi mi olduğu ekip standardında açıkça belirtilmelidir.

Sayfa Açılışında Tema Parlamasını (FOUC) Önlemek

Theme flash kullanıcı sayfayı açtığında önce yanlış theme'in kısa süre görünmesi, ardından doğru theme'e geçilmesidir. Bunun temel nedeni theme preference'ın browser ilk paint'i yaptıktan sonra client JavaScript tarafından uygulanmasıdır. En iyi çözüm aktif theme'i mümkün olduğunca ilk paint öncesinde belirlemektir. SSR varsa cookie veya kullanıcı ayarı server tarafından HTML attribute'una yazılabilir. Tam server bilgisi yoksa küçük blocking initialization script sistem ve local preference'ı mümkün olduğunca erken çözebilir.

Yanlış Tema Neden Önce Görünür?

CSS varsayılan light theme ile yüklenir ve browser hemen ilk paint'i yapabilir. Daha sonra application bundle çalışıp local storage'dan dark preference okur. Root attribute değiştiğinde ikinci paint gerçekleşir. Kullanıcı bunu beyaz ekran parlaması olarak görür. Problem özellikle yavaş cihaz ve büyük JavaScript bundle'da daha belirgin hale gelir.

Client-Side Theme Initialization Problemi

Theme initialization framework component mount aşamasına bırakıldığında zaten çok geç olabilir. React effect veya benzeri lifecycle hook ilk paint sonrasında çalışabilir. Theme resolution global UI state olduğu için app component render'ından önce çözülmesi daha doğrudur. Küçük inline script veya server-rendered attribute kullanılabilir. Script CSP politikasıyla uyumlu biçimde tasarlanmalıdır.

HTML Oluşmadan Tema Tercihini Çözmek

Tarayıcıya gönderilen ilk HTML mümkünse aktif theme bilgisini içermelidir. Server cookie üzerinden user preference'ı okuyabiliyorsa root attribute doğrudan render edilir. Bu durumda CSS ilk paint'te doğru semantic token set'ini kullanır. Sistem theme tercihini server'ın doğrudan bilmediği durumlarda client-side erken resolution gerekebilir. Çözüm architecture ve privacy gereksinimlerine göre seçilmelidir.

SSR ile Tema Bilgisini İlk HTML'e Eklemek

SSR uygulamasında theme preference cookie veya account setting üzerinden request sırasında çözülebilir. HTML root element'e uygun data-theme eklenir. Client hydration aynı state ile başlamalıdır. Server ve client farklı theme varsayarsa hydration mismatch veya görsel geçiş oluşabilir. System mode özel durumda client device preference bilinmediği için ayrıca strateji gerekir.

Sistem Temasını matchMedia ile Çözmek

window.matchMedia("(prefers-color-scheme: dark)") client'ta gerçek sistem tercihini öğrenmek için kullanılabilir. Tailwind'in dark mode dokümantasyonu üçlü seçim senaryosunda bu yaklaşımı örnekliyor. Script mümkün olduğunca erken çalıştırılarak root state belirlenebilir. Sistem preference değişiklikleri event listener ile takip edilebilir. Explicit user preference varsa matchMedia sonucu onu override etmemelidir. :contentReference[oaicite:16]{index=16}

Hydration Mismatch Riskleri

Server light markup üretip client ilk render'da dark state beklerse framework hydration uyarısı oluşabilir. Görsel theme attribute'su component tree'nin server ve client varsayımıyla uyumlu olmalıdır. System preference server'da bilinmiyorsa root theme state için kontrollü initialization gerekebilir. Tema farklılığı yalnızca CSS custom property seviyesinde kalırsa markup mismatch riski azalabilir. SSR framework'ünün hydration davranışı gerçek uygulamada test edilmelidir.

Multi-Brand Tema Mimarisi Nedir?

Multi-brand tema mimarisi tek uygulama veya component library'nin birden fazla kurumsal kimliği desteklemesini sağlar. White-label SaaS, alt marka yapıları ve ajans projeleri bu modele sık ihtiyaç duyar. Temel hedef her marka için ayrı component fork oluşturmak değil, ortak semantic contract'ı farklı token değerleriyle doldurmaktır. Logo ve font gibi asset farklılıkları da aynı tema sisteminin parçasıdır. Brand ve light-dark mode birbirinden bağımsız tema boyutları olarak tasarlanırsa kombinasyonlar daha kolay yönetilir.

Tek Uygulama, Birden Fazla Kurumsal Kimlik

Aynı codebase farklı domain veya tenant için farklı görsel kimlik gösterebilir. Route veya request tenant'ı belirler ve root brand attribute atanır. Component library semantic token kullanmaya devam eder. Asset resolver logo ve font varyantlarını seçer. Deployment tek build üzerinden yapılabilir.

White-Label Ürünler

White-label ürün aynı business capability'yi farklı müşteri markalarıyla sunar. Her müşteri için ayrı frontend repository oluşturmak bakım maliyetini hızla büyütür. Ortak component ve token contract sayesinde tenant yalnızca brand configuration sağlar. Renk, logo, font ve radius gibi değerler kontrollü şekilde override edilir. Product feature release bütün markalara aynı codebase üzerinden ulaşır.

Multi-Tenant SaaS

Multi-tenant SaaS'ta tenant theme configuration database veya config service içinde saklanabilir. Request tenant bilgisi üzerinden doğru theme'i çözer. Cache performansı artırabilir. User-defined renkler schema ve contrast kontrolünden geçmelidir. Tenant isolation yalnızca data access'te değil theme configuration lookup sürecinde de korunmalıdır.

Birden Fazla Alt Marka

Büyük kurum farklı ürün veya alt marka için ayrı color ve typography sistemleri kullanabilir. Ortak design system component davranışını paylaşırken brand token package görsel kimliği değiştirir. Bazı alt markalarda yalnızca accent değişirken bazılarında radius ve motion dahil daha geniş fark olabilir. Semantic contract hangi alanların özelleştirilebilir olduğunu açıklar. Ortaklık ile marka özgürlüğü arasındaki sınır governance tarafından yönetilir.

Ajansların Tek Codebase'den Farklı Müşteri Markaları Sunması

Ajans modelinde ortak product shell farklı müşteri markalarıyla yayınlanabilir. Tokenized architecture yeni müşteri onboarding süresini azaltır. Marka bilgisi CSS ve asset config üzerinden eklenir. Müşteriye özel business requirement gerçekten gerekliyse product override ayrı katmanda yönetilir. Marka farkı ile feature farkını aynı theme sistemi içinde karıştırmamak uzun vadeli bakım için önemlidir.

Multi-Brand Sistemlerde Tema Katmanları

Multi-brand sistemde tek bir CSS dosyasında rastgele override yapmak kısa sürede zor yönetilir hale gelir. Base design system, brand tokens, color-scheme tokens, tenant override ve component exception katmanları açık sırayla tanımlanmalıdır. Cascade priority önceden belli olmalıdır. Her override seviyesinin sorumluluğu dokümante edilmelidir. Böylece bir component'in neden belirli değeri aldığı developer tools üzerinde daha kolay izlenebilir.

Base Design System

Base layer bütün markaların paylaştığı component behavior ve temel token kontratını içerir. Semantic token isimleri burada belirlenir. Marka specific gerçek değerler mümkün olduğunca base component koduna girmez. Accessibility ve state behavior ortak standard olarak korunur. Yeni marka base contract'ı doldurarak sisteme katılır.

Brand Tokens

Brand layer color palette, typography, radius, shadow ve motion gibi kimlik kararlarını tanımlar. Semantic token kontratı her markada aynı kalmalıdır. Marka A primary token'a mavi, marka B yeşil değer bağlayabilir. Logo ve font registry de brand config içinde yönetilebilir. Brand package yalnızca görsel değerleri değil gerektiğinde asset metadata'sını da içerebilir.

Color-Scheme Tokens

Light ve dark mode brand'den bağımsız ikinci tema eksenidir. Color-scheme layer background, surface ve foreground gibi semantic değerleri mode'a göre ayarlar. Brand primary rengi bazı markalarda mode bazında da değişebilir. Bu durumda brand ve mode selector kombinasyonu sınırlı override sunabilir. Genel mimari mümkün olduğunca iki eksenin bağımsız kalmasını hedeflemelidir.

Tenant-Specific Overrides

White-label SaaS müşterisi standard brand token dışında sınırlı özelleştirme isteyebilir. Tenant override yalnızca allowlist içindeki token'lara izin vermelidir. Örneğin primary renk ve logo değişebilir fakat spacing veya security-related UI pattern sabit kalabilir. Override database'den runtime CSS variable olarak uygulanabilir. Her tenant'ın serbest CSS yazmasına izin vermek güvenlik ve bakım riskini artırır.

Component-Level Exceptions

Bazı marka gereksinimleri yalnızca belirli component'i etkileyebilir. Bu durumda component token katmanı genel semantic değeri override edebilir. Exception sayısı arttıkça theme mimarisinin yeniden değerlendirilmesi gerekir. Her markaya özel component fork oluşturmak son seçenek olmalıdır. Exception naming ve ownership açık tutulmalıdır.

Cascade Sırasını Önceden Tanımlamak

Base, brand, mode ve tenant override'ın hangi sırada üstün geleceği net olmalıdır. Aksi halde stylesheet import sırası tesadüfi behavior üretir. Layer veya selector specificity strategy standard hale getirilebilir. Developer tools üzerinden computed value kolay izlenebilmelidir. Tema mimarisi dokümanı örnek cascade senaryoları içermelidir.

Marka ve Dark Mode'u Birbirinden Ayırmak

Brand ile dark mode aynı kavram değildir ve tek theme string'i içinde birleştirildiğinde kombinasyon sayısı hızla büyür. Marka görsel kimliği, light-dark ise color scheme tercihidir. Root element'te data-brand ve data-theme gibi ayrı attribute'lar kullanmak bu ayrımı açık hale getirir. Semantic token katmanı iki boyuttan gerekli override'ı alır. Yeni marka veya yeni color scheme eklendiğinde bütün kombinasyonları sıfırdan kopyalamak gerekmez.

Brand Bir Tema Boyutudur

Brand primary palette, font, radius ve asset gibi kimlik kararlarını ifade eder. Kullanıcının dark preference'ından bağımsızdır. Brand A hem light hem dark mode'da çalışabilmelidir. Component marka bilgisini yalnızca theme layer üzerinden alır. Brand değiştirmek business veya tenant context'e göre gerçekleşebilir.

Light/Dark Başka Bir Tema Boyutudur

Color scheme kullanıcı veya sistem preference'ına bağlı ikinci eksendir. Background ve foreground gibi token'lar mode ile değişir. Brand aynı kalırken color scheme runtime'da değişebilir. Theme switcher brand'i değiştirmemelidir. Bu ayrım state management'i ve CSS selector yapısını sadeleştirir.

data-brand + data-theme Yaklaşımı

Root element üzerinde iki ayrı attribute aktif tema durumunu açıkça gösterir. CSS [data-brand="a"] altında brand variable'larını, [data-theme="dark"] altında mode variable'larını değiştirebilir. Gerekli birkaç token için kombinasyon selector'ı eklenebilir. JavaScript brand ve mode state'ini bağımsız yönetir. Storybook decorator'ları da iki değeri ayrı control olarak sunabilir.

Marka × Tema Kombinasyonlarının Yönetimi

İki marka ve iki mode dört görsel kombinasyon üretir, ancak dört tam theme dosyası oluşturmak zorunlu değildir. Ortak base semantic contract tekrar kullanılmalıdır. Brand layer yalnızca brand-specific değerleri, mode layer yalnızca color-scheme değişikliklerini taşır. Gerçek çapraz farklar küçük kombinasyon override'larıyla çözülür. Bu decomposition yeni marka eklendiğinde CSS tekrarını azaltır.

Brand A Light

Brand A Light, A markasının token'ları ile light color-scheme değerlerinin birleşimidir. Background açık, foreground koyu olabilir. Primary marka rengi light theme contrast kurallarına göre seçilir. Logo light surface'e uygun varyantı kullanır. Bu kombinasyon ayrı tam CSS theme olmadan iki token katmanının cascade sonucu oluşabilir.

Brand A Dark

Brand A Dark aynı marka kimliğini koyu surface sistemiyle birleştirir. Marka primary rengi dark background üzerinde yeterince görünür değilse mode-specific brand override gerekebilir. Font ve radius genellikle değişmeden kalır. Logo dark varyant kullanabilir. Visual regression bu kombinasyonu diğerlerinden bağımsız doğrular.

Brand B Light

Brand B Light farklı palette ve belki farklı font ailesi kullanabilir. Light background semantic contract yine aynı kalır. Component library markup değişmez. Brand B'nin primary foreground seçimi kendi contrast ihtiyacına göre belirlenir. Yeni marka onboarding template bu token set'i doldurarak yapılabilir.

Brand B Dark

Brand B Dark brand ve mode token'larının ikinci kombinasyonudur. Dark surface standard ortak olabilir fakat brand accent değeri B markasına göre değişir. Logo registry doğru dark asset'i seçer. Component-level exceptions mümkün olduğunca az tutulur. Automated screenshot ve contrast testleri bu kombinasyonu release öncesinde doğrular.

Kombinasyon Sayısının CSS Karmaşıklığını Artırmasını Önlemek

Her brand-mode çifti için tam kopya theme oluşturmak kombinasyon sayısı arttıkça ciddi tekrar üretir. Orthogonal tema boyutları ayrı katmanlar halinde tutulmalıdır. Ortak semantic contract ve CSS variable cascade bu tekrarın büyük bölümünü ortadan kaldırır. Yalnızca gerçekten kesişen birkaç token için kombinasyon selector'ı yazılır. Bu yaklaşım on marka ve iki mode bulunan sistemde yirmi bağımsız theme dosyası yönetme ihtiyacını azaltır.

data-brand ile Runtime Marka Değiştirme

data-brand yaklaşımı aktif marka kimliğini DOM root üzerinde açık biçimde temsil eder. CSS custom properties ilgili selector altında override edilir. Tailwind utility'leri semantic variable'lara bağlıysa yeniden build olmadan değerler değişir. JavaScript yalnızca attribute'ı güncelleyerek page reload olmadan marka switching yapabilir. Production multi-tenant sistemde brand state çoğu zaman tenant context'ten gelir ve kullanıcıya açık switcher yalnızca preview veya admin senaryosunda bulunur.

HTML Elementinde Marka Tanımlama

Aktif brand root HTML element üzerinde data attribute olarak tutulabilir. Bu yöntem selector'ı ve developer tools debugging'ini oldukça anlaşılır kılar. Brand değeri allowlist içinden gelmelidir. User-controlled string doğrudan selector veya style üretiminde kullanılmamalıdır. SSR varsa attribute ilk HTML'e eklenerek doğru marka ilk paint'te gösterilir.

CSS Custom Properties ile Override

Her brand selector semantic custom property set'ini override eder. Component aynı Tailwind utility class'larını kullanmaya devam eder. Primary, surface ve foreground gibi değişkenler runtime cascade ile yeni değeri alır. Font ve radius custom property'leri de aynı yöntemle değişebilir. Çok büyük token set'inde yalnızca gerçekten markaya göre değişen değerleri override etmek CSS boyutunu azaltır.

Tek Tailwind Build ile Birden Fazla Marka

Runtime CSS variable modeli sayesinde her marka için ayrı Tailwind compilation zorunlu değildir. Utility class set'i ortak kalır. Brand farklılığı custom property values üzerinden çözülür. Bu durum deployment ve cache stratejisini sadeleştirir. Çok farklı markup veya feature set'i olan markalar gerçekten ayrı build gerektirebilir, ancak yalnızca görsel token farkı için buna çoğu zaman ihtiyaç yoktur.

JavaScript ile Runtime Switching

Preview veya tema editörü gibi ekranlarda JavaScript root data-brand değerini değiştirebilir. CSS cascade anında yeni token set'ini uygular. Component re-render gerekmeyebilir. React context kullanılıyorsa context daha çok asset veya application state için gerekebilir. Görsel değerleri JavaScript object üzerinden her component'e prop olarak göndermek yerine CSS'in doğal cascade modelinden yararlanmak daha sade olabilir.

Page Reload Olmadan Kurumsal Kimlik Değiştirmek

CSS custom properties runtime'da değişebildiği için marka geçişi page reload olmadan gerçekleşebilir. Admin preview ekranında bu özellik oldukça kullanışlıdır. Logo ve font asset değişimi de brand state değişikliğine bağlanmalıdır. Yeni font yüklenmesi kısa layout shift yaratabilir. Preview ile production publish state birbirinden ayrılmalı ve kullanıcının yaptığı geçici düzenleme doğrudan canlı tenant'a uygulanmamalıdır.

Multi-Tenant SaaS'ta Tema Verisi Nerede Tutulmalı?

Multi-tenant theme data yalnızca frontend bundle içine hard-code edilmek zorunda değildir. Database tenant-specific değerleri tutabilir, configuration service doğrulanmış token document üretebilir ve server cache request çözümünü hızlandırabilir. Tema bilgisi tenant ID veya domain üzerinden request sırasında belirlenebilir. Eksik configuration için güvenli default theme fallback bulunmalıdır. Frontend'e yalnızca ihtiyaç duyduğu doğrulanmış ve normalize edilmiş token değerleri gönderilmelidir.

Database

Database tenant'ın logo, primary color ve seçilen font gibi özelleştirme değerlerini saklayabilir. Tam CSS string yerine structured field veya token document kullanmak daha güvenlidir. Schema version tema migration'larını kolaylaştırır. Audit history kim tarafından neyin değiştirildiğini gösterebilir. Database okuması her request'te doğrudan yapılmak yerine cache layer ile desteklenebilir.

Tenant Configuration

Tenant configuration yalnızca visual token değil feature ve locale gibi başka ayarlar da içerebilir. Tema alanları ayrı namespace altında tutulmalıdır. Validation hangi token'ın müşteri tarafından değiştirilebildiğini kontrol eder. Server normalize edilmiş theme object üretir. Frontend internal database schema'yı doğrudan bilmez.

JSON Token Document

JSON token document taşınabilir ve versionlanabilir yapı sunar. Primitive ve semantic values açık hierarchy altında tutulabilir. W3C Design Token formatına yaklaşmak tooling portability açısından yararlı olabilir. Runtime için document doğrudan browser'a gönderilmek yerine gerekli CSS variable set'ine dönüştürülebilir. Schema validation publish öncesinde çalıştırılmalıdır.

Server-Side Cache

Theme configuration sık değişmez fakat her page request'te gerekebilir. Server-side cache database load'u azaltır. Cache key tenant ve theme version içerebilir. Publish sonrası invalidation doğru yapılmalıdır. Stale theme kısa süre eski marka gösterebilir, bu nedenle cache TTL ve purge davranışı ürün ihtiyacına göre belirlenmelidir.

Tema Bilgisini Request Sırasında Çözmek

Custom domain veya route tenant'ı belirleyebilir. Server request başlangıcında tenant config'i çözer ve root HTML'e brand metadata ekler. İlk paint doğru marka ve theme ile gerçekleşir. Client daha sonra aynı configuration state'ini hydrate eder. Tenant resolution güvenlik açısından host header veya kullanıcı girdisine körü körüne güvenmemelidir.

Default Theme Fallback

Theme configuration eksik veya geçersiz olduğunda uygulama bozuk CSS ile açılmamalıdır. Güvenli default brand token set'i bulunmalıdır. Asset registry de default logo sağlayabilir. Monitoring fallback kullanımını görünür hale getirir çünkü sık fallback configuration problemi gösterebilir. Fallback markası tenant data isolation bilgisi sızdırmamalıdır.

Kullanıcının Kendi Marka Rengini Seçtiği Sistemler

White-label ürünlerde kullanıcıya color picker vermek güçlü özelleştirme sunar, ancak beraberinde contrast, palette generation ve güvenlik sorumluluğu getirir. Tek renk seçildiğinde hover, active ve subtle surface gibi türevler sistem tarafından üretilebilir. Foreground kontrastı otomatik doğrulanmalıdır. Geçersiz veya aşırı düşük contrast oluşturan değerler publish edilmemelidir. Preview ve publish aşamalarını ayırmak kullanıcıya değişiklikleri farklı component'lerde görme fırsatı verir.

Color Picker ile Marka Özelleştirme

Color picker kullanıcıdan normalize edilebilir bir renk değeri alır. Sistem HEX, OKLCH veya desteklediği başka formata dönüştürebilir. Kullanıcının doğrudan CSS declaration girmesine izin verilmemelidir. Seçilen renk preview theme variable'a uygulanır. Publish öncesinde contrast ve schema validation tamamlanır.

Tek Renkten Renk Skalası Oluşturmak

Base brand color lightness ve chroma ayarlarıyla tone scale'e dönüştürülebilir. Sistem hover, active ve subtle background için aday değerler üretir. Çok açık veya çok koyu input durumunda scale algoritması sınırlandırılmalıdır. Generated palette real component preview üzerinde gösterilmelidir. Kullanıcıya gerekirse ileri seviye manuel palette seçimi ayrı permission ile sunulabilir.

Otomatik Hover ve Active Renkleri

Hover ve active values belirli lightness veya color-mix kuralıyla türetilebilir. Aynı algoritmanın light ve dark theme'de farklı davranması gerekebilir. Interaction state'leri yeterince ayırt edilebilir olmalıdır. Kullanıcı primary rengi değiştirdiğinde bütün state token'ları yeniden hesaplanır. Bu sonuçlar database'de ayrı values olarak saklanabilir veya runtime'da deterministik üretilebilir.

Otomatik Foreground Kontrastı

Sistem primary background üzerinde beyaz ve koyu foreground adaylarını contrast açısından karşılaştırabilir. Güvenli seçenek token'a atanır. Hiçbir aday yeterli değilse background tonu düzeltilmeli veya publish engellenmelidir. Foreground seçimi yalnızca estetik preference'a bırakılmamalıdır. Button dışında link, badge ve notification gibi farklı kullanım yüzeyleri ayrıca test edilmelidir.

Geçersiz Renkleri Engellemek

Input parse edilmeden style katmanına gönderilmemelidir. Server yalnızca desteklenen renk formatlarını kabul etmelidir. Chroma veya alpha kullanımına ürün policy'sine göre sınır getirilebilir. Transparent primary button gibi beklenmeyen sonuçlar böylece engellenir. Validation hem client preview hem server publish aşamasında çalışmalıdır.

Önizleme ve Publish Akışı

Preview değişikliği yalnızca admin oturumunda geçici state olarak uygulanabilir. Kullanıcı bütün component matrix üzerinde yeni rengi görmelidir. Contrast veya visual test başarısızsa sistem açıklayıcı feedback verir. Publish validated token document'in yeni version'ını oluşturur. Rollback için önceki version saklanabilir.

Dinamik Tema Sistemlerinde Güvenlik

Dinamik theme özelleştirme kullanıcı girdisini CSS'e yaklaştırdığı için güvenlik sınırları açık tasarlanmalıdır. Serbest CSS veya selector kabul etmek yerine yapılandırılmış token değerleri kullanılmalıdır. Renk ve boyut gibi alanlar schema ve allowlist ile doğrulanmalıdır. Tenant identifier selector üretimine doğrudan eklenmemelidir. Content Security Policy kullanılan uygulamalarda runtime style yaklaşımının policy ile uyumu ayrıca planlanmalıdır.

CSS Injection Riski

Kullanıcı input'u doğrudan CSS string içine eklenirse beklenmeyen declaration veya URL behavior'ı oluşabilir. Renk input'u yalnızca color parser tarafından kabul edilen formata dönüştürülmelidir. Serbest property name alınmamalıdır. Server kendi allowlist token set'ini üretmelidir. Browser tarafı validation tek güvenlik sınırı olarak görülmemelidir.

Kullanıcı Girdisini Doğrudan <style> İçine Yazmamak

Serbest kullanıcı metnini <style> içine interpolation ile yerleştirmekten kaçınılmalıdır. Structured theme config server tarafından doğrulanmalı ve güvenli CSS variable values üretilmelidir. Mümkünse predefined selector ile sadece property value set edilmelidir. Runtime style attribute kullanımı CSP ile çatışabilir. Uygulamanın security policy'si theme implementation seçimini etkilemelidir.

Renk Değerlerini Allowlist / Schema ile Doğrulamak

Schema değer formatını, alpha kullanımını ve zorunlu token'ları tanımlayabilir. Custom parser input'un geçerli color value olup olmadığını kontrol eder. Sadece birkaç hazır palette seçeneği sunuluyorsa allowlist daha basit ve güvenlidir. Advanced white-label özellikte normalize edilmiş OKLCH veya HEX value kabul edilebilir. Server validation sonucu theme version içine kaydedilmelidir.

Tenant ID ve Selector Güvenliği

Tenant ID kullanıcı input'undan doğrudan CSS selector oluşturmak için kullanılmamalıdır. Uygulama tenant'ı server-side authorization context üzerinden çözmelidir. CSS'te gerekiyorsa güvenli internal brand key kullanılır. Tenant A'nın theme configuration'ı Tenant B request'ine uygulanmamalıdır. Cache key ve lookup query tenant isolation kurallarına uymalıdır.

Server-Side Validation

Client validation kullanıcı deneyimini iyileştirir fakat atlatılabilir. Publish endpoint bütün theme token'larını yeniden doğrulamalıdır. Contrast policy server'da da uygulanabilir. Unknown token veya unsupported type reddedilir. Audit log değişikliği yapan kullanıcı ve yeni theme version bilgisini saklayabilir.

Content Security Policy ile Uyumluluk

Strict CSP inline style veya script kullanımını sınırlandırabilir. Theme architecture nonce, hash veya external stylesheet modeline göre planlanmalıdır. Pre-paint theme script kullanılıyorsa CSP çözümü tasarımın parçası olmalıdır. Dinamik CSS variable injection için framework ve browser behavior test edilmelidir. Güvenlik policy'sini gevşetmek yerine theme implementation mevcut CSP hedefleriyle uyumlu hale getirilmelidir.

Figma ile Tailwind Arasında Tek Bir Token Kaynağı Oluşturmak

Tasarım ile kodun farklı token listeleri kullanması zaman içinde drift oluşturur. Figma Variables veya token plugin yaklaşımı tasarım kararlarını yapılandırılmış data haline getirebilir. Bu data Git repository'deki token JSON ile kontrollü senkronize edilebilir. Tailwind theme mapping aynı kaynaktan üretildiğinde naming parity korunur. Değişikliklerin doğrudan production'a akması yerine pull request ve CI validation üzerinden geçmesi güvenli governance sağlar.

Figma Variables

Figma Variables renk, spacing ve benzeri tekrar eden değerleri tasarım dosyasında merkezi hale getirir. Mode özelliği light, dark veya farklı brand context'leri modellemek için kullanılabilir. Kod tarafındaki token hiyerarşisiyle isimlerin uyumlu olması handoff'u kolaylaştırır. Figma tek source of truth seçilecekse export pipeline güvenilir olmalıdır. Git tarafındaki değişikliklerle conflict ownership önceden tanımlanmalıdır.

Tokens Studio

Tokens Studio gibi token odaklı araçlar tasarım değerlerini JSON tabanlı workflow'a taşımaya yardımcı olabilir. Primitive ve semantic reference ilişkileri görsel araçta yönetilebilir. Kurum vendor-specific özellikleri kullanırken export format portability'sini değerlendirmelidir. Git entegrasyonu tasarım değişikliğini code review sürecine bağlayabilir. Tool seçimi token modelinin kendisinden daha önemli hale gelmemelidir.

Design Token JSON

JSON token document platform bağımsız kaynak olarak kullanılabilir. Color, dimension ve typography values structured biçimde tutulur. Alias reference semantic katmanı primitive katmana bağlar. Schema validation hatalı veya eksik token'ları CI'da yakalayabilir. Web build aynı document'tan Tailwind-facing CSS üretirken mobil pipeline kendi native formatını oluşturabilir.

Kod ile Tasarım Arasındaki Naming Parity

Figma'da Primary/Button, kodda tamamen farklı blueAction adı kullanılıyorsa iletişim zorlaşır. Naming parity birebir syntax eşitliği olmak zorunda değildir fakat açık deterministic mapping bulunmalıdır. Tasarımcı ve geliştirici review sırasında aynı token'ı kolayca bulmalıdır. Otomatik parity check missing veya renamed token'ı tespit edebilir. Naming convention her iki disiplin tarafından ortak yönetilmelidir.

Tasarımcı Token Değiştirdiğinde Ne Olmalı?

Tasarım değişikliği doğrudan production CSS'i sessizce değiştirmemelidir. Export yeni token diff oluşturur ve pull request açılır. CI contrast, visual regression ve component testlerini çalıştırır. Frontend ve tasarım reviewer değişikliğin kapsamını görür. Merge sonrasında package version ve release note oluşturulabilir.

W3C Design Token Formatı

Design Tokens Community Group'un güncel 2025.10 Format Module çalışması design token'ları araçlar arasında daha taşınabilir biçimde temsil etmek için ortak yapı tanımlar. Güncel spesifikasyonda token değeri, type bilgisi ve reference mekanizması açık biçimde modellenir. Token type color, dimension, duration ve diğer tanımlı değer sınıflarından biri olabilir. Reference yapısı semantic ilişkiler kurmaya ve tekrar eden değerleri azaltmaya yardımcı olur. Vendor-bağımsız model Figma, transformation pipeline ve native platform çıktıları arasında daha açık kontrat oluşturabilir. :contentReference[oaicite:17]{index=17}

Token Değeri

Token'ın gerçek tasarım verisi $value alanında temsil edilir. Değer token type'a göre string, object veya başka tanımlı yapı olabilir. Örneğin modern color token yalnızca basit HEX string olmak zorunda değildir ve color space bilgisi taşıyabilir. Transformation tool target platformun ihtiyaç duyduğu formata dönüşüm yapabilir. Merkezi source raw platform syntax yerine standard token modelini korur. :contentReference[oaicite:18]{index=18}

Token Tipi

$type değerin color, dimension veya başka hangi tasarım tipine ait olduğunu açıklar. Güncel DTCG formatında araçların type'ı value içeriğinden tahmin etmemesi ve tanımlı type kurallarını kullanması beklenir. Group seviyesinde type inheritance belirli token set'lerinde tekrar azaltabilir. Type bilgisi transformation sırasında platform-specific output üretimini kolaylaştırır. Schema validation yanlış type-value kombinasyonunu erken tespit edebilir. :contentReference[oaicite:19]{index=19}

Token Açıklaması

Token description teknik değerin neden var olduğunu insanlara anlatır. “Primary background” gibi isim tek başına kullanım sınırlarını her zaman açıklamayabilir. Description style guide generator veya development tooling içinde gösterilebilir. Yeni ekip token'ın yanlış bağlamda kullanılmasını daha kolay önleyebilir. Kurumsal token governance'ta önemli semantic token'lara açıklama eklemek uzun vadeli bakım değerini artırır.

Alias / Reference

Reference token'ın başka token değerini kullanmasını sağlar. Primitive renk semantic primary tarafından referans alınabilir. Bu yapı değer tekrarını azaltır ve semantic mapping'i açık hale getirir. Güncel DTCG formatında token reference ve JSON Pointer tabanlı $ref mekanizmaları tanımlanmıştır. Transformation pipeline reference'ları doğru sırada çözmelidir. :contentReference[oaicite:20]{index=20}

Renk, Boyut, Font ve Shadow Token'ları

Design token formatı farklı tasarım değer tiplerini standart yapı içinde ifade etmeyi hedefler. Color token color space ve component values gibi veri taşıyabilir. Dimension belirli bir value-unit yapısıyla temsil edilir. Typography ve shadow gibi daha bileşik değerler platform mapping gerektirebilir. Cross-platform pipeline her type için açık transformer kurallarına sahip olmalıdır.

Vendor-Bağımsız Token Modelinin Avantajı

Token kaynağı yalnızca belirli tasarım veya CSS aracının proprietary formatına bağlı olduğunda migration maliyeti artar. Açık token modeli farklı tool'ların aynı veriyi okuyabilmesini kolaylaştırır. Tailwind yalnızca web target'larından biri olur. Mobil veya başka platformlar aynı source üzerinden kendi çıktısını üretebilir. Vendor-specific metadata gerekirse standard core model korunarak extension alanları kullanılabilir.

Figma → Git → Tailwind Otomasyon Akışı

Olgun token pipeline tasarım değişikliklerini kontrollü software delivery sürecine bağlar. Figma tarafında token güncellendikten sonra JSON export edilir veya senkronizasyon aracı Git'e değişiklik hazırlar. Pull request token diff'ini görünür hale getirir. Transformation adımı CSS custom properties ve Tailwind mapping üretir. CI validation tamamlandıktan sonra versionlanan theme package production'a dağıtılır.

Figma'da Token Güncelleme

Tasarımcı yeni renk veya spacing değerini doğrudan component override etmek yerine ilgili token üzerinde değiştirir. Figma component'leri aynı variable'ı kullandığı için tasarım etkisi görünür hale gelir. Token description değişiklik gerekçesini destekleyebilir. Büyük semantic değişiklik öncesinde RFC gerekebilir. Değişiklik export aşamasına kadar design workspace içinde kalır.

Token JSON Oluşturma

Export işlemi tasarım token'larını yapılandırılmış JSON document'e dönüştürür. Naming convention ve alias ilişkileri korunmalıdır. Otomasyon timestamp veya gereksiz metadata nedeniyle her export'ta büyük diff üretmemelidir. JSON schema validation daha bu aşamada çalıştırılabilir. Generated file ile hand-written source ayrımı repository'de açık tutulmalıdır.

Pull Request

Token değişikliği normal code change gibi pull request üzerinden review edilebilir. Diff hangi primary, spacing veya font değerinin değiştiğini gösterir. Tasarım ve frontend reviewer birlikte etkisini değerlendirir. Breaking token rename ayrı şekilde işaretlenebilir. CI visual preview link'i reviewer'ın değişikliği gerçek component'lerde görmesini sağlar.

Style Dictionary Dönüşümü

Style Dictionary benzeri transformation tool token source'u platform-specific çıktılara çevirebilir. Web için CSS custom property, iOS ve Android için native resource üretilebilir. Transformer semantic alias'ları target platform formatına çözebilir. Kurum özel naming veya unit dönüşümü ekleyebilir. Tool configuration source token modelini mümkün olduğunca bozmadan çalışmalıdır.

CSS Custom Properties Üretme

Web output semantic ve primitive token'ları CSS variable olarak üretebilir. Brand ve mode selector'ları ayrı dosyalara bölünebilir. Generated dosya elle düzenlenmemelidir. Source map veya yorum bilgisi debugging'i kolaylaştırabilir. Build sonunda gereksiz duplicate variable oluşup oluşmadığı kontrol edilmelidir.

Tailwind @theme ile Mapping

Generated semantic CSS variables Tailwind-facing theme variables'a bağlanabilir. @theme inline alias modeli runtime değişebilen semantic değerlerle iyi çalışır. Utility isimleri stabil kalırken brand values dış katmanda değişir. Mapping dosyası küçük ve framework-specific adapter görevi görür. Cross-platform token source Tailwind syntax'ına doğrudan bağımlı hale gelmez. :contentReference[oaicite:21]{index=21}

CI Validation

CI token schema, naming, contrast ve generated file consistency kontrolü çalıştırabilir. Visual regression theme değişikliğinin component etkisini gösterir. Build test Tailwind mapping'in syntax açısından geçerli olduğunu doğrular. Breaking token rename consumer package kullanımını etkiliyorsa tespit edilir. Başarılı pipeline ardından package release'e izin verir.

Production Deployment

Token package versionlandıktan sonra uygulamalar controlled dependency update yapabilir. Monorepo'da tek commit ile bütün uygulamalar güncellenebilir. Ayrı repository modelinde release automation changelog oluşturabilir. Critical rebranding feature flag veya staged rollout ile yayınlanabilir. Production monitoring unexpected visual veya performance problemi olup olmadığını takip eder.

Style Dictionary ile Cross-Platform Token Yönetimi

Web, iOS ve Android aynı marka kimliğini farklı teknik formatlarda tüketir. Cross-platform token pipeline tek semantic kaynaktan her platforma uygun output üretir. Style Dictionary gibi transformation yaklaşımı bu mapping için kullanılabilir. Tailwind web tarafında generated CSS values üzerinden çalışır. Yalnızca web ürününde ise ayrı token tooling eklemek her zaman gerekli değildir.

Tek Token Kaynağından Web Çıktısı

Token source web için CSS custom properties'e dönüştürülebilir. Light, dark ve brand selector'ları generated output'ta oluşturulabilir. Tailwind mapping utility API'ye bağlanır. Custom CSS ve third-party component'ler de aynı variables'ı okuyabilir. Böylece web ekosistemi tek token kontratı etrafında birleşir.

iOS Token Çıktısı

Color ve dimension token'ları Swift veya asset catalog formatına dönüştürülebilir. Platform-specific typography mapping gerekebilir. Semantic token isimleri web ile aynı kavramsal karşılığı korur. iOS developer marka değerini elle kopyalamaz. Release pipeline generated native token package'i versionlayabilir.

Android Token Çıktısı

Android tarafında resource XML, Kotlin veya Compose theme output üretilebilir. Dimension unit dönüşümleri target platform kurallarına uygun yapılmalıdır. Semantic role isimleri cross-platform design language'i korur. Brand switching native uygulama architecture'ına göre farklı runtime mechanism kullanabilir. Source token modeli yine ortak kalır.

Web ve Mobil Kurumsal Kimliği Eşitlemek

Aynı source token kullanımı web ve mobil arasında renk ve spacing drift'ini azaltır. Platformların birebir pixel eşitliği hedeflenmemelidir. Native convention gerektiren farklar transformation veya platform semantic layer'da yönetilebilir. Ortak brand meaning korunurken platform usability önceliği devam eder. Design token governance bu istisnaları açıkça belgeler.

Tailwind @theme Ne Zaman Tek Başına Yeterli?

Tek web uygulaması ve sınırlı design token set'i varsa Tailwind theme variables yeterli olabilir. CSS-first model değerleri doğrudan CSS içinde yönetmeyi kolaylaştırır. Ayrı mobile output veya Figma synchronization gerekmiyorsa ek tooling operasyon maliyeti yaratabilir. Shared theme CSS package farklı web uygulamalarına import edilebilir. Tailwind dokümantasyonu theme variable dosyalarının project'ler arasında paylaşılabileceğini ve package haline getirilebileceğini belirtiyor. :contentReference[oaicite:22]{index=22}

Ne Zaman Ayrı Token Tooling Gerekir?

Web, iOS ve Android aynı token kaynağını kullanacaksa transformation pipeline değerli hale gelir. Figma integration, schema validation ve token versioning ihtiyacı da ayrı tooling gerektirebilir. Onlarca brand ve product variant manuel CSS dosyalarını zorlayabilir. Token source'un framework bağımsız tutulması gelecekteki platform değişikliklerini kolaylaştırır. Tooling yatırımı organization ölçeği ve değişiklik sıklığıyla birlikte değerlendirilmelidir.

Design System Component'leri Token'lara Nasıl Bağlanmalı?

Component library token sisteminin en görünür tüketicisidir. Button, Input ve Card gibi primitive'ler ham renk veya spacing değeri kullanmak yerine semantic veya component token'lara bağlanmalıdır. Böylece brand ve mode değişikliği component markup'ını etkilemez. State ve accessibility behavior ortak component logic içinde kalır. Application ekranı design system kararlarını yeniden üretmek yerine bu primitive'leri birleştirir.

Button

Button background, foreground, radius ve motion token'larını semantic variant üzerinden almalıdır. Primary, secondary ve destructive variant gerçek brand renklerini bilmez. Focus ring ve disabled state component standardı olarak korunur. Size variant spacing ve typography token'larını kullanır. Böylece tek Button bütün brand ve theme matrix'inde çalışabilir.

Input

Input border, surface, foreground ve placeholder semantic değerleri kullanır. Invalid state danger token'a bağlanır. Focus behavior accessibility standardına göre component içinde çözülür. Brand yalnızca token mapping'i değiştirir. Form screen geliştiricisi her input için farklı class set yazmaz.

Card

Card surface, border, radius ve elevation token'larına bağlanır. Marka flat tasarım kullanıyorsa shadow token none olabilir. Compact product farklı padding token seçebilir. Card component direct brand condition içermez. Container query responsive layout davranışını placement'tan bağımsız yönetebilir.

Modal

Modal overlay, surface ve elevation değerlerini token sisteminden alır. Focus trap ve keyboard behavior görsel theme'den bağımsız component responsibility olarak kalır. Dark mode overlay opacity ayrı semantic token olabilir. Motion reduced-motion preference'a uyum sağlar. Logo veya brand content modal component'in genel primitive yapısına gömülmemelidir.

Navigation

Navigation active, hover ve foreground state'leri semantic interaction token'larıyla yönetilir. Brand accent selected indicator'a yansıyabilir. Dark mode markup değişmeden token override ile çalışır. Mobile ve desktop layout farklı component structure kullanabilir fakat görsel token contract paylaşılır. Active state yalnızca renkle belirtilmemeli ve accessibility semantics korunmalıdır.

Table

Table header surface, row border ve hover state token'lara bağlanabilir. Dense ve comfortable spacing variant ayrı semantic layout token kullanabilir. Status cell'leri shared badge veya status color sistemini tekrar kullanır. Dark theme contrast özellikle zebra veya hover satırlarında test edilmelidir. Large data table performance visual theme logic'inden ayrı ele alınmalıdır.

Alert

Alert success, warning, danger ve information semantic token ailelerini kullanır. Background, border, icon ve foreground ilişkisi birlikte tanımlanır. Markanın primary rengi status meaning'in önüne geçmemelidir. Dismiss interaction ve focus behavior ortak component logic içinde kalır. Alert component ham palette isimlerini markup'ta taşımamalıdır.

Badge

Badge compact yüzey olduğu için foreground contrast özellikle önemlidir. Semantic status veya neutral variant kullanabilir. Radius brand token'a bağlanır. Çok fazla renk varyantı anlamı zayıflatabilir. Badge'in semantic label text'i renk dışında da durumu açıklamalıdır.

Component İçinde Ham Renk Kullanmamak

Ham HEX veya primitive palette kullanımı component'i mevcut palette'e bağlar. Semantic token component'in niyetini açıklar. Rebranding sırasında mapping değişir ve component release gerekmeyebilir. Lint hard-coded HEX ve belirli primitive kullanımını engelleyebilir. Gerçek istisnalar documentation ve review ile yönetilmelidir.

Tailwind ile Component Variant Yönetimi

Component variant ile theme aynı kavram değildir. Variant component'in semantic veya davranışsal alternatifini, theme ise bu variant'ın gerçek görsel değerlerini belirler. Primary button bütün markalarda primary kalır fakat rengi ve radius'u değişebilir. Size ve state variant'ları da brand context'ten bağımsız tutulmalıdır. Theme logic'i component prop'larına taşımamak ortak library'nin ölçeklenmesini kolaylaştırır.

Visual Variant ile Theme Arasındaki Fark

Visual variant primary, secondary veya destructive gibi component seviyeli seçimdir. Theme bu variant'ın hangi token values ile render edileceğini belirler. brand="a" prop'u component API'sine eklemek bu iki kavramı karıştırabilir. Brand root context veya CSS cascade tarafından çözülmelidir. Component consumer yalnızca kullanım amacını seçmelidir.

Primary / Secondary / Destructive Variant

Bu variant'lar business anlam taşıyan reusable component API'si sağlar. Primary ana action, secondary alternatif action ve destructive riskli action için kullanılabilir. Her variant semantic token grubuna bağlanır. Marka gerçek color mapping'i override eder. Accessibility state davranışı bütün brand'lerde aynı kalır.

Size Variants

Size variant typography, padding ve minimum height değerlerini birlikte değiştirir. Small, medium ve large gibi sınırlı set yeterlidir. Arbitrary height prop design consistency'yi zayıflatabilir. Touch target minimumları accessibility açısından korunmalıdır. Marka density ihtiyacı varsa size mapping theme veya product config seviyesinde ayrıca ele alınabilir.

State Variants

Loading, disabled, selected veya invalid gibi state'ler component behavior'ını ifade eder. State yalnızca renk class'ı değildir ve ARIA veya native HTML attribute davranışıyla birlikte uygulanmalıdır. Theme state'in gerçek görsel değerini token'larla belirler. Loading motion reduced-motion preference'a uyabilir. State logic component'in marka isminden bağımsız kalmalıdır.

Theme Logic'i Component Props'a Taşımaktan Kaçınmak

Her component'e theme veya brand prop'u göndermek prop drilling ve koşullu class kullanımını artırır. CSS custom property cascade bu problem için doğal çözüm sunar. Component yalnızca semantic variant ve state bilgisini alır. Asset gibi CSS ile çözülemeyen durumlar merkezi theme context üzerinden yönetilebilir. Theme state'in component API'sine yayılmaması test ve reuse maliyetini düşürür.

@apply Kurumsal Design System'de Kullanılmalı mı?

@apply bazı reusable CSS abstraction'larında yararlı olabilir, fakat Tailwind utility-first çalışma modelini tamamen klasik class abstraction'a dönüştürmek için kullanılmamalıdır. Design system primitive'lerinde ortak utility kombinasyonunu kapsüllemek anlamlı olabilir. Application screen'lerinde ise utility'lerin doğrudan kullanımı stilin component yakınında kalmasını sağlar. Tailwind v4 custom utility yaklaşımı bazı tekrar eden davranışlar için daha doğal seçenek sunabilir. Kurum kullanım kuralını netleştirerek ekiplerin her yerde farklı abstraction üretmesini önlemelidir.

Utility-First Yaklaşımın Avantajı

Utility class'lar style decision'ı markup yakınında görünür hale getirir. Global CSS selector etkisini azaltır. Token-aware utility API design system sınırlarını korur. Responsive ve state variant'ları aynı yerde okunabilir. Component abstraction yalnızca gerçekten tekrar eden semantic yapı olduğunda eklenir.

@apply Kullanımının Riskleri

Aşırı @apply kullanımı Tailwind'i yalnızca utility yazıp tekrar custom CSS class üretme aracına çevirebilir. Style source iki farklı yerde takip edilmek zorunda kalır. Variant behavior bazı karmaşık selector'larda okunması zor hale gelebilir. Application-specific class'lar tekrar büyüyebilir. Bu nedenle kullanım design system primitive ve kontrollü abstraction ile sınırlandırılabilir.

Design-System Primitive'lerinde Kullanım

Button gibi temel primitive custom CSS component olarak dağıtılıyorsa @apply bazı utility kombinasyonlarını merkezi tutabilir. Yine de token values semantic utility veya variable üzerinden gelmelidir. Component states ve accessibility selectors açık görünmelidir. Generated CSS size takip edilmelidir. Framework component library kullanılıyorsa utility class composition çoğu zaman daha doğrudan olabilir.

Application Screen'lerinde Utility Kullanımını Korumak

Sayfa layout ve bir defaya özgü composition için utility kullanmak geliştirme hızını korur. Her flex veya margin kombinasyonu için custom class oluşturmak gerekmez. Design token scale utility seçimini sınırlar. Tekrarlanan pattern fark edildiğinde reusable component'e çıkarılabilir. Böylece abstraction gerçek ihtiyaçtan doğar.

Custom @utility Ne Zaman Daha Doğru?

Tailwind v4 custom utility mekanizması framework variant sistemiyle çalışan özel reusable utility tanımlamak için kullanılabilir. Bir davranış tek CSS property veya reusable pattern seviyesindeyse custom utility anlamlı olabilir. Component semantics gerektiren daha büyük yapı yine component library içinde kalmalıdır. Naming organization style guide ile uyumlu olmalıdır. Custom utility sayısı kontrolsüz büyümemelidir.

Container Queries ile Yeniden Kullanılabilir Kurumsal Component'ler

Viewport breakpoint yaklaşımı component'in hangi sayfa bölgesinde kullanıldığını her zaman doğru temsil etmez. Aynı Card geniş main content içinde ve dar sidebar içinde farklı davranmak isteyebilir. Container query component'in parent alanına göre layout değiştirmesini sağlar. Tailwind güncel variant sisteminde container query variant'ları da theme namespace'leriyle ilişkilidir. Design system component'lerini placement'tan daha bağımsız hale getirmek reuse oranını artırır. :contentReference[oaicite:23]{index=23}

Viewport-Based Responsive Design'ın Sınırları

Viewport geniş olabilir fakat component dar sidebar içinde bulunabilir. Sadece lg: breakpoint kullanılırsa component yanlış horizontal layout'a geçebilir. Reusable component global page width yerine kendi available space'ini bilmelidir. Container query bu bağımsızlığı sağlar. Sayfa layout breakpoint'leri yine viewport-based kalabilir.

Parent Container'a Göre Component Tasarlamak

Parent element container olarak işaretlenir ve child component belirli container width threshold'larında style değiştirir. Bu behavior component'in farklı sayfalarda tekrar kullanılmasını kolaylaştırır. Breakpoint isimleri component design scale'e göre belirlenebilir. Layout testleri farklı container width'lerinde çalıştırılmalıdır. Theme ve responsive behavior birbirinden bağımsız tutulmalıdır.

Aynı Card'ı Sidebar ve Main Content'te Kullanmak

Card dar alanda vertical, geniş alanda horizontal olabilir. Viewport genişliği her iki instance için aynı olduğu halde container size farklıdır. Container query her instance'a doğru layout verir. Component consumer'a compact prop göndermek zorunda kalmayabilir. Gerçek semantic variant gerekiyorsa container behavior'dan ayrı tutulmalıdır.

Design System Component'lerini Placement'tan Bağımsızlaştırmak

Component belirli page template'e aşırı bağlı olduğunda reuse değeri düşer. Container-aware layout kendi alanına adapte olabilir. Typography ve spacing token'ları theme sisteminden gelmeye devam eder. Storybook farklı container sizes ile component'i test edebilir. Bu yaklaşım component API'sindeki layout prop sayısını azaltabilir.

Monorepo'da Kurumsal Tema Yönetimi

Monorepo ortak token ve component paketlerini birçok uygulama arasında paylaşmayı kolaylaştırır. Merkezi design token package theme variables ve brand files içerebilir. Component library aynı token contract'ı kullanır. Product-specific token'lar shared package'tan ayrılmalıdır. Versioning monorepo içinde bile breaking change etkisini görünür tutmak için değerlidir.

Merkezi Design Token Paketi

Token package primitive ve semantic kaynakları ortak yerde tutar. Generated CSS veya JSON output burada yayınlanabilir. Bütün uygulamalar aynı dependency üzerinden değerleri alır. Pull request değişikliğin etkileyeceği consumer'ları gösterir. Package owner design system ekibi olabilir.

Merkezi Component Library

Component library Button, Input ve Card gibi ortak primitive'leri sunar. Token package bağımlılığı üzerinden theme values kullanır. Product application component'in internals'ını kopyalamaz. Accessibility bug tek yerde düzeltilir. Visual tests bütün brand matrix'i library seviyesinde çalıştırılabilir.

Her Uygulamanın Aynı Theme Package'ı Kullanması

Shared theme dependency renk ve typography drift'ini azaltır. Uygulamalar farklı Tailwind entry CSS dosyalarına aynı package'i import edebilir. Application-specific override yalnızca açık extension point'lerde yapılmalıdır. Upgrade automation eski package version kullanan uygulamaları görünür hale getirir. Monorepo tooling dependency graph üzerinden etki analizi yapabilir.

Marka Bazlı Theme Package'ları

Çok büyük markalarda base token package yanında brand-specific package'lar bulunabilir. Uygulama yalnızca ihtiyaç duyduğu brand files'ı import edebilir. White-label runtime switching gerekiyorsa bütün gerekli brand token'ları ortak bundle'a alınabilir. Package naming açık semantic model izlemelidir. Aynı primitive değerlerin brand package'larda gereksiz tekrarından kaçınılmalıdır.

Shared Token ile Product-Specific Token'ı Ayırmak

Kurumsal primary ve typography bütün ürünlerde shared olabilir. Belirli analytics ürünü yalnızca kendine özgü chart token'larına ihtiyaç duyabilir. Bu değerleri global package'e eklemek diğer ürünlerin token alanını gereksiz büyütür. Product token base semantic values'a referans verebilir. Ownership sınırı package structure ile görünür hale getirilebilir.

Theme Paketini NPM Üzerinden Paylaşmak

Theme CSS'i ayrı package haline getirmek monorepo dışında da ortak kimlik dağıtmayı kolaylaştırır. Tailwind'in güncel dokümantasyonu theme variables'ın CSS dosyasında tutulup farklı projelerde import edilebileceğini ve package olarak paylaşılabileceğini açıkça belirtiyor. Private registry kurumsal package erişimini kontrol eder. Framework bağımsız CSS token package React, Vue veya başka web uygulamalarında aynı şekilde kullanılabilir. Versioning consumer'ların theme değişikliklerini kontrollü şekilde almasını sağlar. :contentReference[oaicite:24]{index=24}

Kurumsal CSS Package Oluşturmak

Package generated primitive ve semantic custom properties içerebilir. Base styles ve Tailwind mapping ayrı entry point olarak sunulabilir. Consumer yalnızca gerekli dosyaları import eder. Package'ın side effect ve tree-shaking davranışı build araçlarıyla test edilmelidir. README hangi layer'ın hangi sırada import edileceğini açıklamalıdır.

@theme Dosyasını Paketlemek

Tailwind-facing theme variables ayrı CSS dosyasında tutulabilir. Consumer Tailwind import'undan sonra veya architecture'ın gerektirdiği layer sırasıyla bu dosyayı yükler. Default theme namespace override ediliyorsa etkisi açıkça belgelenmelidir. Package update yeni utility API üretebilir. Bu nedenle theme file değişikliği de versioning açısından değerlendirilmelidir.

Uygulamalarda Import Etmek

Uygulama package CSS entry point'ini ana stylesheet içinde import eder. Brand-specific entry gerekiyorsa deployment veya runtime modeline göre seçim yapılır. Import sırası cascade behavior'ı etkiler. Consumer'ın kendi overrides katmanı açıkça tanımlanmalıdır. Build test package upgrade sonrası generated CSS'i karşılaştırabilir.

Private Registry Kullanımı

Kurumsal theme package public yayınlanmak zorunda değildir. Private NPM registry erişim kontrolü ve version distribution sağlar. CI token ile package publish yapılabilir. Consumer repository dependency update automation kullanabilir. Secret management package registry credential'ları için standard uygulanmalıdır.

Framework'ten Bağımsız Tema Dağıtımı

CSS custom properties React veya başka UI framework'e bağlı değildir. Aynı theme package farklı frontend stack'lerinde kullanılabilir. Component library ayrı framework package olabilir. Token source daha da yukarıda JSON tabanlı tutulursa native platformlar da aynı kararlardan yararlanabilir. Bu separation vendor ve framework bağımlılığını azaltır.

Design Token Versioning

Token değişikliği görsel API değişikliği gibi ele alınmalıdır çünkü birçok consumer component aynı değere bağlı olabilir. Küçük color düzeltmesi patch, yeni backward-compatible token minor ve mevcut semantic token'ın anlamını değiştiren güncelleme major olabilir. Her organization kendi semantic versioning yorumunu açıkça tanımlamalıdır. Token rename deprecation süreci gerektirebilir. Migration guide özellikle component veya package consumer'larının manuel aksiyon alacağı değişikliklerde önemlidir.

Token Değişikliği Bir API Değişikliği midir?

Token contract consumer'ın kullandığı isim ve semantic anlamı tanımlar. Bir token silindiğinde build kırılabilir. Değer ciddi biçimde değiştiğinde build kırılmasa bile görsel behavior değişebilir. Bu nedenle token package API gibi yönetilebilir. Visual diff ve semantic impact birlikte değerlendirilmelidir.

Semantic Versioning

Semantic Versioning token package release'lerini consumer etkisine göre sınıflandırmaya yardımcı olur. Ancak görsel değişikliklerin semantiği klasik code API kadar net olmayabilir. Organization patch, minor ve major örneklerini style guide içinde tanımlamalıdır. Automation rename ve remove gibi mekanik breaking change'leri yakalayabilir. Görsel breaking karar için insan review gerekebilir.

Patch

Patch küçük düzeltme ve aynı semantic anlamı koruyan value iyileştirmesi için kullanılabilir. Örneğin contrast'ı artırmak amacıyla çok küçük ton düzeltmesi patch sayılabilir. Buna rağmen visual regression sonucu kontrol edilmelidir. Çok geniş görsel değişiklik patch olarak saklanmamalıdır. Consumer release note değişikliğin nedenini görmelidir.

Minor

Yeni token eklemek mevcut consumer'ı bozmadığı için minor release olarak değerlendirilebilir. Yeni brand veya component token set'i de backward-compatible ise bu gruba girebilir. Existing token semantic anlamı değişmemelidir. Generated output addition CSS size etkisi açısından incelenmelidir. Documentation yeni kullanım alanını açıklamalıdır.

Major

Token silmek, rename etmek veya semantic contract'ı bozmak major change olabilir. Consumer migration gerekebilir. Theme architecture yeniden yapılandırılıyorsa adapter period sağlanabilir. Codemod veya alias backward compatibility sürecini kolaylaştırabilir. Major release migration guide ile yayınlanmalıdır.

Token Rename

Token rename bütün code reference'larını etkileyebilir. Yeni token eklenip eski isim geçici alias olarak korunabilir. Deprecation warning lint veya documentation üzerinden gösterilebilir. Consumer adoption ölçülebilir. Sonraki major version'da eski isim kaldırılır.

Token Deprecation

Deprecated token yeni kullanımlara kapatılmalı fakat mevcut consumer'a migration süresi verilmelidir. Linter yeni reference'ı warning olarak işaretleyebilir. Replacement token açıkça belirtilmelidir. Usage search kalan consumer'ları gösterir. Removal ancak migration yeterli seviyeye ulaştığında yapılmalıdır.

Breaking Theme Changes

Semantic token değeri değişirken bütün component'lerin görünümü ciddi biçimde değişebilir. Bu teknik build'i bozmasa bile product açısından breaking olabilir. Rebranding buna örnektir. Preview environment stakeholder review sağlar. Staged rollout ve rollback planı büyük visual change riskini azaltır.

Migration Guide Oluşturmak

Guide eski ve yeni token isimlerini mapping tablosuyla açıklayabilir. Component örnekleri değişiklik etkisini gösterir. Codemod varsa kullanım adımları eklenir. Deprecated timeline belirtilir. Consumer ekip upgrade'i planlayabilir.

Kurumsal Kimlik Governance Modeli

Design system'ın kimin tarafından değiştirilebildiği ve yeni token'ın nasıl açıldığı açık değilse sistem zamanla tekrar dağılır. Tasarımcı, frontend ekibi ve design system ekibi farklı sorumluluklar taşır. Yeni token gerçek kullanım ihtiyacına dayanmalıdır. Büyük semantic değişiklik RFC veya ADR ile belgelenebilir. Governance hızlı olmalı ve küçük kararları gereksiz merkezi approval sürecine çevirmemelidir.

Design System'ın Sahibi Kim Olmalı?

Ownership yalnızca tasarım veya yalnızca frontend ekibinde kalmamalıdır. Cross-functional design system ekibi görsel dil, component implementation ve developer experience'i birlikte yönetebilir. Product domain ekipleri contributor olarak katılır. Executive sponsorship büyük kurumda adoption sorunlarını azaltabilir. Owner roadmap ve quality metrics'ten sorumlu olmalıdır.

Tasarımcıların Sorumluluğu

Tasarımcı token hierarchy ve component visual behavior'ını tanımlar. Accessibility ve interaction state'leri tasarım aşamasında düşünür. Figma variables ile token usage tutarlılığını korur. Değişiklik pull request veya design review sürecine bağlanır. Kod tarafında imkansız veya pahalı davranışlar için frontend ile erken işbirliği yapar.

Frontend Ekibinin Sorumluluğu

Frontend component implementation ve token mapping'in teknik kalitesinden sorumludur. Hard-coded value ve accessibility regression'ları önler. Build, package ve performance etkisini takip eder. Design token source ile generated CSS arasında automation kurar. Tasarım kararını sessizce değiştirip farklı local token üretmemelidir.

Design System Ekibinin Sorumluluğu

Design system ekibi token contract, component library ve documentation'ı bütün olarak yönetir. Contribution guideline yayınlar. Release ve deprecation politikasını yürütür. Storybook ve visual regression pipeline'ını korur. Adoption feedback'ine göre platformu geliştirir.

Yeni Token Açma Süreci

Yeni token isteği önce mevcut token'larla ihtiyaç karşılanabiliyor mu sorusuyla değerlendirilir. Tek seferlik değer için global token eklemek gerekmeyebilir. Tekrarlanan semantic ihtiyacın gerçek use case'leri gösterilir. Naming convention kontrol edilir. Kabul edilen token documentation ve test set'ine eklenir.

Token Değişikliği İçin RFC Süreci

Geniş etki oluşturan token değişikliği RFC ile tartışılabilir. Problem, alternatifler ve migration etkisi yazılır. Tasarım ve frontend ekipleri yorum yapar. Küçük value düzeltmeleri için RFC gerekmemelidir. Süreç risk seviyesine göre ölçeklenmelidir.

Architecture Decision Record Kullanımı

ADR theme architecture gibi uzun ömürlü teknik kararların gerekçesini kaydeder. Neden data-brand ve semantic custom property modeli seçildiği belgelenebilir. Gelecekte ekip aynı tartışmayı yeniden yapmak zorunda kalmaz. Karar değişirse yeni ADR eski kararı supersede eder. Belge kısa ve uygulanabilir tutulmalıdır.

Kurumsal Kimlik Kurallarını Kod Seviyesinde Zorunlu Hale Getirmek

Design system kurallarını yalnızca ekip dokümanına bırakmak büyük codebase'de yeterli olmaz. Hard-coded HEX, arbitrary spacing ve izinsiz shadow kullanımları lint ile tespit edilebilir. Code review insanın semantic doğruluğu değerlendirmesine odaklanır. CI yeni ihlalin main branch'e girmesini engeller. Kurallar geliştiriciye yalnızca hata değil doğru token alternatifini de göstermelidir.

Hard-Coded HEX Değerlerini Engellemek

Source scan CSS ve template içindeki HEX kullanımını tespit edebilir. Asset veya data visualization gibi izin verilen alanlar allowlist içinde tutulabilir. Hata mesajı uygun semantic token kullanımını önermelidir. Legacy code migration aşamasında warning moduyla başlanabilir. Yeni code için blocking rule uygulanabilir.

Arbitrary Tailwind Values Kullanımını Denetlemek

Arbitrary value tamamen yasaklanmak zorunda değildir. Ancak color, spacing ve radius gibi design system kapsamındaki alanlarda kontrol edilmelidir. Linter belirli pattern'leri raporlayabilir. Tekrarlanan değer yeni token ihtiyacına işaret eder. Grid calculation veya gerçek dynamic layout gibi meşru kullanım alanları documented exception olabilir.

İzin Verilmeyen Radius ve Shadow Değerlerini Engellemek

Marka zero-radius ise arbitrary rounded utility doğrudan ihlal oluşturur. Tailwind default namespace daraltılabilir veya linter kullanımını engelleyebilir. Shadow-free brand için component semantic elevation token kullanmalıdır. Shared application code brand-specific hard rule bilmiyorsa theme mapping value'yu none'a çevirebilir. Governance hem utility API hem visual test ile uygulanmalıdır.

Linting

Lint hızlı developer feedback sağlar. IDE veya pre-commit seviyesinde çalışırsa CI beklemeye gerek kalmaz. Rule package versionlanabilir. False positive düşük tutulmalıdır. Exception mekanizması gerekçeli ve görünür olmalıdır.

Code Review Rules

Reviewer semantic token seçiminin doğru olup olmadığını değerlendirir. Otomatik linter zaten syntax ve hard-coded value kontrollerini yapmalıdır. Review checklist accessibility ve component reuse sorularını içerebilir. Tasarımcı gerekli visual change'i preview üzerinden doğrular. İnsan review mekanik kontrol listesine dönüşmemelidir.

CI'da Token Kullanım Kontrolü

CI design system package dışındaki raw color kullanımını tarayabilir. Generated code ve third-party source exclude edilmelidir. New violations merge'i bloklayabilir. Legacy violation baseline ile kademeli azaltılabilir. Metric zaman içinde hard-coded value sayısının düşüşünü gösterebilir.

Storybook ile Çoklu Tema Testi

Storybook component'leri uygulama ekranından bağımsız test etmek için uygun ortam sağlar. Theme ve brand decorator root attribute'ları değiştirerek aynı story'yi farklı kombinasyonlarda render edebilir. Light-dark ve multi-brand matrix manuel kontrolü kolaylaştırır. Yeni marka eklendiğinde bütün temel component story'leri otomatik olarak aynı token set'iyle görüntülenebilir. Bu ortam visual regression ve accessibility testlerinin de temelini oluşturabilir.

Her Component'i İzole Test Etmek

İzole component test state ve token behavior'ını daha kolay gösterir. Button hover, disabled ve focus varyantları ayrı story olabilir. Uygulama data dependency'si minimum tutulur. Theme değişikliğinin hangi component'i bozduğu hızlı görülür. Design review gerçek component library üzerinde yapılabilir.

Theme Decorator Kullanmak

Theme decorator root element'e light veya dark attribute ekler. Story markup değişmeden mode switching yapılır. Control panel reviewer'ın hızlı karşılaştırma yapmasını sağlar. Decorator application theme resolver behavior'ına mümkün olduğunca yakın olmalıdır. Token CSS aynı production package'tan import edilmelidir.

Brand Decorator Kullanmak

Brand decorator aktif data-brand değerini değiştirir. Aynı story farklı marka palette, font ve radius değerleriyle görünür. Logo gerektiren component registry context'ini de decorator sağlayabilir. Yeni brand key config listesine eklenince story matrix genişleyebilir. Manual duplicate story yazma ihtiyacı azalır.

Light / Dark Matrix

Matrix aynı component'in iki mode'unu yan yana gösterebilir. Contrast ve surface farkı hızlı görülebilir. Visual regression her mode için ayrı baseline tutabilir. Interaction testleri her ikisinde de çalışmalıdır. Mode-specific asset ve shadow hataları daha kolay yakalanır.

Multi-Brand Matrix

Brand matrix her component'i bütün desteklenen markalarda render eder. Token contract eksikse bazı markada fallback veya kırık style görünür. Font ve logo mapping hataları hızlı fark edilir. Çok fazla brand olduğunda representative critical components seçilebilir. CI bütün matrix'i screenshot olarak test edebilir.

Yeni Bir Marka Eklendiğinde Otomatik Story Üretmek

Brand config registry test tooling tarafından okunabilir. Story runner aynı component set'ini her brand key ile otomatik render eder. Manual story copy gerekmez. Yeni marka gerekli token'ı eksik bırakmışsa test fail olur. Onboarding checklist otomatik hale gelir.

Visual Regression Testing

Token değişikliği tek satır CSS diff'i olsa bile yüzlerce component'i etkileyebilir. Bu nedenle visual regression design token pipeline'ın güçlü güvenlik ağlarından biridir. Screenshot test eski baseline ile yeni rendering'i karşılaştırır. Her brand ve theme kombinasyonu risk seviyesine göre test edilebilir. Baseline update sıradan otomatik işlem değil, review edilen tasarım kararı olmalıdır.

Token Değişiklikleri Neden Risklidir?

Semantic primary değişikliği birçok button, link ve navigation öğesini etkileyebilir. Radius token değişikliği bütün card ve form kontrollerini değiştirebilir. Code diff küçük olduğu için traditional unit test bu geniş etkiyi göstermez. Screenshot diff görsel kapsamı açık hale getirir. Token package pull request'inde affected component listesi de sunulabilir.

Playwright Screenshot Testleri

Playwright belirli viewport ve theme state'inde screenshot alabilir. Storybook veya gerçek preview route target olarak kullanılabilir. Font loading tamamlanmadan screenshot alınmamalıdır. Animation disabled veya deterministic hale getirilebilir. Baseline farklı operating system rendering farklarına karşı kontrollü environment'da üretilmelidir.

Cypress ile Görsel Testler

Cypress integration veya component test ortamında visual snapshot plugin'leriyle kullanılabilir. Theme switch interaction gerçek user flow içinde doğrulanabilir. Screenshot deterministic data gerektirir. Browser ve viewport standardı CI ile local arasında uyumlu olmalıdır. Görsel test functional assertion'ın yerine geçmez, onu tamamlar.

Chromatic ve Storybook

Storybook tabanlı hosted visual review araçları component diff'ini tasarımcılarla paylaşmayı kolaylaştırabilir. Pull request değişikliği visual preview'a bağlanır. Reviewer değişiklikleri accept veya reject edebilir. Vendor seçimi kurumun güvenlik ve maliyet ihtiyaçlarına göre yapılmalıdır. Open source veya self-hosted alternatifler de aynı testing prensibini uygulayabilir.

Her Brand × Theme Kombinasyonunu Test Etmek

Üç marka ve iki mode altı kombinasyon üretir. Kritik primitive'lerde bütün matrix test edilmelidir. Daha az kritik component'lerde risk bazlı sampling yapılabilir. Automated test generation brand registry'den kombinasyonları çıkarabilir. Kombinasyon sayısının artması theme layer separation'ın önemini daha da artırır.

Baseline Screenshot Yönetimi

Baseline'lar version control veya visual testing service içinde saklanabilir. Her intentional visual change ilgili baseline update'i gerektirir. Reviewer “update all” işlemini görmeden onaylamamalıdır. Font veya browser upgrade geniş diff oluşturabilir. Bu değişiklikler ayrı migration olarak yönetilmelidir.

Accessibility Testlerini Tema Pipeline'ına Eklemek

Tema değişiklikleri erişilebilirliği sessizce bozabilir ve özellikle color token update'leri yüksek risk taşır. Automated contrast, axe-core ve keyboard focus testleri theme pipeline'a eklenmelidir. prefers-contrast, forced colors ve reduced motion gibi kullanıcı tercihleri gerçek component'lerde kontrol edilmelidir. Her brand-dark kombinasyonu aynı accessibility standardını karşılamalıdır. Accessibility testinin yalnızca son QA aşamasında çalışması yerine token pull request'inde erken feedback vermesi daha etkilidir.

Otomatik Contrast Testleri

Known foreground-background token çiftleri CI'da programatik olarak kontrol edilebilir. Button primary ve on-primary gibi semantic pairs açık metadata taşıyabilir. User-defined tenant renkleri publish sırasında aynı rule'a girer. Automated test bütün gerçek UI context'lerini kapsamaz. Visual ve manual accessibility review kritik ekranlarda devam etmelidir.

axe-core

axe-core component veya page rendering üzerinde yaygın accessibility problemlerini otomatik tespit edebilir. Storybook test runner her theme kombinasyonunda aynı audit'i çalıştırabilir. Color contrast bazı durumlarda tool tarafından yakalanabilir. Dynamic state'ler için interaction sonrası test gerekebilir. Otomatik test bütün accessibility gereksinimlerinin tamamlandığı anlamına gelmez.

Keyboard Focus

Theme değişikliği focus ring'i görünmez hale getirebilir. Keyboard ile bütün interactive component'lere erişilebilmelidir. Focus order DOM semantics ile uyumlu olmalıdır. Brand accent focus token olarak kullanılıyorsa bütün surface'lerde contrast kontrol edilmelidir. Screenshot ve automated interaction test birlikte kullanılabilir.

focus-visible

focus-visible keyboard odak göstergesini uygun interaction bağlamında göstermeyi kolaylaştırır. Focus indicator tamamen kaldırılmamalıdır. Design system ortak focus ring utility veya component primitive sunabilir. Tokenized focus color marka ve mode'a göre değişebilir. Browser behavior hedef platformlarda test edilmelidir.

prefers-contrast

prefers-contrast daha yüksek veya farklı contrast tercih eden kullanıcılar için ek uyarlama sağlayabilir. Bütün ürünlerin zorunlu olarak özel contrast mode üretmesi gerekmeyebilir. Ancak design system token layer bu preference'ı gelecekte destekleyecek kadar açık tasarlanabilir. Critical border veya foreground değerleri preference altında güçlendirilebilir. Gerçek kullanıcı ihtiyacı ve browser desteği değerlendirilmelidir.

forced-colors

Forced colors modunda işletim sistemi kullanıcı renklerini override edebilir. Component'in sadece background image veya subtle shadow ile state anlatması sorun yaratabilir. Native controls ve semantic CSS mümkün olduğunca korunmalıdır. Gerekli yerlerde forced-color-adjust davranışı bilinçli kullanılmalıdır. Design system critical components'i Windows high contrast gibi ortamlarda test etmelidir.

prefers-reduced-motion

Reduced motion kullanıcı hareket hassasiyeti için önemli preference'dır. Theme transition sırasında bütün sayfayı animate etmek bu tercihe aykırı olabilir. Motion token values preference altında azaltılabilir. State change feedback tamamen kaybolmamalıdır. Automated screenshot test animation'ı deterministic hale getirirken accessibility behavior ayrı test edilmelidir.

Token Değişikliğinde Accessibility Regresyonu

Bir token update yalnızca görsel diff değil accessibility diff de oluşturabilir. Primary color değiştiğinde button, link ve focus ring etkilenir. CI ilgili semantic pair'leri yeniden test etmelidir. Failing contrast release'i durdurabilir. Design review yeni brand değerinin neden değiştirilmesi gerektiğini açıkça görür.

Kurumsal Tema Değişikliklerini CI/CD'de Doğrulamak

Theme değişikliği production'a çıkmadan önce token schema, design-code parity, contrast, visual regression ve component testlerinden geçebilir. Build kontrolü Tailwind mapping'in geçerli output ürettiğini doğrular. Preview environment stakeholder'ın bütün brand ve theme kombinasyonlarını görmesini sağlar. Bu pipeline token değişikliğini sıradan CSS editinden kontrollü ürün değişikliğine dönüştürür. Test süresi çok büyürse risk bazlı paralel çalışma ve affected component analizi kullanılabilir.

Token Schema Validation

Schema zorunlu token isimlerini ve value type'larını kontrol eder. Unknown veya typo token CI'da yakalanır. Brand package semantic contract'taki bütün required values'ı sağlamalıdır. Optional token'lar default fallback kullanabilir. Schema version migration sürecini destekler.

Design–Code Parity Check

Figma export ile repository token listesi karşılaştırılabilir. Missing veya farklı isimlendirilmiş token raporlanır. Generated source olduğu durumda file checksum kontrolü yapılabilir. Her visual difference parity problemi değildir ve platform-specific istisnalar metadata ile belirtilmelidir. Amaç iki sistemin sessizce birbirinden uzaklaşmasını önlemektir.

Contrast Check

CI known semantic foreground-background pair'lerini test eder. Yeni brand palette bütün mode kombinasyonlarında değerlendirilir. Error report hangi token çiftinin başarısız olduğunu açıkça gösterir. Otomatik öneri en yakın uygun renk değerini gösterebilir. Final brand kararı tasarımcı tarafından doğrulanmalıdır.

Visual Regression

Storybook screenshot'ları önceki baseline ile karşılaştırılır. Token change affected component'lerde beklenmeyen visual shift oluşturursa review gerekir. Font update geniş diff yaratabilir. Screenshot environment deterministic tutulmalıdır. Intentional diff approve edilmeden merge yapılmamalıdır.

Component Testleri

Button state, modal focus ve form validation gibi functional behavior token değişikliğinden bağımsız görünse de package update sırasında regresyon yaşayabilir. Component tests shared library stability'sini korur. Theme decorator farklı brand context'lerinde aynı test'i çalıştırabilir. Functional test screenshot testini tamamlar. Test fail reason hızlı anlaşılır olmalıdır.

Build Kontrolü

Generated CSS size ve compilation success kontrol edilmelidir. Yeni static theme kullanımı gereksiz token output'u artırmış olabilir. Duplicate CSS veya missing utility tespit edilebilir. Production minification test build'e dahil edilmelidir. Theme package bütün supported applications'da compatibility check çalıştırabilir.

Token Değişikliğinde Otomatik Preview Environment

Pull request yeni token package ile geçici preview deployment oluşturabilir. Tasarımcı gerçek page ve component'leri browser üzerinde inceler. Brand switcher bütün combinations'ı gösterir. Product stakeholder rebranding gibi geniş değişikliği release öncesinde onaylar. Preview access kurumsal security kurallarına göre korunmalıdır.

Tema Yönetiminin Frontend Performansına Etkisi

Tema mimarisi yalnızca görsel kalite değil CSS boyutu, font yükleme ve ilk paint performansını da etkiler. Her marka için ayrı build bazı deployment modellerinde faydalı olsa da white-label runtime switching için operasyon maliyeti oluşturabilir. CSS custom properties tek build ile değer değiştirmeyi sağlar. Gereksiz JavaScript theme logic'i azaltılmalı ve ilk paint öncesi mümkün olduğunca küçük initialization kullanılmalıdır. Cache dostu shared theme package sık kullanılan CSS'in tekrar indirilmesini önleyebilir.

Tek Build vs Marka Başına Ayrı Build

Tek build ortak utility ve component kodunu bütün markalarda paylaşır. Runtime switching ve tenant deployment daha kolay olur. Çok sayıda font veya asset aynı bundle'a eklenirse maliyet artabilir. Marka başına ayrı build sadece belirli asset veya feature izolasyonu gerekiyorsa anlamlı olabilir. Karar görsel theme farklılığından çok deployment ve product architecture'a göre verilmelidir.

CSS Custom Properties ile Runtime Switching

Custom property değişikliği yeniden stylesheet indirmeden theme values'ı değiştirir. Component class listesi aynı kalır. CSS cascade browser tarafından verimli şekilde uygulanır. Çok büyük DOM'da geniş variable update style recalculation oluşturabilir fakat normal theme switching için genellikle yönetilebilir bir maliyettir. Profiling gerçek uygulama üzerinde yapılmalıdır.

CSS Duplication'ı Önlemek

Her brand-theme çifti için component style'larını tekrar üretmek CSS boyutunu gereksiz büyütür. Semantic variable model ortak declaration'ı bir kez tutar. Brand files yalnızca variable values değiştirir. Utility class duplication azalır. Build analyzer final CSS'in hangi kısmının tekrar ettiğini gösterebilir.

Gereksiz Theme JavaScript'ini Azaltmak

Her component'te theme hook kullanmak re-render ve code complexity oluşturabilir. Renk ve spacing değişikliklerinin büyük bölümü CSS variable cascade ile çözülmelidir. JavaScript aktif brand, user preference ve asset resolution gibi gerçek state için kullanılabilir. Theme object'i bütün component tree'ye prop olarak dağıtmak gerekmeyebilir. Daha az JavaScript ilk yükleme ve bakım açısından avantaj sağlar.

İlk Paint Öncesinde Temayı Çözmek

FOUC önlemek için theme resolution kritik path'te olmalıdır. Server-rendered attribute en temiz çözümlerden biridir. Client-only durumda initialization script küçük tutulmalıdır. Büyük theme configuration fetch beklenirse default brand hızlı gösterilip customization sonra gelebilir, fakat white-label beklentisine göre bu kabul edilmeyebilir. Tenant config edge veya server cache ile request öncesi çözülebilir.

Cache Dostu Tema Mimarisi

Ortak base CSS uzun süre cache edilebilir. Tenant-specific küçük variable stylesheet ayrı cache key ile sunulabilir. Theme version URL veya response metadata'ya eklenebilir. Rebranding tüm application bundle cache'ini bozmak zorunda değildir. CDN ve browser caching strategy deployment modeline göre planlanmalıdır.

Kurumsal Rebranding Tailwind ile Nasıl Yönetilir?

Rebranding başarılı token mimarisinin en güçlü testlerinden biridir. İlk adım mevcut codebase'deki hard-coded renk, font, radius ve shadow değerlerini envanterlemektir. Sonra primitive ve semantic token katmanı oluşturulur. Component'ler semantic token'lara geçirildikten sonra yeni brand values merkezi biçimde eklenebilir. Eski ve yeni marka parallel preview ile test edilip controlled rollout yapılabilir.

Mevcut Hard-Coded Değerleri Envanterlemek

Source scan HEX, arbitrary color ve özel spacing kullanımını raporlayabilir. Figma tarafındaki styles ve variables da çıkarılmalıdır. Aynı renk farklı semantic amaçlarla kullanılıyor olabilir. Otomatik replace yapılmadan önce kullanım amacı sınıflandırılmalıdır. Inventory migration planının kapsamını gösterir.

Primitive Token'lara Taşımak

Tekrarlanan ham değerler palette ve spacing primitives altında toplanır. Token isimleri current brand value'yu çok fazla yansıtmamalıdır. Legacy class'lar geçici alias kullanabilir. Migration küçük component gruplarıyla yapılabilir. Token package ilk aşamada mevcut görünümü birebir korumayı hedefler.

Semantic Token Katmanını Oluşturmak

Primitive values background, surface, primary ve foreground gibi semantic rollerle eşleştirilir. Bu aşama rebranding öncesinde yapılırsa component'lerin gerçek anlamı ortaya çıkar. Tasarımcı mevcut UI'daki farklı kullanım bağlamlarını doğrular. Semantic kontrat light-dark mode'u da kapsar. Yeni brand sonrasında yalnızca mapping büyük ölçüde değişebilir.

Component'leri Semantic Token'lara Geçirmek

Button, Card ve Input gibi high-reuse component'lerden başlanabilir. Application-level raw utility kullanımları zaman içinde azaltılır. Visual regression mevcut brand görünümünün değişmediğini doğrular. Component props'taki brand-specific değerler kaldırılır. Migration completion lint metriğiyle takip edilebilir.

Yeni Marka Token'larını Eklemek

Yeni palette, typography, radius ve asset values brand theme package'e eklenir. Semantic contract aynı kalır. Eksik token schema testinde görünür. New brand Storybook matrix'e otomatik dahil edilir. Component code'a marka koşulu eklenmeden ilk preview alınır.

Eski ve Yeni Markayı Paralel Test Etmek

data-brand switching eski ve yeni markayı aynı build içinde karşılaştırmayı kolaylaştırır. Visual regression iki baseline set'i kullanabilir. Product stakeholder real pages üzerinde review yapar. Dark mode her iki brand için de test edilir. Logo, font ve motion gibi renk dışı değerler unutulmamalıdır.

Kontrollü Rollout

Rebranding feature flag veya tenant segment üzerinden aşamalı yayınlanabilir. İlk internal kullanıcı veya düşük riskli cohort yeni brand'i görür. Error ve performance metric takip edilir. Görsel issue hızlı rollback ile eski token set'ine döndürülebilir. Token version rollout state'iyle ilişkilendirilebilir.

Legacy Token'ları Deprecate Etmek

Yeni semantic model oturduktan sonra eski brand-specific token isimleri deprecated edilir. Linter yeni kullanımını engeller. Alias transition period boyunca build compatibility sağlayabilir. Usage sıfıra indiğinde major package release ile kaldırılır. Migration guide kalan consumer'lara yol gösterir.

Tailwind CSS v3'ten v4 Tema Sistemine Geçiş

v3'ten v4'e migration yalnızca syntax değiştirmek değil, mevcut theme architecture'ı yeniden değerlendirme fırsatıdır. JavaScript config içindeki colors, typography ve spacing değerleri envanterlenmelidir. CSS-first theme variables'a taşınabilecek alanlar belirlenir. Existing CSS custom properties semantic runtime layer olarak korunabilir veya sadeleştirilebilir. Dark mode, plugin ve custom utility behavior final compiled CSS karşılaştırmasıyla doğrulanmalıdır.

tailwind.config.js Envanteri

Config içindeki theme.extend, plugins ve custom values listelenmelidir. Hangi değerlerin gerçekten kullanıldığı source scan ile belirlenebilir. Deprecated veya duplicate token'lar migration sırasında temizlenebilir. Tailwind v4 JavaScript config'i backward compatibility amacıyla destekler fakat explicit @config gerekir. Bu sayede migration tek seferde yapılmak zorunda değildir. :contentReference[oaicite:25]{index=25}

Renklerin @theme Yapısına Taşınması

Primitive color scale --color-* namespace'ine aktarılabilir. Semantic runtime colors ayrı normal CSS variables olarak kalabilir. @theme inline utility-facing aliases için kullanılabilir. Default palette tamamen kaldırılacaksa namespace reset yaklaşımı değerlendirilebilir. Tailwind dokümantasyonu --color-*: initial ile default color namespace'inin değiştirilebildiğini gösterir. :contentReference[oaicite:26]{index=26}

Typography ve Spacing Taşıma

Font family ve size values ilgili theme namespaces'e dönüştürülebilir. Legacy spacing scale kullanım oranı analiz edilmelidir. Arbitrary values migration sonrasında cleanup backlog'u olabilir. Semantic typography styles custom utility veya component primitives'e taşınabilir. Final UI visual regression ile v3 baseline'a karşı test edilmelidir.

CSS Custom Properties'i Yeniden Değerlendirme

v3 döneminde Tailwind config'e değer taşımak için kullanılan bazı workaround custom property'ler artık gereksiz olabilir. Buna karşılık runtime brand ve dark mode için semantic CSS variables hâlâ güçlü çözümdür. Her variable'ın framework utility üretmesi gerekip gerekmediği değerlendirilmelidir. Normal runtime values :root, Tailwind-facing values @theme altında tutulabilir. Bu ayrım v4 architecture'ı sadeleştirir.

Dark Mode Davranışını Test Etme

Legacy darkMode config behavior'ı v4 custom variant modeline taşınabilir. Class veya data attribute selector yeniden tanımlanır. System preference ve stored user selection test edilir. FOUC davranışı migration sırasında değişebilir. Component screenshots light ve dark için karşılaştırılmalıdır.

Plugin ve Custom Utility Migration

Legacy plugin'lerin v4 compatibility durumu kontrol edilmelidir. @plugin eski JavaScript plugin'lerini yüklemek için kullanılabilir. Custom utilities CSS-first yaklaşımına taşınabilir. Unsupported config seçenekleri için yeni v4 yöntemleri kullanılmalıdır. Tailwind'in functions ve directives dokümantasyonu migration sırasında hangi legacy özelliklerin nasıl bağlandığını açıklar. :contentReference[oaicite:27]{index=27}

Derlenmiş CSS'i Karşılaştırma

Source config aynı görünse bile generated selector veya variable behavior değişebilir. Production CSS size ve utility output karşılaştırılmalıdır. Critical components screenshot testinden geçirilir. Browser computed styles alias resolution problemlerini gösterir. Migration ancak source code compile olduğu için tamamlanmış sayılmamalıdır.

Gerçek Dünya Örneği: Tek Codebase'den Üç Kurumsal Marka

Üç marka destekleyen ortak SaaS uygulaması düşünelim. Component library ve primitive token'lar ortaktır. Her marka semantic token mapping, logo ve font configuration sağlar. Light ve dark mode ikinci tema ekseni olarak uygulanır. Tenant request sırasında brand belirlenir ve tek build doğru theme'i runtime'da gösterir.

Ortak Component Library

Button, Input, Card ve navigation üç marka tarafından aynı package'tan kullanılır. Component'ler brand prop taşımaz. Semantic token ve asset resolver kullanırlar. Accessibility behavior bütün markalarda ortaktır. Release tek component version üzerinden yapılır.

Ortak Primitive Token'lar

Spacing, bazı neutral values ve typography scale markalar arasında paylaşılabilir. Brand color primitives ayrı olabilir. Base radius scale shared olup marka mapping'i farklı seviyeyi seçebilir. Ortak primitive sayısı zorla artırılmamalıdır. Gerçek brand farkı source token modelinde görünür kalmalıdır.

Marka A Semantic Token'ları

Marka A primary blue palette kullanabilir. Surface ve foreground ortak neutral system'den gelebilir. Radius medium ve shadow subtle seçilebilir. Logo registry A asset'lerini tanımlar. Aynı semantic token isimleri diğer markalarda da bulunur.

Marka B Semantic Token'ları

Marka B primary green ve farklı display font kullanabilir. Zero-radius gibi güçlü visual rule uygulayabilir. Button component değişmez. Brand B token package farklı values sunar. Storybook matrix farkı açık biçimde gösterir.

Marka C Semantic Token'ları

Marka C daha yüksek radius ve shadow scale kullanabilir. Primary foreground contrast farklı olabilir. Motion duration biraz daha kısa seçilebilir. Shared component semantic roles aynı kalır. Yeni marka onboarding'i component fork oluşturmadan tamamlanır.

Light ve Dark Tema

Her marka iki color scheme'i destekler. Background, surface ve foreground mode layer'da değişir. Brand primary yalnızca gerektiğinde mode-specific override alır. Altı kombinasyon visual regression testine girer. Theme switch user preference'ına göre runtime çalışır.

Tenant Bazlı Runtime Marka Seçimi

Tenant domain request sırasında internal brand key'e eşlenir. Server root data-brand attribute'ını üretir. Client aynı state'i hydrate eder. Brand switching normal son kullanıcıya sunulmayabilir. Admin preview ekranı üç markayı runtime değiştirebilir.

Logo ve Font Değişimi

Asset registry brand key üzerinden doğru logo ve favicon'u döndürür. Font CSS yalnızca aktif veya gerekli brand için optimize yüklenebilir. Fallback font metrics layout shift'i azaltacak şekilde seçilir. Dark logo variant mode state'ine göre çözülür. Component bu asset path'lerini hard-code etmez.

Tek Build ile Deployment

Utility ve component CSS tek build içinde paylaşılır. Brand farkı variable set'leri üzerinden uygulanır. Deployment pipeline tenant başına frontend build üretmez. Cache ortak bundle için daha verimli olur. Tenant configuration ayrı server data olarak güncellenebilir.

Otomatik Görsel Testler

CI üç brand ve iki mode için critical story screenshots üretir. Contrast test semantic pair'leri kontrol eder. Missing token schema validation'da fail olur. Logo ve font loading smoke test yapılabilir. Yeni component otomatik matrix'e dahil edilir.

Örnek Dosya ve Paket Mimarisi

Dosya yapısı primitive, semantic, component ve theme katmanlarını fiziksel olarak ayırarak ownership'i görünür hale getirebilir. Tek doğru directory yapısı yoktur, fakat import sırası ve generated-handwritten dosya ayrımı açık olmalıdır. Brand ve dark theme dosyaları semantic variable override'ları taşır. Utility mapping ayrı tutulabilir. Uygulama ana stylesheet'i bu katmanları belirli cascade sırasıyla birleştirir.

tokens/primitives/

Primitive directory ham color, typography, spacing ve effect değerlerini tutar. Bu dosyalar kullanım anlamı taşımaz. Generated token pipeline varsa elle düzenlenmeyebilir. Platform-specific mapping bu katmandan doğrudan consumer component'e gitmemelidir. Semantic layer primary kullanım yüzeyi olmalıdır.

colors.css

Color primitives palette değerlerini içerir. OKLCH veya başka standard format kullanılabilir. Brand-specific primitives ayrı file veya selector altında bulunabilir. Default Tailwind color namespace ile collision stratejisi belirlenir. Semantic colors bu primitive'lere referans verir.

typography.css

Typography primitives font families, sizes ve weights'i tanımlar. Font-face declarations ayrı asset layer'da tutulabilir. Variable font axis values burada yer alabilir. Semantic heading styles başka katmanda mapping yapar. Generated file ise elle override edilmemelidir.

spacing.css

Spacing scale temel ölçüleri içerir. Grid convention ile uyumlu değerler kullanılır. Semantic card ve section spacing bu values'a referans verir. Arbitrary values burada çoğaltılmamalıdır. Scale değişikliği geniş layout etkisi yaratacağı için visual review gerekir.

effects.css

Shadow, blur, easing ve duration gibi primitive effects burada gruplanabilir. Marka-specific motion veya shadow differences semantic layer'da seçilebilir. Effect values accessibility preference tarafından override edilebilir. Naming standard bütün platform output'larıyla uyumlu tutulmalıdır. Dosya yalnızca görsel değerleri içermeli ve component logic taşımamalıdır.

tokens/semantic/

Semantic directory component'lerin büyük ölçüde tükettiği kullanım odaklı token'ları içerir. Background, foreground, primary ve status values burada tanımlanır. Primitive references brand veya mode selector'larıyla değişebilir. Cross-platform naming bu katmanda en stabil olmalıdır. Breaking semantic change package versioning gerektirebilir.

colors.css

Semantic color file surface, foreground ve action roles tanımlar. Light default values burada veya base theme'de bulunabilir. Dark override ayrı theme file'da yer alır. Brand-specific mapping ayrı selector üzerinden çalışabilir. Component raw primitive yerine bu variables'ı kullanır.

typography.css

Semantic typography display, heading, body ve label styles için mapping sağlar. Font family ve weight brand tarafından değişebilir. Component bu semantic roles üzerinden tutarlı text hierarchy kullanır. Responsive formula burada veya custom utility seviyesinde tanımlanabilir. Tasarım ve code naming parity korunmalıdır.

spacing.css

Card padding, section gap ve form gap gibi semantic values burada bulunur. Product density mode gerektiğinde override edilebilir. Primitive scale'e referans verir. Component token gerekmedikçe bu seviye yeterli olabilir. Layout docs her token'ın kullanım bağlamını açıklar.

tokens/components/

Component token directory yalnızca gerçek component-specific farklılık gerektiğinde kullanılır. Button, Card veya Form gibi primitives burada semantic values'ı kendi role'lerine map eder. Küçük sistemlerde bu directory tamamen gereksiz olabilir. Büyük multi-brand library'de daha kontrollü override imkanı sunar. Token proliferation düzenli review edilmelidir.

button.css

Button primary background ve foreground mapping'i burada bulunabilir. Hover ve active states semantic interaction token'lara referans verir. Radius ve padding component role'ü olarak tanımlanabilir. Marka component file'ı fork etmez. Variant behavior component code ile token mapping arasında açık ayrım taşır.

card.css

Card surface, border ve elevation values component seviyesinde tanımlanabilir. Brand shadow-free ise token mapping theme override ile none olabilir. Card padding semantic spacing'e referans verir. Component CSS gerçek color value içermez. Visual tests bütün brand'lerde aynı component contract'ını doğrular.

form.css

Input border, focus ring ve helper text semantic tokens form layer'da birleştirilebilir. Error state danger palette'e bağlanır. Form density token burada bulunabilir. Accessibility behavior CSS token'dan bağımsız component semantics'inde korunur. Product-specific form styling global semantic system'i bozmamalıdır.

themes/

Theme directory brand ve color-scheme overrides'ını içerir. Bu dosyalar component selector yerine mümkün olduğunca custom property değerlerini değiştirir. Import sırası cascade dokümanında belirtilir. Tenant runtime config generated theme values ile bu katmana eklenebilir. Base semantic contract bütün theme dosyalarında korunmalıdır.

brand-a.css

Brand A semantic variables'ın gerçek marka değerlerini tanımlar. Palette, font ve asset metadata farklı kanalda tutulabilir. Sadece değişen values override edilir. Dark-specific intersection gerekiyorsa sınırlı selector kullanılabilir. Dosya uygulama business logic'i taşımaz.

brand-b.css

Brand B aynı semantic kontratı farklı values ile doldurur. Component class'ları değişmez. Zero-radius veya farklı motion behavior buradan uygulanabilir. Missing required token CI'da tespit edilir. Yeni brand file template üzerinden oluşturulabilir.

dark.css

Dark file color scheme'e göre background, surface ve foreground values değiştirir. Brand'den bağımsız ortak defaults sunar. Gereken birkaç brand-dark special case ayrı override olabilir. Native color-scheme property de burada ayarlanabilir. Component markup'a dark class eklemek gerekmeyebilir.

utilities/

Utilities directory framework-specific custom utility ve mapping'leri tutabilir. Tailwind @theme adapter burada bulunabilir. Semantic CSS variables Tailwind utility API'ye bağlanır. Application-specific style bu katmana eklenmemelidir. Custom utility naming design system namespace'iyle uyumlu olmalıdır.

app.css

App CSS Tailwind, token package ve application-specific stylesheet'leri belirli sırada import eder. Cascade layer strategy burada görünür hale gelir. Theme files runtime selectors üzerinden aktif olur. App-level overrides minimum tutulmalıdır. Build analyzer bu entry point'in final CSS boyutunu takip eder.

Tailwind ile Tema Yönetiminde Sık Yapılan Hatalar

Tema sisteminde en sık görülen sorunlar kısa vadeli kolaylıkların uzun vadede standartları delmesinden kaynaklanır. Hard-coded renkler, değer odaklı token isimleri ve component içine dağıtılmış dark variant'ları rebranding maliyetini artırır. Marka ile dark mode'u aynı state olarak modellemek kombinasyonları çoğaltır. Figma-code drift ve versionlanmayan token package değişikliklerin kontrolünü zorlaştırır. Güçlü tema mimarisi yalnızca yeni proje kurulurken değil, bu hataları önleyecek governance ve test sistemiyle birlikte düşünülmelidir.

Kurumsal Rengi Her Yerde Hard-Code Etmek

Aynı brand HEX yüzlerce class veya style içinde tekrarlandığında merkezi değişiklik mümkün olmaz. Bazı kullanımlar gerçek brand primary, bazıları decorative olabilir. Search-replace yanlış alanları değiştirebilir. Semantic primary token bu anlamı açık hale getirir. Linter yeni hard-coded renk eklenmesini önler.

Semantic Token Yerine blue-500 Gibi Değer Odaklı İsimler Kullanmak

Primitive isim component'in kullanım amacını açıklamaz. Rebranding primary rengini değiştirdiğinde blue-500 anlamsız hale gelir. Dark theme farklı neutral tone gerektirebilir. Component semantic primary veya surface kullanmalıdır. Primitive palette yalnızca token mapping katmanında kalabilir.

Her Component'e Ayrı Dark Mode Kuralı Yazmak

Yüzlerce dark: override renk mapping'ini markup'a dağıtır. Yeni theme eklemek daha da zorlaşır. Semantic token override centralizes mode behavior. Gerçek istisnalar yine dark variant kullanabilir. Default yaklaşım token-level theme olmalıdır.

Marka ile Dark Mode'u Aynı Kavram Olarak Modellemek

theme="brand-a-dark" gibi birleşik state ilk başta basit görünür. Marka sayısı arttıkça bütün color-scheme kombinasyonları ayrı tanımlanır. Brand ve mode bağımsız attribute'lara ayrıldığında tekrar azalır. Ortak layer values reuse edilir. Intersection yalnızca gerçekten gerekli olduğunda tanımlanır.

Her Marka İçin Ayrı Tailwind Build Oluşturmak

Sadece renk ve font values farklıysa ayrı build operasyon yükünü artırabilir. Tek utility set CSS variables üzerinden farklı marka values'ı kullanabilir. Ayrı build deployment, caching ve release coordination gerektirir. Gerçek feature veya asset isolation ihtiyacı varsa yine anlamlı olabilir. Karar token farkına göre değil product architecture'a göre verilmelidir.

Kullanıcı Tarafından Belirlenen Renklerde Kontrastı Kontrol Etmemek

Tenant çok açık primary seçtiğinde beyaz text okunamaz hale gelebilir. Publish pipeline contrast test yapmalıdır. Foreground otomatik hesaplanabilir. Geçersiz palette engellenebilir. Preview kullanıcıya sorunu release öncesinde gösterir.

Tema Değerlerini Client Mount Sonrasında Uygulamak

Theme component mount'tan sonra çözülürse yanlış ilk paint görünür. FOUC marka güvenini ve kullanıcı deneyimini olumsuz etkiler. Server-side attribute veya early initialization tercih edilmelidir. Hydration state uyumlu tutulmalıdır. System mode ayrı çözüm gerektirir.

Token Değişikliklerini Visual Regression Testine Sokmamak

Tek token update yüzlerce component'i etkileyebilir. Unit test bu görsel farkı yakalamaz. Storybook screenshot matrix geniş etkiyi gösterir. Intentional changes review edilir. Baseline update kontrollü yapılmalıdır.

Figma ve Kodda Farklı Token İsimleri Kullanmak

İki taraf aynı kavramı farklı adla tanımladığında handoff ve review maliyeti artar. Naming mapping documentation gerektirir. Mümkünse parity sağlanmalıdır. Automated comparison drift'i bulabilir. Ortak token glossary ekip iletişimini güçlendirir.

Arbitrary Values ile Design System'ı Delmek

Arbitrary values exception için kullanışlıdır fakat default çalışma şekline dönüşmemelidir. Her özel piksel değeri spacing ve radius sistemini zayıflatır. Linter design-sensitive property'lerde kontrol sağlayabilir. Tekrarlanan exception yeni token ihtiyacı olarak değerlendirilir. Gerçek layout hesapları için arbitrary syntax açık istisna olarak kalabilir.

Token'ları Versionlamamak

Theme package değişikliği bütün consumer'ları sessizce etkileyebilir. Version ve changelog değişiklik kapsamını görünür yapar. Breaking rename kontrollü migration alır. Application belirli version'a pin edilebilir. Rebranding staged rollout için eski ve yeni package versions parallel kullanılabilir.

Tema Sistemini Yalnızca Renklerden İbaret Sanmak

Marka kimliği typography, radius, shadow, motion ve asset kararlarını da içerir. Yalnızca color variable değiştirmek farklı markaların aynı görünmesine neden olabilir. Token hierarchy bütün tekrar eden visual decisions'i değerlendirmelidir. Her brand bütün token kategorilerini değiştirmek zorunda değildir. Sistem değişime açık contract sunmalıdır.

Kurumsal Tailwind Tema Mimarisi İçin Kontrol Listesi

Kontrol listesi theme system'in yalnızca çalışıp çalışmadığını değil, yeniden marka değişimine ve büyümeye hazır olup olmadığını değerlendirmelidir. Semantic naming ve component'lerden ham değerlerin temizlenmesi temel adımdır. Light-dark, multi-brand ve contrast automation ileri gereksinimleri güvenli hale getirir. Figma-code parity ile token versioning organization workflow'unu tamamlar. Rebranding hâlâ yüzlerce component değişikliği gerektiriyorsa theme architecture'da merkezi olmayan kararlar kalmış olabilir.

Token'lar Semantic Olarak İsimlendirilmiş mi?

Component consumer değer yerine kullanım anlamını görmelidir. Primary, surface ve foreground gibi isimler rebranding'e dayanıklıdır. Primitive palette isimleri token layer'da kalabilir. Naming convention belgelenmelidir. Ambiguous semantic isimler örneklerle açıklanmalıdır.

Ham Değerler Component'lerden Temizlenmiş mi?

HEX, arbitrary radius ve custom spacing kullanımları taranmalıdır. Shared component'ler yalnızca approved tokens kullanmalıdır. Legacy exception backlog halinde takip edilebilir. Linter yeni ihlal eklenmesini engeller. Migration visual regression ile yapılır.

Light ve Dark Tema Tanımlı mı?

Color scheme semantic token override üzerinden çalışabilir. System preference ve explicit user seçimleri desteklenebilir. Dark contrast ayrı test edilmelidir. Asset ve native form behavior unutulmamalıdır. İlk paint doğru theme ile gelmelidir.

Multi-Brand Gereksinimi Karşılanıyor mu?

Brand semantic contract ortak olmalıdır. Component brand prop taşımamalıdır. Logo ve font registry merkezi çözülmelidir. Tenant override allowlist ile sınırlanmalıdır. Yeni marka ekleme component fork gerektirmemelidir.

Kontrast Otomatik Kontrol Ediliyor mu?

Known token pair'leri CI'da test edilmelidir. User-defined colors publish pipeline'a dahil edilmelidir. Focus ve disabled state ayrıca değerlendirilmelidir. Automated check manual review'u tamamlar. Failing contrast release'i engelleyebilir.

Tema İlk Paint'ten Önce Belirleniyor mu?

Server-rendered attribute veya early script kullanılabilir. Client mount beklenmemelidir. System preference gerektiğinde matchMedia ile çözülür. Hydration mismatch test edilmelidir. FOUC performans ölçümünde gözlemlenebilir.

Figma ile Kod Aynı Token Kaynağını Kullanıyor mu?

Tek source veya deterministic synchronization bulunmalıdır. Naming parity korunmalıdır. Token export pull request üzerinden geçmelidir. Design change doğrudan production'a akmamalıdır. Drift automation düzenli çalışmalıdır.

Visual Regression Testleri Var mı?

Critical component'ler bütün brand ve mode kombinasyonlarında screenshot testine girmelidir. Baseline controlled environment'da tutulmalıdır. Intentional diff review edilmelidir. Font ve browser upgrade ayrı değişiklik olarak yapılmalıdır. Token PR preview link sunabilir.

Token Package Versionlanıyor mu?

Release version consumer etkisini görünür kılar. Deprecated token migration süresi alır. Major rename guide ile yayınlanır. Monorepo içinde bile changelog yararlıdır. Package adoption dashboard eski version kullanan uygulamaları gösterebilir.

Rebranding Tek Tek Component Değiştirmeden Yapılabiliyor mu?

İdeal sistemde yeni brand büyük ölçüde token ve asset config değişikliğidir. Component condition sayısı artıyorsa semantic abstraction eksik olabilir. Visual differences gerçek component exception gerektiriyorsa kontrollü layer kullanılabilir. New brand pilot Storybook matrix'te test edilir. Rebranding effort bu mimarinin en net kalite göstergelerinden biridir.

Tailwind CSS, Open Source ve Ekipler Arası İşbirliği

Tailwind'in açık kaynak ekosistemi theme, accessibility ve component uygulamalarında geniş deneyimden yararlanmayı kolaylaştırır. Bununla birlikte kurumsal design system değerini hazır component kopyalamaktan değil, ortak kuralları kurum ihtiyaçlarına göre yönetmekten alır. InnerSource modeli design token ve component library'ye farklı ekiplerin kontrollü katkı yapmasını sağlar. Pull request ve review değişikliğin nedenini görünür tutar. Yerel yazılım topluluklarında yapılan design system pratikleri de ekiplerin ortak vocabulary geliştirmesine katkıda bulunabilir.

Tailwind'in Açık Kaynak Ekosisteminden Yararlanmak

Resmi dokümantasyon ve community örnekleri yeni CSS özelliklerini öğrenmek için güçlü kaynaktır. Ancak her community pattern kurumsal ürüne doğrudan kopyalanmamalıdır. Accessibility, browser target ve maintenance durumu değerlendirilmelidir. Theme architecture mümkün olduğunca resmi Tailwind primitive'leri üzerine kurulmalıdır. Özel workaround sayısı framework upgrade maliyetini artırabilir.

Design System'ı InnerSource Olarak Yönetmek

InnerSource farklı ürün ekiplerinin merkezi design system repository'sine katkı yapmasını sağlar. Contribution guideline yeni token ve component taleplerinin nasıl ilerleyeceğini açıklar. Core maintainers kalite ve semantic tutarlılığı korur. Domain ekipleri gerçek kullanım ihtiyaçlarını doğrudan code ve design örnekleriyle sunar. Merkezi ekip bütün geliştirme işinin tek kaynağı haline gelmez.

Ortak Component Library'ye Katkı Süreci

Yeni component önce mevcut primitive'lerle çözülebiliyor mu değerlendirilir. API ve accessibility behavior tasarlanır. Storybook stories ve tests contribution'ın parçası olur. Token kullanımında hard-coded value kabul edilmez. Release note yeni component ve migration bilgisini paylaşır.

Token Değişikliklerinde Pull Request ve Review

Token diff code diff kadar önemli kabul edilmelidir. Tasarımcı visual intent'i, frontend developer teknik etkileri değerlendirir. CI contrast ve screenshots sunar. Breaking rename açıkça işaretlenir. Review history governance kaydı oluşturur.

Tasarımcı–Frontend Geliştirici İşbirliği

Tasarımcı ve developer yalnızca handoff anında buluşmamalıdır. Token naming ve component states birlikte tasarlanabilir. Technical limitation tasarımın erken aşamasında görünür olur. Developer implementation sırasında semantic karar değiştirmek yerine tasarımcıyla ortak çözüm üretir. Shared Storybook ve Figma vocabulary iletişim süresini azaltır.

Yerel Yazılım Topluluklarında Design System Pratikleri

Yerel topluluklarda küçük design token workshop'ları gerçek öğrenme fırsatı sunar. Aynı component farklı theme'lerle tasarlanıp kodlanabilir. Katılımcılar Figma, CSS variables ve Tailwind mapping ilişkisini birlikte deneyebilir. Open source örnek repository ortak contribution pratiği sağlar. Diyarbakır Yazılım Topluluğu'nun çalışmaları ve topluluk yapısı hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir.

Sık Sorulan Sorular

Tailwind CSS ile kurumsal tema yönetiminde en fazla soru v4 @theme modeli, dark mode, design token ve multi-brand mimari etrafında oluşur. Tek bir doğru dosya yapısı bulunmasa da semantic token, runtime CSS variable ve açık governance ilkeleri çoğu büyük projede güçlü temel oluşturur. Tailwind'in utility-first modeli kurumsal kimliği sınırlandırmaz ve doğru token sistemiyle oldukça farklı markalar aynı framework üzerinde çalışabilir. Tema mimarisi yalnızca frontend styling konusu değil, tasarım, accessibility ve release süreçlerini de etkileyen platform kararıdır. Aşağıdaki yanıtlar uygulamada en sık karşılaşılan soruları kısa fakat pratik çerçevede ele alır.

Tailwind CSS ile Tema Nasıl Oluşturulur?

Tailwind v4'te theme values @theme ile framework utility API'sine bağlanabilir. Runtime brand veya dark mode için normal CSS custom properties selector bazında override edilebilir. @theme inline semantic custom property'leri Tailwind-facing token'lara bağlamak için kullanılabilir. Component'ler semantic utility'leri kullanır. Theme switch root class veya data attribute üzerinden yapılabilir. :contentReference[oaicite:28]{index=28}

Tailwind CSS v4'te tailwind.config.js Gerekli mi?

Tailwind v4 CSS-first configuration yaklaşımını öne çıkarır ve birçok theme ayarı doğrudan CSS içinde yapılabilir. JavaScript config tamamen kaldırılmış değildir. Resmi upgrade dokümantasyonuna göre legacy JavaScript config dosyası hâlâ desteklenir ancak otomatik algılanmaz ve gerektiğinde @config ile yüklenir. Yeni projede yalnızca ihtiyaç varsa legacy config kullanılmalıdır. Migration kademeli şekilde ilerleyebilir. :contentReference[oaicite:29]{index=29}

@theme ile CSS Variable Arasındaki Fark Nedir?

@theme içindeki değişkenler Tailwind utility veya variant API'sini etkileyen özel theme variable'lardır. Normal CSS variable yalnızca browser runtime custom property davranışı sunar. Tailwind resmi dokümantasyonu utility üretmesi istenmeyen değerler için normal :root variables kullanımını önerir. Multi-brand modelde bu iki katman birlikte kullanılabilir. Semantic runtime value normal CSS variable, Tailwind utility alias ise theme variable olabilir. :contentReference[oaicite:30]{index=30}

@theme inline Ne Zaman Kullanılmalıdır?

Theme variable başka CSS custom property'ye referans veriyorsa inline yaklaşımı özellikle yararlıdır. Tailwind dokümantasyonu CSS variable resolution kapsamı nedeniyle bu durumda @theme inline kullanılmasını önerir. Multi-brand sistemde --color-primary utility token'ını runtime --brand-primary variable'ına bağlamak tipik örnektir. Component aynı utility'yi korur. Brand selector yalnızca runtime custom property'yi değiştirir. :contentReference[oaicite:31]{index=31}

Tailwind'de Dark Mode Nasıl Yönetilir?

Tailwind dark variant varsayılan olarak sistem color scheme tercihini kullanabilir. Manuel seçim için @custom-variant üzerinden class veya data-theme selector tanımlanabilir. Light, Dark ve System tercihi local storage veya server-side profile ile saklanabilir. Semantic token override component markup'ındaki dark class sayısını azaltır. İlk paint öncesinde active theme çözülerek FOUC önlenmelidir. :contentReference[oaicite:32]{index=32}

Her Element İçin dark: Yazmak Gerekir mi?

Hayır, semantic token modelinde çoğu component aynı utility'yi light ve dark modda kullanabilir. Root selector token values'ı değiştirir. bg-surface veya text-foreground mode'dan bağımsız kalır. dark: gerçek mode-specific asset veya davranış istisnası olduğunda kullanılabilir. Bu yaklaşım büyük component library'lerde bakım maliyetini azaltır.

Design Token Nedir?

Design token tekrar eden tasarım kararının isimlendirilmiş veri karşılığıdır. Renk, spacing, typography, radius, shadow ve motion değerleri token olabilir. Semantic token gerçek değerden çok kullanım anlamını temsil eder. Aynı source web ve native platform çıktısına dönüştürülebilir. Token sistemi tasarım ile kod arasında ortak kontrat oluşturur.

Primitive ve Semantic Token Arasındaki Fark Nedir?

Primitive token ham değeri temsil eder ve blue.600 gibi palette seviyesinde olabilir. Semantic token bu değerin kullanım anlamını ifade eder ve primary gibi isim taşır. Dark mode veya rebranding sırasında semantic token başka primitive'e bağlanabilir. Component mümkün olduğunca semantic token kullanır. Primitive layer tasarım değerlerinin temel kaynak havuzu olarak kalır.

Tailwind ile Birden Fazla Tema Kullanılabilir mi?

Evet, CSS custom properties ve selector-based override birden fazla theme'i runtime'da yönetmeyi mümkün hale getirir. data-theme veya başka data attribute kullanılabilir. Tailwind utility API semantic variables'a bağlanır. Her theme için ayrı component markup yazılmaz. Theme matrix automated testlerle doğrulanmalıdır.

Tek Tailwind Projesinde Birden Fazla Marka Yönetilebilir mi?

Evet, data-brand ve semantic token yaklaşımı tek build içinde çoklu marka çalıştırabilir. Her marka aynı token contract'a farklı values sağlar. Logo ve font gibi asset'ler registry üzerinden çözülür. Brand ile dark mode ayrı state olarak tutulur. Yeni marka eklemek component fork gerektirmemelidir.

White-Label SaaS İçin Tailwind Uygun mudur?

Tailwind semantic theme variable ve CSS custom property yaklaşımıyla white-label SaaS için güçlü temel sunabilir. Tenant primary color, font ve logo gibi sınırlı alanları özelleştirebilir. Runtime values database configuration'dan gelir. Security ve contrast validation publish aşamasında uygulanır. Tek build birçok tenant'a hizmet verebilir.

Tenant'ın Marka Rengi Runtime'da Değiştirilebilir mi?

Evet, marka rengi normal CSS custom property olarak runtime'da değiştirilebilir. Tailwind semantic utility bu variable'a bağlanabilir. JavaScript veya server root value'yu günceller. Renk input'u schema ve accessibility açısından doğrulanmalıdır. Page reload olmadan preview yapılabilir.

Figma Design Token'ları Tailwind ile Senkronize Edilebilir mi?

Evet, Figma variables veya token tooling üzerinden structured token export alınabilir. JSON Git repository'ye aktarılır. Transformation pipeline CSS custom properties üretir. Tailwind @theme mapping bu values'ı utility API'ye bağlar. Pull request ve CI değişikliği kontrollü hale getirir.

Tailwind ile Kurumsal Design System Oluşturulabilir mi?

Evet, fakat Tailwind design system'ın tamamı değildir. Token, component, accessibility, documentation ve governance süreçleri ayrıca gerekir. Tailwind utility-first API bu kararların implementation katmanını kolaylaştırır. Component library reusable semantic primitives sunar. Kurumsal değer standart ve süreçlerin birlikte uygulanmasıyla oluşur.

Tailwind Kullanmak Bütün Sitelerin Birbirine Benzemesine Neden Olur mu?

Hayır, Tailwind belirli görsel stili zorunlu kılmaz. Theme variables renk, font, radius, shadow ve spacing değerlerini değiştirebilir. İki marka aynı utility sınıflarını farklı token values ile tamamen farklı görsel karakterde kullanabilir. Benzerlik çoğu zaman framework'ten değil hazır default tasarım kararlarının değiştirilmemesinden kaynaklanır. Güçlü brand token sistemi özgün kurumsal kimliği korur.

Tailwind CSS Öğrenmek İçin Hangi Programlama Dilini Bilmek Gerekir?

Tailwind CSS öğrenmek için belirli bir programlama dili zorunlu değildir. HTML ve CSS temellerini anlamak en önemli başlangıçtır. JavaScript bilgisi runtime theme switching ve frontend framework integration için yararlı olur. Design token ve accessibility bilgisi kurumsal kullanım seviyesini yükseltir. Framework öğrenmeden önce CSS cascade ve responsive design mantığını anlamak uzun vadede daha değerlidir.

Yazılımcı Olmak İçin Tailwind ve Design System Konularını Ne Zaman Öğrenmeli?

Önce HTML, CSS box model, cascade ve responsive temelinin anlaşılması daha doğrudur. Tailwind bu temel kavramları daha hızlı uygulamak için kullanılır. İlk birkaç projeden sonra reusable component ve token mantığını öğrenmek çok faydalıdır. Büyük ekiplerde design system knowledge frontend yetkinliğinin önemli parçası haline gelir. Konu yalnızca class ezberlemek değil, sürdürülebilir UI kararları vermektir.

Open Source ve İşbirliği Design System Yetkinliğini Nasıl Geliştirir?

Open source project'lerde component API, accessibility ve theme kararlarını gerçek örnekler üzerinden görmek mümkündür. Pull request review farklı çözüm seçeneklerini öğretir. InnerSource model aynı pratiği kurum içine taşır. Ortak style guide contribution ekiplerin semantic vocabulary'sini geliştirir. Diyarbakır Yazılım Topluluğu'nun proje çalışmalarına göz atmak için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir.

Sonuç: Kurumsal Kimliği Component'lere Değil Token Sistemine Kodlayın

Kurumsal tema mimarisinin en önemli hedefi markayı yüzlerce component dosyasının içine dağıtmamaktır. Primitive, semantic ve gerektiğinde component token katmanları bu kararları merkezi hale getirir. Tailwind CSS v4'ün theme variables ve CSS-first yapısı semantic runtime variables ile birlikte kullanıldığında dark mode ve multi-brand senaryoları daha sade modellenebilir. Figma, token JSON, CI ve visual regression aynı lifecycle'a bağlandığında tasarım ile kod arasındaki fark azalır. Rebranding tek tek component refactor etmek yerine kontrollü token ve asset değişikliğine dönüştüğünde design system gerçek kurumsal değer üretmeye başlar.

Marka Kararlarını Merkezi Hale Getirin

Renk, font, spacing, radius, shadow ve motion kararlarını ortak source altında toplayın. Component geliştiricisinin kendi marka değerini üretmesini engelleyin. Brand package bütün uygulamalar için aynı semantic kontratı sunsun. Değişiklik pull request ve visual preview üzerinden ilerlesin. Merkezi karar tek bir ekibin kapalı kontrolü değil, versionlanan ve katkıya açık design system anlamına gelmelidir.

Primitive ve Semantic Token'ları Ayırın

Ham palette ile kullanım anlamını aynı seviyede tutmayın. Primitive token gerçek değeri, semantic token rolü ifade etsin. Component'ler mümkün olduğunca semantic layer kullansın. Dark mode ve rebranding yalnızca mapping değiştirerek uygulanabilsin. Bu separation theme architecture'ın uzun vadeli esnekliğini önemli ölçüde artırır.

Component'leri Marka Değerlerinden Bağımsızlaştırın

Button içinde marka adı veya HEX bulunmamalıdır. Component semantic variant ve state bilgisiyle çalışmalıdır. Brand CSS cascade ve token mapping tarafından çözülmelidir. Asset ihtiyacı merkezi registry üzerinden karşılanmalıdır. Bu yaklaşım aynı component library'nin birçok ürün ve markada tekrar kullanılmasını sağlar.

Light, Dark ve Multi-Brand Temaları Aynı Mimari Üzerinde Çalıştırın

Brand ve color scheme'i ayrı tema boyutları olarak modelleyin. data-brand ve data-theme gibi açık state değerleri kullanın. Semantic custom property override component markup'ını sade tutar. Gerçek intersection yalnızca gerekli token'larda eklenir. Automated matrix test bütün kombinasyonların güvenilir kalmasını sağlar.

Figma ile Kodu Aynı Kaynağa Bağlayın

Token isimlerinin tasarım ve kod tarafında aynı kavramsal modeli kullanmasını sağlayın. Export ve transformation pipeline manual copy-paste ihtiyacını azaltır. Pull request değişiklik etkisini görünür hale getirir. Schema ve parity check drift'i erkenden bulur. Tasarım değişikliği production deployment kadar kontrollü lifecycle kazanır.

Tema Değişikliklerini Otomatik Test Edin

Contrast, schema, visual regression ve component testlerini token pipeline'a ekleyin. Bir renk değişikliğinin onlarca component'i etkileyebileceğini varsayın. Light-dark ve bütün markalar risk seviyesine göre test edilsin. Preview environment insan review'unu desteklesin. Otomasyon tasarımcı ve geliştiricinin zamanını mekanik kontroller yerine gerçek ürün kararlarına ayırmasını sağlar.

Rebranding'i Frontend Refactor'ı Olmaktan Çıkarın

İyi theme architecture'da rebranding yeni token değerleri, asset'ler ve sınırlı semantic mapping değişikliklerinden oluşmalıdır. Eğer her Button, Card ve form ekranı tek tek değiştirilmek zorundaysa marka kararları component katmanına fazla dağılmış demektir. Önce mevcut hard-coded değerleri semantic token sistemine taşıyın ve ardından yeni marka üzerinde visual regression çalıştırın. Kurumsal frontend mimarisi, Tailwind CSS tema yönetimi ve design system yaklaşımı üzerine toplulukla iletişim kurmak için https://www.diyarbakiryazilim.com.tr adresini kullanabilirsiniz. Amaç yalnızca yeni renkleri hızlı yayınlamak değil, sonraki dark mode, yeni marka ve yeniden tasarım kararlarını daha düşük maliyetle yönetebilen kalıcı bir sistem kurmaktır.