Tasarım Sistemi Kurma Rehberi: Tutarlılık Kazanırken Yeni Borç Üretmeyin

1. Önce Tasarım Sistemine Gerçekten İhtiyacınız Olup Olmadığını Belirleyin

Tek ürün, küçük ekip ve seyrek arayüz değişikliği için sıkı bir UI kiti ile kod kütüphanesi yeterli olabilir. Birden fazla ürün, platform, marka veya ekip aynı etkileşimleri tekrar tekrar çözüyor; tutarsızlık erişilebilirlik ve kalite hatası doğuruyor; ortak değişiklikleri yaymak haftalar alıyorsa sistem yatırımı anlam kazanır. Kararı şirket büyüklüğüne değil, tekrarın maliyetine ve koordinasyon yüküne bağlayın.

Başlangıç envanterinde ekran görüntüsü saymayın. Aynı amaca hizmet eden buton, form alanı, navigasyon, tablo, bildirim ve modal varyantlarını; bunların kod tabanlarını, kullanım sıklığını, hata geçmişini ve sahiplerini bulun. Tasarım ile üretim arasındaki farkları ayrıca kaydedin. Beş farklı dosyada görünen aynı buton, beş ayrı ihtiyaç değil; kararın parçalandığına dair sinyaldir.

Başarı hipotezini yazın: ortak form bileşenleriyle erişilebilirlik regresyonunu azaltmak, yeni ürün akışında yeniden tasarım süresini kısaltmak veya marka değişikliğini merkezi jetonlarla yaymak gibi. ‘Tutarlılık artsın’ ölçülemez. Başlangıç değerini ve beklenen davranış değişimini belirlemeden sistem, sürekli bütçe isteyen soyut bir vitrine dönüşebilir.

2. Minimum Çekirdeği Jeton, Temel Stil ve Kritik Örüntülerle Sınırlayın

İlk sürüm bütün arayüzü kapsamak zorunda değildir. Renk, tipografi, boşluk, boyut, katman ve hareket kararlarını adlandıran tasarım jetonları; erişilebilir temel stiller; en sık ve riskli birkaç bileşen yeterli bir çekirdek olabilir. Kullanım sayısına ek olarak hata şiddetine bakın. Tarih seçici az kullanılabilir ama karmaşık ve kritikse sıradan karttan önce sistem kapsamına girebilir.

Her bileşen yalnızca görsel örnekten oluşmaz. Amaç, ne zaman kullanılacağı, ne zaman kullanılmayacağı, içerik kuralları, durumlar, klavye davranışı, erişilebilir adlandırma, responsive tepki, API sözleşmesi ve örnek kod birlikte yayınlanmalıdır. Tasarım varlığıyla kod bileşeninin aynı ad ve durum modelini kullanması ekipler arasındaki çeviri kaybını azaltır.

Ürün alanına özgü karmaşık bileşenleri erken merkezileştirmeyin. Sadece bir akışta görülen ve henüz değişen bir örüntü, ortak sisteme alınırsa deney yapmayı yavaşlatır. Önce yerel olarak öğrenin; birden fazla bağlamda yarar ve kararlılık kanıtlandığında katkı sürecinden geçirin. Sistem, tüm farklılıkları yok etmek değil, tekrar eden güvenli zemini sağlamaktır.

3. Merkezi Kontrol ile Ürün Katkısını Dengeli Yönetin

Merkezî model tutarlılık sağlar fakat kuyruğu yavaşlatabilir; dağıtık model hızı artırırken çatallanabilir. Çoğu ekipte küçük çekirdek ekip kalite, mimari ve yayını sahiplenir; ürün ekipleri araştırma, tasarım ve kodla katkıda bulunur. Karar hakları yazılı değilse tartışma kişisel zevk müzakeresine dönüşür.

GOV.UK Design System katkı ölçütleri, yeni önerinin faydalı ve benzersiz olduğuna dair kanıt ister. Yayın öncesinde ise örüntünün temsilî kullanıcılarla, engelli kullanıcılar dahil araştırılmış; tutarlı ve farklı hizmetlerde kullanılabilecek kadar çok yönlü olması beklenir. Bu yaklaşım, ‘bir ekip istedi’ sinyalini ortak sisteme kabul için yeterli görmez.GOV.UK Design System — Contribution criteria

Katkı şablonunda çözülen ihtiyaç, mevcut bileşenlerin neden yetmediği, kullanım bağlamları, araştırma kanıtı, erişilebilirlik testi, API etkisi, bakım sahibi ve geçiş planı bulunmalıdır. Hafif talepler için hızlı danışma yolu; kırıcı değişiklikler için daha ayrıntılı inceleme kurun. Reddedilen öneri de gerekçesiyle arşivlenmelidir; böylece aynı tartışma tekrar tekrar açılmaz.

• Çekirdek ekip ve ürün ekiplerinin karar hakları yazılı.
• Katkı için ihtiyaç, tekrar ve benzersizlik kanıtı isteniyor.
• Erişilebilirlik, içerik, tasarım ve kod birlikte inceleniyor.
• Her bileşenin bakım ve destek sahibi belli.
• Kırıcı değişiklik için sürüm ve geçiş politikası var.
• Reddedilen veya ertelenen önerilerin gerekçesi kayıtlı.

4. Dokümantasyonu Ürün Sözleşmesi, Sürümlemeyi Değişim Yönetimi Yapın

Dokümantasyon, bileşenin ekran görüntüsü değil kullanım sözleşmesidir. Tasarımcı için varyant ve içerik sınırını; geliştirici için API, bağımlılık ve örnekleri; kalite ekibi için beklenen etkileşimi; ürün yöneticisi için uygun kullanım koşulunu tek yerde buluşturur. Kodla dokümanın farklı sürümlere ayrılmasını önlemek için örnekleri mümkün olduğunca gerçek bileşenden üretin ve dokümantasyonu yayın sürecinin parçası yapın.

Semantik sürümleme benzeri açık bir politika kurun: hata düzeltmesi, geriye uyumlu özellik ve kırıcı değişiklik ne demektir? Değişiklik günlüğü kullanıcı etkisini anlatmalı; yalnızca dosya adlarını sıralamamalıdır. Kırıcı değişiklikte otomatik dönüştürme, kod örneği, son destek tarihi ve göç sorumlusu sunun. Bir sistemi güncel tutma maliyeti, onu ilk kurma maliyetinden daha uzun yaşar.

Tasarım kütüphanesi, paket deposu ve dokümantasyon sitesinin sürüm ilişkisini görünür kılın. Ekipler tasarımda yeni, kodda eski bileşen kullanıyorsa ‘tek doğruluk kaynağı’ iddiası bozulur. Kullanım telemetrisi kişisel veri toplamadan hangi paket sürümlerinin ve bileşenlerin aktif olduğunu gösterebilir; anket ve destek kayıtları ise neden benimsenmediğini açıklar.

5. Varsayımsal Senaryo: Üç Üründeki Form Borcunu Birleştirmek

Bu senaryo varsayımsaldır; gerçek bir müşteri sonucu değildir. Aynı şirketin üç web ürününde 14 metin alanı, altı hata mesajı biçimi ve dört farklı buton paketi kullanılsın. Ekipler yeni form ekranını hızlı çıkarıyor, fakat klavye odağı, hata özeti ve analitik adları her üründe farklı. Merkezi ekip başlangıçta tüm arayüz bileşenlerini altı ayda yeniden yazmayı öneriyor.

Envanter, sorunların çoğunun form ailesi ve temel jetonlarda toplandığını gösteriyor. Girdiler; kullanım sıklığı, erişilebilirlik riski, bakım maliyeti ve ürünler arası tekrar. Karar, büyük yeniden yazım yerine renk-tipografi-boşluk jetonlarıyla metin alanı, seçim, hata özeti ve birincil butondan oluşan pilot kurmak oluyor. Ürün ekiplerinden biri gerçek kayıt akışında pilot ortağı seçiliyor.

Pilotun kararı yalnızca güzel görünmeye dayanmaz. Entegrasyon süresi, bildirilen erişilebilirlik hatası, yerel override sayısı, dokümantasyonda cevap bulunma oranı ve geliştirici geri bildirimi izlenir. İki ürün daha bileşenleri benimseyebiliyor ve yerel çatallar azalıyorsa kapsam genişler. Karmaşık tarih seçici ise kullanıcı araştırması tamamlanana kadar ürün alanında kalır.

6. Benimsemeyi Duyuru Değil, Desteklenen Geçiş Programı Olarak Yönetin

Sistem yayınlandığında ekiplerin kendiliğinden geçmesini beklemeyin. İlk kullanıcıları yüksek ihtiyaç ve işbirliği isteğine göre seçin. Ofis saatleri, örnek entegrasyon, göç tarifleri ve doğrudan destek sağlayın. Yeni geliştirmelerde varsayılan kullanım ile eski ekranların kademeli dönüşümünü ayırın; her şeyi aynı anda taşımak yol haritasını kilitleyebilir.

Ölçümü çıktı ve sonuç olarak ikiye ayırın. Çıktı; yayınlanan bileşen, doküman kapsamı ve destek talebidir. Sonuç; aktif ürünlerde benimseme, sürüm güncelliği, yerel override, tekrar eden hata, değişikliği yayma süresi ve ekip memnuniyetidir. Çok indirme her zaman doğru kullanım değildir. Kod araması, paket telemetrisi ve örnek incelemesi birlikte daha gerçekçi resim verir.

İlk 90 günün ilk ayında envanter, hipotez ve sahiplik; ikinci ayında pilot çekirdek, dokümantasyon ve kalite testleri; üçüncü ayında gerçek ürün entegrasyonu, geri bildirim ve genişleme kararı tamamlanabilir. Takvim organizasyonun kapasitesine göre değişir. Her çeyrekte kullanılmayan bileşenleri, açık erişilebilirlik borcunu ve bakım kapasitesini gözden geçirip kapsamı daraltma hakkını koruyun.

• İlk benimseyen ürün ve gerçek kullanım akışı seçildi.
• Göç rehberi, örnek kod ve destek kanalı hazır.
• Yeni geliştirme ile eski ekran dönüşümü ayrı planlandı.
• Aktif kullanım ve yerel override birlikte ölçülüyor.
• Sürüm güncelliği ve kırıcı değişiklik geçişi izleniyor.
• Çeyreklik kapsam ve bakım kapasitesi incelemesi yapılıyor.

7. Sınırlar ve Başarısızlık Modları: Sistem Ürün Tasarımının Yerini Tutmaz

Tasarım sistemi yerel kullanıcı araştırmasını, ürün stratejisini veya uzman alan kararını ikame etmez. Ortak kart bileşeni hangi bilgiyi göstermeniz gerektiğini söylemez; erişilebilir form altyapısı gereksiz alanları haklı çıkarmaz. Sistem güvenli varsayımlar sunar, fakat her akış yine kullanıcı ihtiyacı ve bağlamla tasarlanmalıdır.

En sık başarısızlıklar; sistemi marka vitrini sanmak, bileşen sayısını başarı metriği yapmak, tasarım ve kodu ayrı yönetmek, katkıyı kapatmak, bakım bütçesi ayırmamak ve zorunlu kullanımı destek vermeden dayatmaktır. Aşırı soyut API'ler her olasılığı desteklemeye çalışırken kullanımı zorlaştırır. Fazla katı bileşenler ise ürün ekiplerini gizli çatallara iter.

GOV.UK Design System bileşen sayfalarında kullanım rehberiyle kodlanmış örnekleri birlikte sunar. Bu, kendi sisteminizin aynı yapıyı kopyalaması gerektiği anlamına gelmez; ancak bileşenin yalnızca görsel varlık değil, uygulama ve kullanım bilgisiyle tamamlanan bir sözleşme olduğunu gösteren kurumsal bir örnektir.GOV.UK Design System — Components

Sisteminiz küçük kalabilir ve yine de başarılı olabilir. Beş iyi desteklenen, erişilebilir ve yaygın kullanılan örüntü; elli sahipsiz bileşenden daha değerlidir. Yeni parça eklemek kadar birleştirmek, kullanım dışına almak ve ‘bu sistemin konusu değil’ diyebilmek de yönetişim işidir.