01Sorun ve çözüm
Design system geliştirme bu dağınıklığı tek bir kaynağa bağlar. Renk, tipografi, boşluk ve köşe yarıçapı gibi kararlar tasarım tokenı olarak tanımlanır; bu tokenlar hem Figma kütüphanesini hem de kod bileşenlerini besler. Bileşenler erişilebilirlik kurallarına göre yazılır, kullanım örnekleriyle belgelenir ve ekiplerin kendi projelerine paket olarak ekleyebileceği biçimde sürümlenir.
02Kimler için
Design system kurulumu hangi ekipler için anlamlı
Tek bir tanıtım sayfası için design system kurmak gereksizdir; aşağıdaki durumlarda ise yatırım kendini hızla gösterir.
- Müşteri paneli, yönetim paneli ve mobil uygulama gibi birden fazla arayüzü olan ürün şirketleri
- Aynı ürünü farklı markalarla sunan ve tema değiştirerek yeni müşteri ortamı açmak isteyen white-label yazılım sağlayıcıları
- Birden fazla frontend ekibi aynı ürün üzerinde çalışan ve tutarlılığı kod incelemesiyle korumaya çalışan şirketler
- Marka yenilemesi sonrasında bütün dijital ürünlerini yeni kimliğe kontrollü biçimde taşımak isteyen kurumlar
- Erişilebilirlik gereksinimlerini her ekranda ayrı ayrı çözmek yerine bileşen düzeyinde güvenceye almak isteyen ekipler
03İhtiyaçlar
Arayüz tutarsızlığının ekiplere maliyeti
Sorun görsel olduğu kadar operasyoneldir; tekrar eden iş ve hata olarak geri döner.
- 01
Tasarım ile kod arasındaki kopukluk
Tasarımcı Figma'da bir rengi güncellediğinde bu değişikliğin kodda nereye denk geldiği belirsizdir. Ortak token isimleri ve otomatik dönüşüm, iki tarafın aynı dili konuşmasını sağlar.
- 02
Aynı bileşenin defalarca yazılması
Her ekip kendi açılır menüsünü, modal penceresini ya da tablo bileşenini yazdığında hatalar da çoğalır. Merkezi bir bileşen düzeltildiğinde bütün ürünler bir sonraki sürümde düzelir.
- 03
Tema ve marka varyasyonları
Karanlık tema, yüksek kontrast modu ya da müşteriye özel marka renkleri sabit renk kodlarıyla yazılmış bir arayüzde ancak elle aranıp değiştirilerek uygulanabilir. Token katmanları bu değişikliği tek bir dosyaya indirir.
- 04
Erişilebilirlik borcu
Klavyeyle kullanılamayan bir menü ya da ekran okuyucunun okuyamadığı bir form alanı, o bileşenin geçtiği her ekranda tekrar eder. Bileşen düzeyinde çözülen erişilebilirlik bütün ürüne yayılır.
04Özellikler
Design system kapsamında teslim edilen parçalar
Kapsam, envanter çalışmasında mevcut arayüzlerinizden çıkan ihtiyaca göre belirlenir.
- 01
Arayüz envanteri ve denetim
Mevcut ekranlardaki renk, yazı boyutu ve bileşen varyasyonları toplanır; hangilerinin birleştirileceği tasarım ekibinizle birlikte karara bağlanır.
- 02
Katmanlı tasarım tokenları
Ham renk paleti, anlamsal tokenlar ve bileşene özel tokenlar ayrı katmanlarda tanımlanır; tema değişimi yalnızca anlamsal katmanda yapılır.
- 03
Bileşen kütüphanesi ve canlı belge
Buton, form alanı, tablo, modal ve bildirim gibi bileşenler durumları ve varyantlarıyla birlikte Storybook gibi bir ortamda belgelenir; geliştirici kodu oradan kopyalayabilir.
- 04
Katkı ve sürüm kuralları
Yeni bir bileşen önerisinin nasıl yapılacağı, hangi değişikliğin ana sürüm gerektirdiği ve eski bileşenlerin nasıl kullanımdan kaldırılacağı yazılı bir rehberle belirlenir.
05Entegrasyonlar
Design system kurulumu projelerinde kullanılan araçlar
Sistem, ekiplerin zaten kullandığı araç zincirine yerleşmelidir.
- 01
Figma değişkenleri ve kütüphaneleri
Tokenlar Figma değişkenleri olarak tanımlanır, bileşenler paylaşılan kütüphanede yayınlanır; tasarımcılar güncellemeleri kendi dosyalarına kontrollü biçimde alır.
- 02
Token dönüştürme hattı
Style Dictionary gibi araçlarla tokenlar CSS değişkenlerine, mobil platformların renk ve boyut dosyalarına otomatik dönüştürülür.
- 03
Paket kayıt sistemi
Bileşen kütüphanesi npm üzerinden özel bir paket olarak ya da kurum içi paket deposunda yayınlanır; projeler sürüm numarasıyla bağımlılık ekler.
- 04
Görsel regresyon testleri
Her değişiklikte bileşenlerin ekran görüntüleri öncekiyle karşılaştırılır; istenmeyen bir görsel fark birleştirmeden önce yakalanır.
06Süreç
Design system kurulumu hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Çerçeve bağımsızlığı ve erişilebilir bileşen mimarisi
Bütün ürünleriniz React kullanıyorsa bileşenler doğrudan React ile yazılır. Farklı çerçeveler bir aradaysa, örneğin bir tarafta Vue diğer tarafta Angular varsa, tokenlar ortak tutulur ve bileşenler web bileşeni olarak ya da her çerçeve için ince bir sarmalayıcıyla sunulur. Kütüphane, kullanılmayan bileşenlerin uygulama paketine girmeyeceği biçimde yapılandırılır.
Devamını okuDaha az göster
Her bileşen WCAG kontrast oranlarına, klavye gezinmesine ve doğru ARIA rollerine göre yazılır; odak sırası ve ekran okuyucu davranışı otomatik testlerle denetlenir. Tasarım tokenlarındaki renk çiftleri de tema eklenirken kontrast açısından kontrol edilir, böylece yeni bir marka teması okunabilirliği bozmaz.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Bakım ve destek
Aylık sözleşmeli, SLA'lı bakım, destek ve geliştirme saati
Yayındaki bir sistemin sürekliliği için.
- Aylık sözleşme ve SLA
- İzleme, güncelleme ve hata düzeltme
- Aylık geliştirme saati
09Sık sorulan sorular
Design system kurulumu hakkında sık sorulan sorular
Material UI gibi hazır bir kütüphane varken neden kendi design system'imizi kuralım?
Hazır kütüphaneler iyi bir başlangıç noktasıdır ve çoğu zaman temel olarak kullanılabilir. Markanıza özgü görünüm, birden fazla temaya ihtiyaç ya da kütüphanede olmayan alan bileşenleri gerektiğinde, hazır kütüphanenin üzerine kendi token ve bileşen katmanınızı kurmak daha sürdürülebilir olur.
Mevcut ürünü bozmadan design system'e nasıl geçilir?
Geçiş ekran ekran yapılır. Önce tokenlar eklenir ve sabit renkler bunlarla değiştirilir, sonra en sık kullanılan bileşenler yenisiyle değiştirilir. Eski ve yeni bileşenler bir süre birlikte yaşar, görsel regresyon testleri farkları izler.
Design system kurulumu fiyatları neye göre şekillenir?
Bileşen sayısı, desteklenecek tema ve çerçeve sayısı, Figma kütüphanesinin de kapsamda olup olmadığı, erişilebilirlik testlerinin derinliği ve mevcut ürünlere geçiş desteği belirleyicidir. Envanter çalışmasından sonra kapsam netleşir.
Sadece Figma tarafını ya da sadece kod tarafını yaptırabilir miyiz?
Yaptırabilirsiniz, ancak asıl fayda iki tarafın aynı tokenlardan beslenmesinden gelir. Tasarım ekibiniz Figma kütüphanesini yönetiyorsa biz kod tarafını onunla eşlenecek şekilde kurarız.
Design system'in bakımını kim yapacak?
Sistem bir kez kurulup bırakılırsa ekipler kısa sürede yeniden kendi bileşenlerine döner. Kurum içinde bir sahip belirlenmesini öneriyoruz; yeni bileşen talepleri ve sürümler için bakım ve destek modeliyle yanınızda kalabiliriz.
Design system kurulumu için firma seçerken neye bakmalıyız?
Tasarım ile kodun aynı tokenlardan nasıl beslendiğini, erişilebilirliğin nasıl test edildiğini ve sürüm kurallarının nasıl işletileceğini sorun. Örnek bir bileşenin belgesini görmek, ekiplerin onu nasıl kullanacağı hakkında net fikir verir.
10İlgili hizmetler