Aydınlatma metni yükleniyor…
Dijital tasarım sistemi neden bir UI kütüphanesinden fazlasıdır?
B2B şirketlerde dijital ürünler çoğunlukla tek bir kurumsal web sitesinden ibaret değildir. Bayi portalı, müşteri paneli, B2B e-ticaret platformu, ERP bağlantılı operasyon ekranları ve mobil uygulama aynı markanın farklı temas noktalarını oluşturur. Her kanal bağımsız tasarlandığında renkler, butonlar ve formlar kadar kullanıcı rolleri, işlem adları, hata mesajları ve onay davranışları da birbirinden uzaklaşır. Sonuç; tutarsız bir marka deneyimi, tekrar eden geliştirme maliyeti ve yönetilmesi güç bir arayüz envanteridir.
Dijital tasarım sistemi; markanın görsel kararlarını, deneyim ilkelerini, tasarım tokenlarını, tekrar kullanılabilir bileşenlerini ve kullanım kurallarını ortak bir altyapıda toplar. UI bileşen kütüphanesi bu sistemin kod tarafındaki önemli bir çıktısıdır; ancak tek başına sistemin tamamı değildir. Sağlıklı bir yapı, “Buton hangi renkte?” sorusunun yanında “Bu işlemi hangi rol yapabilir, hangi durumda ek onay gerekir ve kullanıcıya nasıl geri bildirim verilir?” sorularını da yanıtlar.
Bu nedenle başlangıç noktası hazır bir bileşen seti seçmek değil, markanın ve ürün ailesinin ortak kararlarını tanımlamaktır. Kapsamlı bir dijital tasarım yaklaşımı, görsel kimliği gerçek kullanıcı görevleri ve teknik kısıtlarla buluşturur. Böylece tasarım sistemi yalnızca ekranları benzeştiren bir katalog değil, ekiplerin ortak ürün dili hâline gelir.
B2B ürünlerinde tasarım sistemini zorlaştıran gereksinimler
Tüketici odaklı basit bir akışta kullanıcı, ürün seçip ödeme yapabilir. B2B uygulamalarda ise bayi, satın alma uzmanı, yönetici, saha personeli, finans çalışanı ve sistem yöneticisi aynı veriyi farklı yetkilerle kullanabilir. Sipariş tutarı belirli bir limiti geçtiğinde onay gerekebilir; fiyatlar müşteri sözleşmesine göre değişebilir; stok, cari hesap ve sevkiyat bilgileri ERP’den gelebilir. Arayüz mimarisi bu kuralları görünür ve anlaşılır kılmalıdır.
Bir sipariş kartının yalnızca görünümü değil; taslak, onay bekliyor, reddedildi, ERP’ye aktarılıyor, kısmen sevk edildi ve iptal edildi gibi durumları da tanımlanmalıdır. Her durum için etiket, renk, açıklama, izin verilen eylem, yüklenme davranışı ve hata senaryosu belirlenmediğinde ekipler aynı süreci farklı ekranlarda farklı biçimde yorumlar.
Kurumsal ürünlerde yoğun veri tabloları, gelişmiş filtreler, toplu işlemler, belge yükleme ve uzun formlar da yaygındır. Masaüstünde hızlı işlem yapma ihtiyacı ile mobilde okunabilirlik aynı bileşenin farklı davranışlarını gerektirebilir. Tasarım sistemi bu farkları yok etmeye çalışmamalı; ortak ilkeler altında kanal ve kullanım bağlamına uygun varyantlar üretmelidir.
Tasarım sisteminin temel katmanları
| Katman | Cevapladığı soru | Temel çıktı | Ana sorumluluk |
|---|---|---|---|
| İlkeler | Nasıl karar veririz? | Deneyim kuralları | Marka ve ürün |
| Tokenlar | Kararı nasıl adlandırırız? | Renk, ölçü, tipografi | Tasarım ve geliştirme |
| Bileşenler | Arayüz nasıl davranır? | Varyant ve durumlar | UI ve ön yüz |
| Kalıp ve şablonlar | İş akışı nasıl kurulur? | Teklif, sipariş, onay akışları | Ürün ve iş birimi |
İlkeler ve ortak terminoloji
İlk katman, ürün kararlarını yönlendiren kısa ve uygulanabilir ilkelerdir. “İşlem sonucunu görünür kıl”, “Yetki sınırını kullanıcıya açıkla” veya “Kritik eylemlerde geri dönüş imkânı sun” gibi ilkeler, estetik tercihten daha kalıcıdır. Sipariş, teklif, müşteri, bayi ve onay gibi kavramların kurum genelinde aynı anlamda kullanılması da önemlidir. ERP’de “cari”, satış ekibinde “müşteri”, portalda “hesap” denilen yapı gerçekten aynı nesneyse ortak bir terim ve bağlamsal açıklama belirlenmelidir.
Tasarım tokenları
Renk, boşluk, yazı boyutu, köşe yarıçapı, gölge ve hareket süresi gibi kararlar tasarım tokenlarıyla adlandırılır. Ancak “mavi-500” gibi ham değerlerle yetinmek yerine “metin-birincil”, “yüzey-uyarı” veya “kenarlık-odak” gibi anlam taşıyan semantik katman kurulmalıdır. Böylece bir marka rengi değiştiğinde ya da koyu tema eklendiğinde her bileşeni ayrı ayrı düzenlemek gerekmez.
Design Tokens Community Group formatı, token kararlarının araçlar arasında aktarılabilmesi için ortak bir dosya yapısı tanımlar. Bu yaklaşım tasarım aracı, web kod tabanı ve mobil uygulama arasındaki elle kopyalama ihtiyacını azaltabilir. Yine de token adlandırması kurumun ürün mantığına göre kurulmalı; standart bir format, yanlış sınıflandırılmış kararları kendiliğinden düzeltmez.
UI bileşenleri, kalıplar ve şablonlar
Buton, alan, seçim kutusu ve etiket temel bileşenlerdir. Arama alanı ile filtre paneli veya ürün satırı ile miktar kontrolü birleştiğinde daha yüksek seviyeli kalıplar oluşur. Sipariş oluşturma, teklif karşılaştırma ya da kullanıcı yetkilendirme gibi şablonlar ise bileşenlerin gerçek iş akışında nasıl düzenleneceğini gösterir. Kurumsal UI bileşen mimarisi bu seviyeleri ayırarak aşırı büyük, yalnızca tek ekranda çalışan bileşenlerin oluşmasını önler.
Kurumsal UI bileşen mimarisi nasıl kurulmalı?
İlk adım mevcut ürünlerin ekran görüntülerini toplamak değil, gerçek arayüz örneklerini işlevlerine göre envanterlemektir. Aynı işi yapan farklı butonlar, aynı veriyi gösteren kartlar ve farklı hata mesajları kümelenir. Hangi parçanın standartlaştırılacağı; kullanım sıklığı, iş açısından kritikliği, erişilebilirlik riski ve geliştirme tekrarına göre belirlenir.
İkinci adımda bileşenin sözleşmesi yazılır. Bir bileşenin amacı, kabul ettiği veri, varyantları, boyutları, durumları, olayları ve erişilebilirlik davranışı açık olmalıdır. Örneğin kurumsal veri tablosu; sıralama, filtreleme, sayfalama, satır seçimi, boş sonuç, yüklenme, hata ve yetkisiz alan durumlarını kapsayabilir. Fakat her özelliği tek bileşene eklemek yerine temel tablo ile iş alanına özgü sipariş tablosu ayrılmalıdır.
Üçüncü adım tasarım ve kod karşılıklarını eşleştirmektir. Tasarım dosyasındaki varyant adları ile React veya React Native özellikleri aynı kavramsal modeli izlemelidir. Bileşenler izole ortamda görüntülenmeli; gerçekçi veri, uzun metin, farklı dil, dar ekran ve hata senaryolarıyla sınanmalıdır. Storybook’un bileşen odaklı iş akışı, varyasyonların bağımsız geliştirilmesini, belgelenmesini ve zor ulaşılan durumların kontrolünü destekler.
Dördüncü adım sürümleme ve dağıtımdır. Değişiklikler “görsel düzeltme”, “geriye uyumlu özellik” ve “uyumsuz API değişikliği” gibi sınıflara ayrılmalı; paket sürümleri ve geçiş notları yayınlanmalıdır. Web ve mobil aynı görsel dili kullanabilir, fakat platformların teknik bileşenleri ayrı paketlerde tutulabilir. Ortak token kaynağı ve davranış ilkeleri, her platformu aynı kod tabanına zorlamadan tutarlılık sağlar.
Tasarım sistemi oluşturma yol haritası
Tasarım sistemi bir kerede tamamlanan kapsamlı bir yeniden tasarım projesi olarak ele alınmamalıdır. En iyi başlangıç, şirketin sık kullanılan ve ölçülebilir sorun üreten bir akışıdır. Teklif oluşturma veya sipariş onayı gibi bir pilot akış; temel tokenları, form bileşenlerini, veri gösterimini ve durum yönetimini birlikte sınama fırsatı verir.
- Web, mobil ve portal kanallarını; kullanıcı rollerini ve kritik iş akışlarını haritalayın.
- Mevcut bileşenleri, tekrarları ve tutarsız durumları iş etkisine göre sınıflandırın.
- Marka ilkelerini, ortak terminolojiyi ve semantik tasarım tokenlarını tanımlayın.
- Pilot akış için bileşenleri, durumları, erişilebilirlik ölçütlerini ve kod sözleşmelerini üretin.
- Test, sürümleme, katkı ve sahiplik modelini kurarak sistemi diğer ürünlere genişletin.
Pilot sonunda yalnızca tasarımın beğenilip beğenilmediğine bakılmamalıdır. Yeni ekran üretme süresi, tekrar kullanılan bileşen oranı, arayüz kaynaklı hata sayısı, erişilebilirlik sorunları ve ekiplerin belgeye ulaşma süresi izlenebilir. Bu göstergeler sistemin gerçekten benimsenip benimsenmediğini ortaya koyar.
Erişilebilirlik, durumlar ve çoklu kanal tutarlılığı
Erişilebilirlik, bileşen tamamlandıktan sonra eklenen bir kontrol değil, bileşen sözleşmesinin parçasıdır. Klavye kullanımı, odak sırası, görünen etiket, erişilebilir ad, hata açıklaması ve ekran okuyucu geri bildirimi tasarım aşamasında tanımlanmalıdır. WCAG 2.2, aynı işlevi gören bileşenlerin tutarlı biçimde tanımlanmasını ve kullanıcı arayüzü durumlarının algılanabilir olmasını kapsayan ölçütler sunar.
Renk tek başına “onaylandı” veya “hatalı” anlamını taşımamalıdır; metin, simge ya da başka bir belirgin işaret kullanılmalıdır. Özellikle veri tablolarında seçili satır, odak, hata ve devre dışı durumları yeterli kontrastla ayrışmalıdır. Marka paletinin bu gereksinimlere uyarlanması için erişilebilir renk sistemi baştan kurulabilir; konuya ilişkin ayrıntılar erişilebilir renk sistemi rehberinde incelenebilir.
Web ve mobilde tutarlılık, bileşenin piksel düzeyinde aynı görünmesi değildir. Aynı işlemin adı, risk seviyesi ve sonuç mesajı ortak kalırken navigasyon, dokunma alanı veya yerel seçim kontrolü platforma uyarlanabilir. Tasarım sistemi değişmez ekranlar değil, tutarlı kararlar üretmelidir.
Yönetişim ve ekip sorumlulukları
Sahibi olmayan tasarım sistemi kısa sürede güncelliğini kaybeder. Marka, ürün tasarımı, ön yüz geliştirme, mobil geliştirme ve kalite ekiplerinden temsilcilerin yer aldığı küçük bir çekirdek ekip kurulabilir. Bu ekip her ekranı tasarlamak yerine standartları yönetir, katkıları değerlendirir ve uyumsuz değişikliklerin etkisini açıklar.
Yeni bileşen talebinde önce mevcut bileşenle çözüm aranmalı; yeni ihtiyaç gerçek bir tekrar potansiyeli taşıyorsa sisteme alınmalıdır. Talep; kullanım örneği, hedef roller, durum listesi, erişilebilirlik beklentisi ve teknik bağımlılıklarla birlikte sunulmalıdır. Onaylanan bileşen için tasarım, kod, test ve dokümantasyon aynı teslimatın parçaları kabul edilmelidir.
ERP bağlantılı ürünlerde sistem sınırları ayrıca kaydedilmelidir. Arayüz “sipariş onaylandı” dediğinde bunun yalnızca portal onayı mı, yoksa ERP kaydı mı olduğu açık olmalıdır. kurumsal kaynak planlaması ile arayüz mimarisini birlikte düşünmek; durumların, yetkilerin ve veri sahipliğinin gerçeğe uygun modellenmesine yardımcı olur.
Başarı nasıl ölçülür, hangi hatalardan kaçınılır?
Başarı yalnızca kütüphanedeki bileşen sayısıyla ölçülmez. Benimsenme oranı, yeni özelliklerin teslim süresi, yinelenen kod miktarı, tasarım-geliştirme uyuşmazlıkları, erişilebilirlik bulguları ve kullanıcıların kritik görevleri tamamlama başarısı birlikte değerlendirilmelidir. Çok sayıda bileşen üretip bunların ürün ekiplerince kullanılmaması, sistemin kapsamlı değil verimsiz olduğunu gösterebilir.
Yaygın hatalar arasında sistemi görsel stil rehberine indirgemek, tüm ihtiyaçları ilk sürüme almak, iş alanına özgü kuralları temel bileşenlere gömmek ve dokümantasyonu tasarım dosyasındaki notlara bırakmak bulunur. Bir başka risk de yönetim desteği olmadan ekiplerin kullanımını zorunlu kılmaktır. Sistem, günlük üretimi gerçekten hızlandırmalı ve istisnalar için şeffaf bir karar yolu sunmalıdır.
Kumsal Ajans ile uygulanabilir bir tasarım sistemi kurmak
Kumsal Ajans, dijital marka danışmanlığıyla görsel yönü ve deneyim ilkelerini belirler; Art Director liderliğinde dijital kimlik ile arayüz sistemlerini tasarlar. Kurumsal web tasarım, projeye özel web yazılımı, B2B e-ticaret ve React Native mobil uygulama yetkinliklerini aynı çerçevede ele alarak tasarım kararlarının geliştirilebilir bileşenlere dönüşmesini hedefler.
Süreç; mevcut kanalların ve bileşenlerin denetlenmesi, kullanıcı rolleri ile iş akışlarının çıkarılması, token mimarisi, pilot bileşen seti, kodlama yaklaşımı, entegrasyon sınırları ve yönetişim modelini kapsayabilir. Amaç hazır bir UI paketini markaya uyarlamak değil; kurumun gerçek operasyonlarını, marka özgünlüğünü ve teknik altyapısını sürdürülebilir bir ürün dilinde birleştirmektir.
Kurumunuzun mevcut dijital kanallarını, kullanıcı rollerini ve iş akışlarını birlikte değerlendirelim; markanıza ve teknik altyapınıza uygun, web ve mobil ürünlerde uygulanabilir bir tasarım sistemi yol haritası oluşturalım.