Design System Kurulumu
Ürün sayısı ve ekip büyüdükçe aynı düğmenin on farklı sürümü, aynı rengin yedi farklı tonu ortaya çıkar. Her yeni ekran sıfırdan tartışılır, tasarımla kod arasındaki fark her sürümde büyür. Design system bu tekrarı bir kez çözer.
Design system, bir şirketin dijital ürünlerinde kullanılan renk, yazı, boşluk gibi temel kararların (token'lar), tekrar kullanılan bileşenlerin ve bunların nasıl kullanılacağını anlatan kuralların tek bir kaynakta toplanmasıdır. Tasarımcı ve geliştiricilerin aynı dili konuşmasını, ürünlerin tutarlı kalmasını ve yeni ekranların daha hızlı yapılmasını sağlar.
Kuruluma mevcut arayüzün envanteriyle başlarız: neler var, hangileri gerçekten farklı, hangileri kazara farklı. Sonra temel kararları tasarım token'larına çevirir, bunları araçtan bağımsız ortak bir formatta (W3C Design Tokens topluluk grubunun DTCG formatı; bir W3C standardı değil, topluluk raporu) teslim ederiz. Bileşenleri tüm durumlarıyla tasarlar, kullanım kurallarını yazar ve sistemin kimin onayıyla nasıl büyüyeceğini belirleriz.
[01]Kimler için?
- Birden fazla ürünü ya da platformu olan şirketler
- Birden fazla tasarımcı ve geliştirme ekibi olan ürün organizasyonları
- Tutarlılığı bozulmuş, yeniden tasarım öncesi düzen isteyen ürünler
- Açık/koyu tema ya da birden çok marka desteği gereken ürünler
[02]Kimler için değil?
- Tek bir küçük ürün ve tek bir tasarımcıyla çalışıyorsanız tam bir design system erken olabilir; iyi düzenlenmiş bir bileşen kütüphanesi çoğu zaman yeterlidir.
- Logo, marka renkleri ve kurumsal kimlik bir marka tasarımı işidir; ürün arayüzü bu kimliği kullanır ama onu yaratmaz.
[03]Ne teslim edilir?
| Teslimat | İçerik | Sıklık |
|---|---|---|
| Arayüz envanteri | Mevcut renk, yazı, bileşen ve desenlerin dökümü | Başlangıç |
| Tasarım token'ları | Temel, anlamsal ve bileşen katmanları; DTCG formatında dışa aktarım | Proje |
| Bileşen kütüphanesi | Tüm durumlar, varyantlar ve erişilebilirlik notlarıyla | Proje |
| Tema desteği | Açık/koyu tema ya da çoklu marka | Kapsama göre |
| Dokümantasyon | Ne zaman hangi bileşen, yapılacaklar ve yapılmayacaklar | Proje |
| Yönetişim | Katkı süreci, sürümleme, kimin onay verdiği | Teslim |
[04]İlk 90 gün
- 1. aşama
Envanter
Mevcut ürünlerdeki arayüz öğeleri toplanır, tekrarlar ve sapmalar görünür olur.
- 2. aşama
Temeller
Renk, yazı, boşluk, köşe ve gölge kararları token'lara çevrilir.
- 3. aşama
Bileşenler
En çok kullanılan bileşenlerden başlanarak kütüphane kurulur.
- 4. aşama
Dokümantasyon ve devir
Kullanım kuralları, katkı süreci ve geliştirici ekiplerle senkronizasyon.
[05]Neyle ölçülür?
- Yeni ekranlarda sistem bileşenlerinin kullanım oranı
- Tasarım ile kod arasındaki bileşen farklarının azalması
- Bileşenlerin erişilebilirlik kontrollerinden geçmesi
[06]Sık yapılan hatalar
Her şeyi baştan yapmak
Sistemi en nadir bileşenden başlatmak enerjiyi tüketir. En sık kullanılan bileşenlerle başlamak hızlı fayda getirir.
Yalnız tasarım dosyasında kalmak
Kodda karşılığı olmayan bir design system yalnızca bir çizim kütüphanesidir. Token'lar ve bileşenler kodla eşleşmeli.
Sahipsiz bırakmak
Kimin sorumlu olduğu belli değilse sistem birkaç ayda eskir. Yönetişim, kurulum kadar önemlidir.
[07]Karşılaştırma
| Katman | Örnek | Kim kullanır |
|---|---|---|
| Temel token | Renk paleti, boşluk ölçeği | Sistem ekibi |
| Anlamsal token | Birincil arka plan, hata metni rengi | Tasarımcı ve geliştirici |
| Bileşen token'ı | Düğme dolgu rengi | Bileşen geliştirici |
| Bileşen | Düğme, form alanı, tablo | Tüm ürün ekipleri |
| Desen | Form doğrulama, boş durum | Tüm ürün ekipleri |
[08]Fiyatı ne belirler?
Sabit paket fiyatı yayınlamıyoruz; çünkü iki “mobil uygulama” ekran sayısı, kullanıcı rolleri, araştırma ihtiyacı ve mevcut tasarım sistemi açısından çok farklı iş yükü olabilir. Görüşmeden sonra kapsamı, yöntemi, takvimi ve fiyatı yazılı iletiriz. Dış katılımcı paneli gibi üçüncü taraf maliyetler ayrıca yazılır.
- Ürün ve platform sayısı
- Bileşen sayısı ve karmaşıklığı
- Tema ve marka sayısı
- Mevcut kod kütüphanesiyle eşleştirme
- Dokümantasyonun kapsamı
[09]Sık sorulanlar
Birden fazla ürün, platform ya da tasarım ve geliştirme ekibi olduğunda; aynı bileşenin farklı sürümleri çoğaldığında ve yeni ekranlar her seferinde sıfırdan tartışıldığında. Tek küçük üründe iyi bir bileşen kütüphanesi çoğu zaman yeterlidir.
W3C Design Tokens topluluk grubunun yayımladığı araçtan bağımsız formatta. Bu dosyadan web, iOS ve Android için gereken kod çıktıları üretilebilir; tasarım aracını değiştirseniz bile token'larınız taşınabilir kalır.
Evet. Çoğu zaman sıfırdan başlamak yerine ekibinizin kullandığı kütüphaneyi temel alıp sistemi onun üzerine kurarız; böylece geçiş maliyeti düşer.
Teslimde katkı ve onay sürecini yazılı olarak bırakırız. Kendi ekibinizde bir sahip belirlemenizi öneririz; isterseniz ilk aylarda sistemin bakımını birlikte yürütebiliriz.
Ürününüzü birlikte inceleyelim
Görüşmede ürününüzü, kullanıcılarınızı, takıldıkları yerleri ve ekibinizin yapısını konuşur; yazılı bir kapsam, yöntem ve takvim önerisi çıkarırız. Bağlayıcı değildir.