1. Design system nedir ve otel projelerinde neden önemli?
Design system; yalnız UI kit değil, aynı zamanda prensipler, token’lar, bileşen kuralları ve kullanım pattern’leri bütünüdür. Otelde bunu önemli yapan iki şey var:
- Rezervasyon akışı tekrar eder: oda kartı, paket seçimi, form, ödeme…
- Çok dilli + çok cihazlı yapı: TR–EN–DE–RU metin uzunluğu, para birimi, mobil davranışlar.
Design system olmadığında, aynı sorunlar her sprintte geri gelir: “Bu kart neden farklı?”, “Bu sayfada spacing neden değişik?”, “Almanca metin taşınca ne yapacağız?”
UI kit’in rezervasyon UX’ine etkisi
UI kit, rezervasyon funnel’ındaki sürtünmeyi azaltır: her ekranda CTA aynı görünür, form hataları aynı şekilde yönetilir, iptal/koşul metinleri aynı blokta taşınır. Bu tutarlılık, güven algısını yükseltir ve test/optimizasyonu kolaylaştırır.
☑ Mini Check
- •Aynı CTA farklı sayfalarda farklı görünüyor mu?
- •Form error state’leri standardize mi?
- •Oda kartları her yerde aynı bilgi hiyerarşisine sahip mi?
- •Çok dilli metin taşmalarına plan var mı?
Ne yapmalıyım?
- • Design system’i “tasarım dosyası” değil “ürün standardı” gibi sahiplenin.
- • Rezervasyon akışındaki tekrar eden bileşenleri önce standardize edin.
- • Çok dilli ve mobil senaryoyu baştan sisteme dahil edin.
2. Otel projeleri için design system nasıl kurulur?
AEO checklist (5–7 madde, net)
- Tasarım prensiplerini yazın: “netlik, hız, güven, tutarlılık” gibi 4–6 madde.
- Design token setini oluşturun: renk, tipografi, spacing, radius, shadow, z-index.
- Çekirdek bileşenleri tanımlayın: button, input, select, card, modal, badge, tooltip.
- Component + variant yapısını kurun: state (default/hover/focus/error/disabled/loading) zorunlu.
- Pattern’leri yazın: hero, oda listesi, fiyat/paket seçimi, form/checkout, CTA bar.
- Çok dilli ve cihaz kırılımlarını test edin: TR–EN–DE–RU metin taşması + mobil davranış.
- Figma→Next.js handoff sözlüğünü sabitleyin: isimlendirme, token map, kabul kriterleri.
☑ Mini Check
- •Token’lar yazılı mı yoksa “göz kararı” mı?
- •Bileşenlerin state seti eksiksiz mi?
- •Çok dilli metin testleri yapıldı mı?
- •Dev sözlüğü ve handoff kuralları var mı?
Ne yapmalıyım?
- • Token’ları oluşturup kilitleyin; UI kit ondan sonra gelir.
- • “State’leri olmayan bileşen yayınlanmaz” kuralı koyun.
- • Handoff öncesi 3 ekranlık pilot yapın: oda listesi + oda detayı + form.
3. Bileşen, pattern ve tasarım token’ları (otel için çekirdek set)
Otel projelerinde bileşenler iki gruba ayrılır: genel UI bileşenleri ve otel/rezervasyon özel bileşenleri. İkisini aynı kütüphanede, farklı kategorilerde tutmak işleri hızlandırır.
Çekirdek bileşenler (her projede)
- •Button (primary/secondary/ghost)
- •Input / Select / Date picker (takvim)
- •Card
- •Modal/Drawer
- •Tabs/Accordion
- •Toast/Alert
Otel özel bileşenler (rezervasyon odaklı)
- •RoomCard (oda kartı)
- •PriceBlock (toplam fiyat + vergi notu)
- •CancellationBadge (iptal özeti)
- •BoardTag (AI/UAI/HB)
- •TrustRow (puan/yorum/ödül)
- •StickyCTA (mobil rezervasyon bar)
Design token tablosu (örnek yapı)
Aşağıdaki token mantığı, Figma ve Next.js arasında köprü kurar: dev ekibi “renk adı” değil “token” görür.
| Token | Açıklama | Örnek kullanım |
|---|---|---|
| color.brand.primary | Marka ana renk | Primary CTA |
| type.scale.body | Gövde metni | Oda açıklaması |
| space.8 | 8px boşluk | Kart iç padding |
| radius.lg | Büyük radius | Kart/CTA |
| shadow.sm | Hafif gölge | Kart ayrımı |
☑ Mini Check (Token/Bileşen)
- •Token adları anlaşılır ve map’lenebilir mi?
- •RoomCard, PriceBlock gibi otel özel bileşenler var mı?
- •Date picker erişilebilirlik ve state setiyle hazır mı?
- •“BoardTag” metin taşmalarına dayanıklı mı (DE/RU)?
Ne yapmalıyım?
- • Otel özel bileşenleri ayrı kategoriye koyun; tekrar tekrar tasarlamayın.
- • Token tablosunu dev ekibiyle birlikte onaylayın.
- • Rezervasyon akışı bileşenlerini “pattern” olarak dokümante edin.
4. Otel UI Kit Figma Şablonunu İndir — Design System Starter
Otel UI Kit Figma Şablonunu İndir — Design System Starter (v1.0)
Bu Figma şablonu, otel web projelerinde çekirdek UI kit’i (button, form, card, modal, badge) ve otel özel bileşenleri (RoomCard, PriceBlock, CancellationBadge, BoardTag, StickyCTA) hızlıca kurmanız için hazırlanmıştır. Token tablosu ve component/variant setiyle tutarlı tasarım üretmeyi ve Next.js handoff’ı hızlandırmayı hedefler.
Kim Kullanır?
UX/UI tasarımcı + tasarım lead + Next.js geliştirme ekibi.
Nasıl Kullanılır?
- Token sayfasını doldurun (renk/tipo/spacing) ve kilitleyin.
- Component library’de variant/state’leri tamamlayın (focus/error/loading dahil).
- Rezervasyon pattern sayfasında 3 ekranı prototipleyin (oda listesi, oda detayı, form).
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ A) Design Tokens
- ▢ ✅ B) Component Library
- ▢ ✅ C) Hotel-specific Components
- ▢ ✅ D) Patterns (Reservation UX)
- ▢ ✅ Nasıl doldurulur? 1. Token’lar tamamlanmadan component’e geçmeyin.
- ▢ ✅ Nasıl doldurulur? 2. State’siz bileşen yayınlamayın (focus/error/loading şart).
- ▢ ✅ Nasıl doldurulur? 3. Çok dilli metin stres testini (DE/RU) her bileşende yapın.
- ▢ ✅ Nasıl doldurulur? 4. Pattern sayfaları, gerçek akış ekranlarıyla doğrulansın.
- ▢ ✅ Nasıl doldurulur? 5. Handoff sözlüğünü dev ile ortaklaştırın (isimlendirme + token map).
- ▢ ✅ Örnek — RoomCard: “Deluxe Sea View — AI”
- ▢ ✅ Örnek — PriceBlock: “Toplam fiyat (vergiler dahil)” + iptal özeti satırı.
- ▢ ✅ Kontrol
- ▢ ✅ Deliverable:
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
5. Çok dilli ve çok cihazlı yapılar için tasarım sistemi (TR–EN–DE–RU + mobil)
Otel projelerinde sistemin kırıldığı yer genelde burasıdır: Almanca metin taşar, Rusça satır sayısı artar, mobilde CTA bar çakışır, fiyat bloğu sığmaz. Design system, bu varyasyonları “kural seti”ne bağlar.
Çok dilli kurallar (pratik)
- •Metin alanları min/max genişlik tanımı
- •Uzun kelime kırma (hyphenation) stratejisi
- •Button label’ları için kısa alternatifler (TR/EN/DE/RU)
- •PriceBlock’ta para birimi ve format standardı
Çok cihazlı kurallar
- •Breakpoint token’ları (sm/md/lg)
- •Mobilde StickyCTA davranışı
- •Tablo/kart dönüşümü (mobilde kart, desktop’ta tablo gibi)
☑ Mini Check (Çok dilli/cihaz)
- •DE/RU metinleriyle stres testi yapıldı mı?
- •Mobilde StickyCTA menüyle çakışmıyor mu?
- •PriceBlock her breakpoint’te okunuyor mu?
- •Oda kartı bilgi hiyerarşisi mobilde bozulmuyor mu?
Ne yapmalıyım?
- • Çok dilli metin “son dakika çeviri” değil, sistem kuralı olsun.
- • Mobilde kritik pattern’leri (sticky CTA, date picker) ayrı test edin.
- • Bu yaklaşımı görsel dil ve motion ile bağlayın: https://dgtlface.com/tr/creative/grafik-motion-tasarim
6. Design system → geliştirme (Next.js) entegrasyonu (handoff)
Design system’in gerçek değeri, geliştirmeye sorunsuz geçtiğinde ortaya çıkar. Handoff’ın hedefi: “Figma’daki bileşen ile Next.js bileşeni aynı isim ve aynı davranışta olsun.”
Figma’dan geliştiriciye handoff pratikleri
- •Component isimlendirme sözlüğü (RoomCard, PriceBlock…)
- •Variant/state açıklamaları (loading/error/disabled)
- •Token map (Figma token → CSS/Tailwind token)
- •Responsive davranış notları
- •Asset export (optimize, sıkıştırılmış)
İç link (geliştirme süreci): https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme
İç link (performans teknik not): https://dgtlface.com/tr/seo/teknik-seo
Teknik not (LCP ve görseller)
Design system sayfası ve component görselleri LCP’yi bozmamalı:
- •Ekran görüntülerini sıkıştırın
- •Lazy-load kullanın (hero hariç)
- •Component highlight görsellerini küçük ve net tutun
☑ Mini Check (Handoff)
- •Dev sözlüğü ve isimler onaylı mı?
- •Token map dokümanı var mı?
- •Component state’leri devde karşılık buluyor mu?
- •Görsel ve doküman performansı iyi mi?
Ne yapmalıyım?
- • “Design system deliverable paketi” çıkarın: token tablosu + component listesi + pattern’ler.
- • Next.js tarafında component kütüphanesini token’larla başlatın.
- • Her sprintte 1–2 bileşeni sistemleştirerek ilerleyin (big-bang yapmayın).
7. Rakiplerin atladığı boşluk (otel özel design system farkı)
Rakip içerikler design system’i genelde SaaS ve ürün odaklı anlatır; otelde ise özel ihtiyaçlar vardır:
- •Rezervasyon akışına özel bileşenler (RoomCard, CancellationBadge, BoardTag)
- •Sezonluk kampanya blokları ve içerik modülleri
- •Çok dilli (TR–EN–DE–RU) ve destinasyon bazlı içerikler
Bu boşluğu kapatmanın yolu, design system’i “otel funnel” üzerinden kurmaktır.
☑ Mini Check (Fark)
- •Otel özel bileşen seti çıkarıldı mı?
- •Board/iptal/fiyat blokları standardize mi?
- •Çok dilli stres testi planlandı mı?
Bir Sonraki Adım
Otel projelerinizde UI kit ve token’ları netleştirip tasarım–geliştirme ekibini aynı sözlükte buluşturmak için workshop planlayın.
Sık Sorulan Sorular
Design system nedir, otel web sitelerinde ne işe yarar?▾
UI kit otel projelerinde neden kritik?▾
Figma’da otel için design system nasıl kurulur?▾
Design system geliştirici ekip ile nasıl paylaşılır?▾
Çok dilli otel projelerinde design system neyi çözer?▾
Design token’lar neden önemli?▾
İlgili İçerikler