TAILWIND CSS DESIGN SYSTEM KURGULAMAK

Vimaj11 dk okuma
Teal Tailwind CSS dalga logosu ile renkli design token grid renk paleti tipografi ölçeği ve boşluk birimleri kategorilerinde 3x3 hücre düzeni

Tailwind CSS bu sorunu çözmek için ideal araçtır ama tek başına değil. Tailwind utility-first sınıflarıyla hızlı üretim sağlar; design system mantığı ise hangi sınıfların kullanılacağı, hangi renklerin kabul edileceği, hangi bileşenlerin tekrar üretilmeyeceği kararını verir. İkisi birleştiğinde ölçeklenebilir bir arayüz mimarisi çıkar.

1. Design system nedir?

Design system; bir ürünün tüm tasarım kararlarını ortak bir dilde toplayan kurallar bütünüdür. Renk paleti, tipografi ölçeği, boşluk birimleri, bileşen kütüphanesi, animasyon tercihleri ve marka tonu bu sistemin parçalarıdır. Atomic Design diliyle "atom" (renk, font), "molekül" (buton, input), "organizma" (kart, navbar) seviyelerinde organize edilir.

Dokümantasyondan çok uygulanabilirlik

Önemli olan dokümantasyondan ziyade uygulanabilirliktir. Bir tasarımcı Figma'da bir renk seçtiğinde, bir geliştirici bunu kodda yazarken aynı isimle çağırıyorsa sistem işler.

2. Tailwind'in design system için neden iyi?

  • Konfigürasyon merkezli: tailwind.config.js dosyası tüm tasarım tercihlerinin tek kaynağı olur
  • Tutarlı utility'ler: "p-4" yazan herkes 16 piksel padding alır; ekipte yorum farkı kalmaz
  • JIT (Just-In-Time) compiler: Sadece kullanılan sınıflar derlemeye alınır; bundle boyutu küçük
  • Plugin desteği: @tailwindcss/typography, forms gibi resmi pluginler hazır kalıp sağlar
  • Geniş ekosistem: Headless UI, Radix, Heroicons gibi açık kaynak bileşen kütüphaneleri Tailwind ile uyumlu

3. tailwind.config.js: design system'in kalbi

Tailwind kurulumunun ardından tailwind.config.js dosyası proje köküne gelir. Bu dosya tüm tasarım kararlarınızın tek kaynağıdır.

// tailwind.config.js
module.exports = {
  content: ["./src/**/*.{html,js,vue,jsx,tsx}"],
  theme: {
    extend: {
      colors: {
        brand: {
          50: "#f0f9ff",
          100: "#e0f2fe",
          500: "#0ea5e9",
          700: "#0369a1",
          900: "#0c4a6e"
        },
        accent: "#facc15"
      },
      fontFamily: {
        sans: ["Inter", "sans-serif"],
        serif: ["Merriweather", "serif"]
      },
      spacing: {
        "18": "4.5rem",
        "128": "32rem"
      },
      borderRadius: {
        "card": "12px",
        "button": "8px"
      }
    }
  }
};

Bu dosyaya bir renk veya boşluk eklediğinizde tüm projede kullanılabilir hale gelir; theme genişletme alanlarının tamamı resmi dokümantasyonda listelenir. Yeni bir geliştirici geldiğinde tek bu dosyaya bakarak markanın tasarım kararlarını öğrenir.

4. Renk paleti tasarımı

İyi bir Tailwind palette beş prensibe uyar:

  1. Anlamlı isim: "blue" değil "brand" veya "primary" kullanılır; çünkü marka rengi değişebilir
  2. 9-11 tonluk skala: 50, 100, 200, 300, 400, 500, 600, 700, 800, 900 (Tailwind'in standardı)
  3. Yarı-açık ve yarı-koyu hep dengeli: 100 ve 900 simetrik açıklık-koyulukta
  4. Semantik renkler ayrı: success, warning, danger, info bağımsız tanımlanır
  5. Kontrast WCAG AA: Metin/arka plan kontrast oranı en az 4.5:1

Örnek semantik renk sistemi

colors: {
  primary: { 50: "...", 500: "#3b82f6", 900: "..." },
  neutral: { 50: "#fafafa", 500: "#737373", 900: "#171717" },
  success: { 500: "#10b981" },
  warning: { 500: "#f59e0b" },
  danger:  { 500: "#ef4444" },
  info:    { 500: "#3b82f6" }
}

5. Tipografi ölçeği

Tutarlı tipografi için ölçek tanımlanır. Tailwind varsayılan ölçeği (text-xs, sm, base, lg, xl, 2xl...) çoğu proje için yeterli ama özelleştirmek isteyenler için fontSize override edilir.

fontSize: {
  "display": ["3.5rem", { lineHeight: "1.1", letterSpacing: "-0.02em" }],
  "h1": ["2.5rem", "1.15"],
  "h2": ["2rem", "1.2"],
  "h3": ["1.5rem", "1.3"],
  "body": ["1rem", "1.6"],
  "caption": ["0.875rem", "1.4"]
}

Önemli: tipografi sınıfları semantik isimle (h1, body) tanımlandığında ekip aynı dili konuşur. "text-2xl" denmez, "text-h2" denir; bu değişimi tasarımcıdan geliştiriciye aynen aktarır.

Atomic design hiyerarşi diyagramı atom molekül ve organizma seviyelerinde Tailwind token renk font buton input ve kart bileşeni ile katmanlı gösterim

6. Boşluk sistemi

Tailwind varsayılan olarak 4px tabanlı bir boşluk ölçeği kullanır (1 = 4px, 2 = 8px, 4 = 16px, 8 = 32px...). Bu mantığı korumak design system için kritiktir; çünkü ekipler aynı birime hizalandığında dikey ritim doğal kalır.

8px tabanlı sistem

Bazı projeler 8px tabanlı sistem ister (Material Design etkisi); bu durumda tüm boşluklar 8'in katı olur. Tailwind config'de spacing override edilebilir.

7. Bileşen kütüphanesi

Tailwind sadece utility class verir; bileşen kütüphanesi yapısı ekibin sorumluluğundadır. İki yaklaşım yaygındır.

1. Component dosyası ile

React, Vue, Svelte gibi framework'lerde her bileşen kendi dosyasında durur. Buton dosyası:

// Button.tsx
type ButtonProps = {
  variant?: "primary" | "secondary" | "danger";
  size?: "sm" | "md" | "lg";
  children: React.ReactNode;
};

export const Button = ({ variant = "primary", size = "md", children }: ButtonProps) => {
  const variants = {
    primary: "bg-brand-500 text-white hover:bg-brand-600",
    secondary: "bg-neutral-200 text-neutral-900 hover:bg-neutral-300",
    danger: "bg-danger-500 text-white hover:bg-danger-600"
  };
  const sizes = {
    sm: "px-3 py-1.5 text-sm",
    md: "px-4 py-2 text-base",
    lg: "px-6 py-3 text-lg"
  };

  return (
    <button className={`rounded-button ${variants[variant]} ${sizes[size]}`}>
      {children}
    </button>
  );
};

2. @apply ile özel sınıflar

Saf HTML/CSS projelerinde Tailwind'in @apply direktifi kullanılır:

/* styles.css */
.btn-primary {
  @apply px-4 py-2 bg-brand-500 text-white rounded-button hover:bg-brand-600;
}
.btn-secondary {
  @apply px-4 py-2 bg-neutral-200 text-neutral-900 rounded-button hover:bg-neutral-300;
}

Hangi yaklaşım seçilirse seçilsin, prensip aynı: HTML'in içinde 30 sınıf yığını olmaz; bileşen adı çağırılır.

8. Storybook ile dokümantasyon

Bileşenleri tek tek ve farklı varyantlarda görsel olarak göstermek için Storybook kullanılır. Her bileşenin "story" dosyası yazılır; ekipteki herkes bileşen kütüphanesini canlı olarak gezebilir.

Avantajları:

  • Tasarımcı ve geliştirici aynı dili konuşur
  • Yeni bileşen önce Storybook'ta dener; sonra uygulamaya entegre eder
  • Görsel regresyon testleri (Chromatic gibi) ile değişiklikler otomatik yakalanır
  • Bileşenler "uygulamadan bağımsız" geliştirilir; yeniden kullanım artar

9. Plugin'ler ile genişletme

Tailwind resmi pluginleri standart kalıpları hazır verir:

  • @tailwindcss/typography: Blog/makale içeriği için "prose" sınıfı. Otomatik tipografi düzeni
  • @tailwindcss/forms: Tarayıcı varsayılan form elemanlarını sıfırlar; tutarlı bir başlangıç noktası verir
  • @tailwindcss/aspect-ratio: Görsel oranlarını korumak için (16:9, 4:3 gibi)
  • @tailwindcss/container-queries: Container size'a göre responsive davranış

10. Headless UI ve bileşen kütüphaneleri

Tailwind'in arkasındaki ekip Headless UI adında bir bileşen kütüphanesi sağlar. Modal, dropdown, tabs, combobox gibi etkileşim odaklı bileşenler hazır gelir; sadece styling'i siz yaparsınız. Erişilebilirlik (a11y) standartlarını otomatik karşılar.

Alternatifler

Alternatifler: Radix UI, Ariakit, React Aria. Hepsi "headless" yaklaşım kullanır.

11. Ekip için kurallar

Design system uygulanabilir olması için ekip içi kurallar gerekir:

  1. Yeni renk eklemeden önce config'i kontrol et. Var olan paletten uygun ton seçilebilir mi?
  2. Inline custom değer kullanma. "p-[17px]" yazma; gerekiyorsa spacing scale'e ekle
  3. Yeni bileşen önce design ekibine sor. Var olan kalıpla çözülüp çözülmediğine bakın
  4. Component dosyasını güncelle. Sayfaya doğrudan utility yığını yazma; ekip içi paylaşılan bileşen olsun
  5. Storybook'u güncel tut. Yeni varyant eklediğinde story dosyasına da ekle
VS Code dark theme tailwind.config.js editör görünümünde theme extend colors fontFamily spacing ve borderRadius kategorileri syntax highlight sözdizimi

12. Versiyonlama ve dağıtım

Büyük şirketlerde design system kendi paketi olur. Bir monorepo'da @brand/design-tokens, @brand/components gibi paketler tanımlanır; tüm ürünler bu paketleri kullanır. Tek bir değişiklik (örneğin marka renginin tonunu değiştirmek) tek bir merge ile tüm ürünlere yayılır.

13. Sürdürülebilir tutmak

Design system zamanla "ölü dokümantasyon"a dönüşebilir. Bunu önlemek için:

  • Üç ayda bir gözden geçir; kullanılmayan token'ları kaldır
  • Yeni gelen ekip üyesini sistemle tanıştır (onboarding parçası)
  • Tasarım ve geliştirme arasındaki "system karar toplantısı"nı aylık yap
  • İhlal eden kodları PR sürecinde yakala (lint kuralları)

14. Tekrar ve Sürdürme

Tailwind ve design system pratiği birlikte öğrenildiğinde modern frontend kariyerinin önemli bir parçasını oluşturur. Konuyu profesyonel düzeyde işlemek için Tailwind CSS eğitimi programları utility-first yaklaşımı uygulamalı şekilde aktarır.

15. Çıkarımlar

Tailwind CSS, design system kurmak için en uygun front-end araçlarından biridir; ama tek başına yetmez. Renk paleti, tipografi ölçeği, boşluk sistemi ve bileşen kütüphanesi tailwind.config.js'de toplanır; Storybook ile görselleştirilir; ekip içi kurallar ile sürdürülür. Doğru kurulmuş bir Tailwind tabanlı design system, ekip büyüdükçe arayüz tutarlılığını korur ve yeni özellikler eklemeyi hızlandırır. Yanlış kurulduğunda ise Tailwind'in utility class özelliği avantajdan çok kafa karışıklığına dönüşür; kurallı yapı bu nedenle kritiktir.

Sıkça Sorulan Sorular

Tailwind ile design system kurmak Bootstrap'tan ne kadar farklı?

Bootstrap hazır bileşen kütüphanesidir; <strong>design system</strong>'i kendi varsayımlarıyla gelir, özelleştirmek ek iş ister. Tailwind ise utility class verir; design system'i sıfırdan tasarlama özgürlüğü tanır. Bootstrap hızlı prototip için iyi; Tailwind uzun vadede özgün marka kimliği için. Farklı projeler için farklı doğru cevap olabilir.

Design system kurmak küçük projeler için zorunlu mu?

Hayır, küçük projelerde (5-10 sayfa) overkill olur. <strong>Design system</strong> 'aynı bileşen 10+ yerde tekrarlanıyor' veya 'ekip 3+ kişi' olduğunda anlamlı hale gelir. Tek kişilik küçük site için Tailwind'in varsayılan ayarları yeterlidir; özelleştirme ihtiyaca göre eklenir. Aşırı sistemleştirme erken aşamada hızı yavaşlatır.

Storybook gerçekten gerekli mi?

Orta ve büyük ölçekli projelerde evet. 5 kişiden fazla ekip varsa, tasarımcı-geliştirici işbirliği aktifse veya bileşen kütüphanesi 20'den fazla bileşen içeriyorsa Storybook kurmak iş akışını ciddi şekilde hızlandırır. Küçük tek geliştiricili projelerde Storybook için harcanan zaman uygulamaya geri dönmez; doğrudan uygulama içinde geliştirme daha pratiktir.

Headless UI mı Radix mı daha iyi?

İkisi de aynı problemi (erişilebilir, stilsiz bileşen) çözer ama yaklaşımları farklıdır. <strong>Headless UI</strong> Tailwind ekibinden gelir; React ve Vue desteği var. Radix UI daha kapsamlı ve daha fazla bileşeni var (slider, tooltip, hover card vb.); React odaklı. Yeni başlayanlar için Headless UI yeterli; karmaşık etkileşim ihtiyaçları için Radix tercih edilir. İkisini bir arada kullanmak mümkündür.

@apply kullanmak best practice mi yoksa anti-pattern mi?

İhtilaflı bir konu. Tailwind'in kendi belgeleri @apply'ı 'gerektiğinde kullan' diyor ama abartmamayı öneriyor. Doğru kullanım: tekrar eden 5+ kullanım için bileşen sınıfı oluşturmak. Yanlış kullanım: HTML'i temiz tutmak için her elemana @apply ile yeni sınıf eklemek (utility-first amacına aykırı). Genel kural: önce framework component'i (React, Vue), olmazsa @apply, son çare inline utility yığını.

Tailwind config'i nasıl ekip içinde yönetilir?

Üç ana yöntem var. Birincisi: monorepo içinde paylaşılan paket (örn. @brand/tailwind-config) tüm projeler import eder. İkincisi: design tokens'ı JSON'da tutmak; sistem Figma tokens ile entegre çalışır. Üçüncüsü: tailwind.config.js'yi git'te tutup pull request süreciyle değiştirmek. Hangi yöntem seçilirse seçilsin, 'tek kişi config'i istediği gibi değiştirir' yaklaşımı yasaklanmalıdır.

Mevcut bir projeyi Tailwind'e geçirmek mantıklı mı?

Bağlıdır. Küçük projeler (5-20 sayfa) iki haftada geçirilir. Büyük projeler (100+ sayfa) ay sürer ve sayfa sayfa kademeli geçiş tercih edilir. Eğer mevcut CSS dağınık ve tutarsız ise geçiş yatırım değerinde; eğer mevcut sistem sağlam ve ekip mutluysa geçiş zorla olur. Karar verirken sadece teknik değil ekip alışkanlığı da hesaba katılmalıdır.

 Vimaj