Tasarım Sistemleri: Çoğu Neden Başarısız Olur ve Çalışan Bir Tane Nasıl Oluşturulur

Belli bir büyüklüğe ulaşan her ekip sonunda aynı şeyi söyler: "Bir tasarım sistemine ihtiyacımız var." Sonra çoğu, kimsenin kullanmadığı bir sistem inşa etmek için altı ay harcar ve bir yıl sonra başladıkları aynı tutarsızlığa geri dönerler.

Sorun asla bileşenler değildir. Sorun, bir tasarım sistemini bir ürün yerine bir proje gibi ele almaktır. Projeler biter. Ürünler gelişir. Gelişmeyi durduran bir tasarım sistemi, piyasaya sürüldüğü gün ölmeye başlar.

Bir Tasarım Sistemi Gerçekten Nedir

Bir tasarım sistemi bir bileşen kütüphanesi değildir. Bir bileşen kütüphanesi, yeniden kullanılabilir UI parçalarından oluşan bir klasördür. Bir tasarım sistemi, bir ürünün nasıl tasarlandığını ve inşa edildiğini yöneten eksiksiz standartlar, dokümantasyon ve araçlar bütünüdür.

Şunları içerir:

• Tasarım tokenları. Diğer her şeyin referans aldığı atomik değerler (renkler, boşluklar, tipografi, gölgeler).
• Bileşenler. Tokenlardan oluşturulmuş yeniden kullanılabilir UI öğeleri.
• Desenler. Tekrarlayan tasarım sorunları için belgelenmiş çözümler (formlar, navigasyon, hata durumları).
• Yönergeler. Her bir parçanın ne zaman ve nasıl kullanılacağına dair kurallar.
• Yönetişim. Sistemi kimin sahiplendiği, değişikliklerin nasıl önerildiği ve kararların nasıl alındığı.

Bunlardan herhangi birini çıkarırsanız, eksik bir sisteme sahip olursunuz. Eksik sistemler, kısmi benimsemeye yol açar. Kısmi benimseme, çözmeye çalıştığınız aynı tutarsızlığı yaratır.

Çoğu Tasarım Sistemi Neden Başarısız Olur

Başarısızlık 1: Yalıtılmış olarak inşa edildi. Küçük bir ekip üç ay ortadan kaybolur, güzel bir sistem inşa eder ve bunu hiçbir girdisi olmayan bir kuruluşa sunar. Sistem, kullanıcıların gerçekliğini değil, inşa edenlerin varsayımlarını yansıtır. Benimseme başlangıçta nazikçe olur, sonra sessizce terk edilir.

Başarısızlık 2: Çok erken çok katı. Sistem, her senaryo için katı kurallarla başlatılır. Sistemin öngörmediği bir durumla karşılaşan tasarımcılar ve mühendislerin iki seçeneği vardır: sistemle savaşmak ya da onu atlatmak. Çoğu, atlatma yolunu seçer. Sistem, kimsenin referans almadığı bir referans haline gelir.

Başarısızlık 3: Özel bir sahiplenme yok. Sistem bir sprint sırasında inşa edildi. Kimse onu sürdürmekle görevlendirilmedi. Tokenlar kod tabanından sapar. Bileşenler ürünün gerisinde kalır. Dokümantasyon güncelliğini yitirir. Altı ay sonra, sistem ürünün geçen yılki halinin bir anlık görüntüsüdür.

Başarısızlık 4: Bileşen öncelikli düşünme. Ekip, tek bir token tanımlamadan veya tek bir yönerge yazmadan önce 47 bileşen oluşturur. Bileşenler Figma dosyasında çalışır ancak temel değerler asla sistemleştirilmediği için üretimde bozulur.

Başarısızlık 5: Mükemmeliyet felci. Ekip, herhangi bir şeyi başlatmadan önce her uç durumu çözmeye çalışır. Sistem asla yayınlanmaz. Bu arada, ürün onsuz her gün yayınlanır.

Hayatta Kalan Sistemlerin Ortak Noktaları

Gerçekten kalıcı olan sistemleri (Shopify Polaris, Atlassian Design System, IBM Carbon, GitHub Primer) inceledikten sonra üç ortak desen ortaya çıkıyor:

Küçük başladılar ve büyüdüler. Hiçbiri 200 bileşenle piyasaya sürülmedi. Tokenlar, birkaç temel bileşen ve net dokümantasyonla başladılar. Sonra teorik eksiksizliğe göre değil, gerçek ürün ihtiyaçlarına göre genişlediler.

Özel ekipleri var. Tek bir kişi değil. Bir ekip. Büyük ölçekli tasarım sistemleri minimumda bir tasarımcı, bir mühendis, bir dokümantasyon yazarı ve bir ürün sahibini gerektirir. Shopify'da Polaris üzerinde düzinelerce insan çalışıyor. Düzinelerce kişiye ihtiyacınız yok, ancak sıfırdan fazlasına ihtiyacınız var.

Katkıları bir özellik olarak ele alırlar. En iyi sistemler, ürün ekiplerinin eklemeler önermesini, sorunları işaretlemesini ve bileşenler katkıda bulunmasını kolaylaştırır. Sistem sadece merkezden değil, kenarlardan da büyür. Sadece bir ekibin kararlarıyla büyüyen bir sistem, her zaman ürünün gerisinde kalacaktır.

Tasarım Tokenları Gerçek Temeldir

Tokenlar, diğer her şeyin miras aldığı ilkel değerlerdir. Bir tokenı değiştirin ve onu referans alan her bileşen otomatik olarak güncellenir. Bir sistemi bir koleksiyon yerine bir sistem yapan şey budur.

Token seviyeleri:

| Seviye | Örnek | Amaç | |---| | Global | color-blue-500: #3B82F6 | Ham palet değerleri | | Semantik | color-primary: {color-blue-500} | Anlam tabanlı takma adlar | | Bileşen | button-bg: {color-primary} | Bileşene özgü bağlamalar |

Global tokenlar ham değerleri tanımlar. Semantik tokenlar anlam atar (birincil, tehlike, yüzey). Bileşen tokenları bu anlamları belirli UI öğelerine bağlar. Bu üç katmanlı yapı, tek bir bileşene dokunmadan semantik tokenları değiştirerek yeniden markalaşabileceğiniz anlamına gelir.

Önce tanımlanacak token türleri:

• Renkler (arka plan, metin, kenarlık, etkileşimli durumlar)
• Boşluk (4 piksel ızgara: 4, 8, 12, 16, 24, 32, 48, 64)
• Tipografi (aile, boyut ölçeği, ağırlık, satır yüksekliği)
• Kenarlık yarıçapı (yok, küçük, orta, büyük, tam)
• Gölgeler (yükseklik seviyeleri)
• Hareket (süre, yumuşatma eğrileri)

Başka hiçbir şey tanımlamazsanız, bunları tanımlayın. Ekibinizin günlük görsel kararlarının %90'ını kapsarlar.

Kalıcı Bileşenler Oluşturmak

Tokenlar üzerine inşa edilen bileşenler, sabit kodlanmış değerler üzerine inşa edilen bileşenlerden doğası gereği daha dayanıklıdır. Ancak token tabanlı bileşenler bile yanlış inşa edilirse başarısız olur.

Hayatta kalan bileşenler için kurallar:

Konfigürasyon yerine kompozisyon. 14 prop'lu bir düğme esnek değildir. Kırılgandır. Her varyantı prop'lar aracılığıyla ele alan mega bir bileşen oluşturmak yerine, desenler halinde birleşen küçük, birleştirilebilir parçalar oluşturun. Bir kart tek bir bileşen değildir. Bir kart kapsayıcısı, bir kart başlığı, bir kart gövdesi ve bir kart altbilgisinden oluşur ve bunlar bir araya gelir.

Durumlar isteğe bağlı değildir. Her etkileşimli bileşenin şunlara ihtiyacı vardır: varsayılan, üzerine gelme, aktif, odaklanma, devre dışı, yükleniyor ve hata durumları. Yedi durumun tamamı olmadan bir bileşen göndermek, birisinin bu durumları geçici olarak inşa edeceği ve bunların eşleşmeyeceği anlamına gelir.

Sadece "ne" değil, "ne zaman"ı da belgeleyin. Düğme dokümantasyonunuz sadece nasıl göründüğünü göstermemelidir. Birincil düğmeyi ne zaman, ikincil düğmeyi ne zaman veya hayalet düğmeyi ne zaman kullanacağınızı belirtmelidir. Karar çerçevesi, görsel referanstan daha önemlidir.

Desenler, Bileşenlerin Çözemediği Sorunları Çözer

Bir açılır menü bileşeni, bir açılır menünün nasıl göründüğünü söyler. Ancak bir açılır menüyü ne zaman, bir radyo grubunu ne zaman veya segmentli bir kontrolü ne zaman kullanacağınızı söylemez. Bu karar bir desendir.

Erken belgelenecek desenler:

• Form düzenleri. Etiket yerleşimi, hata gösterimi, zorunlu alan belirtimi, çok adımlı akışlar.
• Navigasyon. Sekmeleri ne zaman, kenar çubuğunu ne zaman veya ekmek kırıntılarını ne zaman kullanmalı. Mobil navigasyonun daralma davranışı.
• Boş durumlar. Veri olmadığında ne gösterilir. İllüstrasyon mu? CTA mı? Eğitici içerik mi?
• Yükleme durumları. İskelet ekranlar mı, dönen simgeler mi, yoksa aşamalı yükleme mi. Her birinin ne zaman uygun olduğu.
• Hata yönetimi. Satır içi doğrulama mı, bildirimler mi, yoksa tam sayfa hata durumları mı.

Bu desenler, bir sistemi olmayan ekipleri rahatsız eden "aynı formu beş farklı şekilde inşa ettik" sorununu önler.

Yönetişim Benimsemeyi Sağlar veya Bozar

Yönetişimi olmayan bir tasarım sistemi bir öneridir. Yönetişim üç soruyu yanıtlar:

1. Kim karar verir? Bir inceleme kurulu var mı? Tek bir sahip mi? Demokratik bir oylama mı? Ne seçerseniz seçin, bunu açıkça belirtin.
2. Değişiklikler nasıl gerçekleşir? RFC süreci mi? GitHub sorunu mu? Slack ileti dizisi mi? "Yeni bir bileşene ihtiyacımız olduğunu düşünüyorum"dan "sistemde"ye giden yolu tanımlayın.
3. Sürümleme stratejisi nedir? Token paketi için semantik sürümleme mi? Her sürüm için değişiklik günlüğü mü? Kırıcı değişiklik politikası mı?

Yönetişimi atlayan ekipler, çatallanan bir sistemle karşılaşır. Tasarım 2.3 sürümünü kullanır. Mühendislik 1.8 sürümünü kullanır. Pazarlama sitesi yerel geçersiz kılmalarla 2.0 sürümünü kullanır. Bu noktada, üç tasarım sisteminiz ve sıfır tutarlılığınız olur.

Sıkça Sorulan Sorular

Bir tasarım sistemi oluşturmak ne kadar sürer?

Başlangıç temeli (tokenlar, 10-15 temel bileşen, temel dokümantasyon) özel bir ekiple 2-4 ay sürer. Ancak bir tasarım sistemi asla "bitmiş" değildir. Bir tasarım mühendisliği ekibinin kapasitesinin %15-25'i oranında sürekli yatırım planlayın.

Küçük ekiplerin bir tasarım sistemine ihtiyacı var mı?

Evet, ancak orantılı bir tane. 3 kişilik bir ekibin Polaris'e ihtiyacı yoktur. Tokenlar, 8-10 temel bileşen ve tek sayfalık bir karar kılavuzu içeren paylaşılan bir Figma kütüphanesine ihtiyaçları vardır. En çok acı veren şeyle (genellikle tutarsız boşluk ve renk kullanımı) başlayın ve oradan büyüyün.

Bir tasarım sistemi ile bir bileşen kütüphanesi arasındaki fark nedir?

Bir bileşen kütüphanesi, yeniden kullanılabilir UI öğelerinin bir koleksiyonudur. Bir tasarım sistemi, bileşen kütüphanesine ek olarak tasarım tokenlarını, kullanım yönergelerini, desenleri, dokümantasyonu ve yönetişimi içerir. Kütüphane, sistemin bir katmanıdır.

Hırsla Değil, Acıyla Başlayın

Profesyonel göründüğü için bir tasarım sistemi oluşturmayın. Ekibiniz aynı sorunları tekrar tekrar çözmekle zaman kaybettiği için bir tane oluşturun. Şu anda en çok tutarsızlığa neden olan üç şeyle başlayın. Bunları sistemleştirin. Yayınlayın. Sonra bir vaka çalışmasında etkileyici görünen şeye göre değil, ekibin bir sonraki ne istediğine göre genişletin.