Aydınlatma metni yükleniyor…
Tasarım sistemindeki bir butonun yüksekliğini, form alanının hata davranışını veya kart bileşeninin yapısını değiştirmek küçük bir arayüz düzenlemesi gibi görünebilir. Oysa ortak bileşenler kurumsal web sitesinden e-ticaret platformuna, yönetim panelinden mobil uygulamaya kadar yüzlerce ekranı etkileyebilir. Görsel açıdan doğru görünen bir karar erişilebilirliği bozabilir; teknik olarak kolay bir düzenleme marka tutarlılığını zayıflatabilir; belirli bir ürünün ihtiyacını karşılayan çözüm diğer kanallarda gerilemeye yol açabilir.
Bu nedenle tasarım sistemi bileşen değişikliği tek bir tasarımcının, ürün yöneticisinin veya geliştiricinin kişisel onayına bırakılmamalıdır. Sağlıklı model; tasarım sorumlusu, ilgili ürün ya da iş sahibi ve teknik ekibin tanımlı ölçütlerle birlikte karar vermesidir. Değişikliğin niteliğine göre erişilebilirlik, içerik, güvenlik ve marka sorumluları da incelemeye katılmalıdır. Amaç kalabalık bir kurul oluşturmak değil, doğru risk için doğru uzmanlığı zamanında devreye almaktır.
Bileşen değişikliğinin tek sahibi değil, üçlü karar yapısı olmalı
Nihai karar yetkisi değişikliğin kapsamına göre farklılaşsa da üç temel bakış hiçbir zaman eksik kalmamalıdır. Tasarım sorumlusu görsel dil, etkileşim kalıbı ve sistem bütünlüğünü; ürün ya da iş sahibi kullanıcı ihtiyacı, iş değeri ve önceliği; teknik sorumlu ise uygulanabilirlik, bağımlılıklar, performans ve bakım etkisini değerlendirir. Böylece “güzel görünüyor”, “müşteri istedi” veya “kodlaması kolay” gibi tek boyutlu gerekçeler karar için yeterli sayılmaz.
Tasarım sorumlusunun onay alanı
Tasarım sorumlusu çoğu kurumda Design System Lead, Product Design Lead veya Art Director olabilir. Bu rol; önerinin marka karakteriyle uyumunu, mevcut tasarım tokenlarını, durum çeşitlerini, görsel hiyerarşiyi ve diğer bileşenlerle ilişkisini inceler. Yeni varyant gerçekten gerekli mi, yoksa mevcut seçeneklerden biri doğru kullanım rehberiyle ihtiyacı karşılıyor mu sorusuna yanıt verir. Kumsal Ajans’ın Art Director liderliğindeki dijital tasarım yaklaşımı, marka yönü ile ürün arayüzünü aynı karar sistemi içinde ele alır.
Ürün veya iş sahibinin onay alanı
Ürün ya da iş sahibi talebin hangi kullanıcı sorununu çözdüğünü, hangi iş hedefini desteklediğini ve neden şimdi yapılması gerektiğini doğrular. Bir bileşenin yalnızca tek kampanyada kullanılacak olması ile satın alma, üyelik veya teklif toplama gibi temel bir akışı iyileştirmesi aynı önceliğe sahip değildir. Bu rol ayrıca başarı ölçütünü tanımlar: görev tamamlama oranı, hata oranı, destek talebi veya dönüşüm gibi hangi göstergenin izleneceği değişiklikten önce belirlenmelidir.
Teknik sorumlunun onay alanı
Frontend veya mobil geliştirme sorumlusu önerinin kod mimarisine, API sözleşmelerine, tarayıcı ve cihaz desteğine, performansa ve test kapsamına etkisini inceler. Değişiklik geriye dönük uyumlu mu, mevcut prop veya parametreleri kırıyor mu, veri toplama ya da yetkilendirme davranışını değiştiriyor mu soruları burada yanıtlanır. Web, React Native ve e-ticaret kanallarında aynı görsel bileşenin farklı teknik uygulamaları bulunabileceği için onay yalnızca tasarım dosyasına bakılarak verilmemelidir.
Değişiklik talebinden yayın onayına karar akışı
Onay süreci herkesin takip edebildiği, kanıt üreten ve gereksiz toplantıları azaltan kısa bir akış olarak tasarlanmalıdır. Her talep aynı formdan açılmalı; ancak düşük riskli görsel düzeltmeler ile kullanıcı davranışını veya veri akışını değiştiren talepler farklı inceleme yollarına ayrılmalıdır.
1. Talebi sorun ve kanıtla tanımlayın
Talep kaydı, önerilen çözümle değil gözlenen sorunla başlamalıdır. Etkilenen kullanıcı grubu, ekranlar, kanallar, kullanım sıklığı ve mevcut davranış açıkça yazılmalıdır. Kullanıcı araştırması, analitik bulgusu, destek kaydı, erişilebilirlik testi veya teknik hata gibi kanıtlar eklenmelidir. Kanıt yoksa talep reddedilmek yerine keşif kuyruğuna alınabilir.
2. Kapsamı ve değişiklik sınıfını belirleyin
Değişiklik; düzeltme, küçük iyileştirme, yeni varyant, kırıcı değişiklik veya yeni bileşen olarak sınıflandırılabilir. Renk tokenındaki bir düzeltme ile form alanının klavye davranışını değiştirmek aynı inceleme kapsamına sahip değildir. Sınıflandırma; gerekli onay sahiplerini, test derinliğini, sürüm türünü ve yayın iletişimini belirler.
3. Tasarım, ürün ve teknik incelemeyi tamamlayın
Tasarım sorumlusu sistem tutarlılığını, iş sahibi ihtiyacı ve önceliği, teknik ekip ise uygulanabilirliği değerlendirir. Etkileşimli bileşenlerde erişilebilirlik kontrolü ayrı bir kabul kapısıdır. W3C’nin ARIA Authoring Practices Guide kaynağı; yaygın arayüz kalıpları için roller, durumlar, özellikler ve klavye etkileşimlerine ilişkin uygulama rehberliği sunar. Bununla birlikte örneklerin üretime hazır bir tasarım sistemi olmadığı unutulmamalı; kurumun kullanıcıları ve teknoloji yığını üzerinde ayrıca test yapılmalıdır.
4. Etki analizi ve prototip testi yapın
Bileşenin kullanıldığı tüm ekranlar envanterden çıkarılmalı; web, mobil, e-ticaret ve yönetim kanallarındaki örnekler kontrol edilmelidir. Varsayılan, hover, focus, active, disabled, loading, empty, error ve success durumları gerektiği ölçüde test edilmelidir. Metin uzaması, farklı dil, yakınlaştırma, klavye kullanımı ve ekran okuyucu davranışı da kapsamda olmalıdır. GOV.UK Design System’ın bileşen katkı ölçütleri, yayımlanacak bir çözümün kullanılabilir, tutarlı ve farklı bağlamlara uyarlanabilir olmasını; tarayıcılar, yardımcı teknolojiler ve cihazlarla sınanmasını ister. Bu yaklaşım kurum içi kabul kriterleri için güçlü bir referanstır.
5. Sürümleyin, yayımlayın ve sonucu izleyin
Onaylanan değişiklik tasarım kütüphanesi, kod paketi ve kullanım dokümantasyonunda aynı sürüm altında yayımlanmalıdır. Kırıcı değişikliklerde geçiş rehberi, eski kullanımın kaldırılacağı tarih ve sorumlu ekipler belirtilmelidir. Yayından sonra hata, kullanım ve iş sonucu göstergeleri izlenmeli; gerekirse geri alma planı çalıştırılmalıdır. U.S. Web Design System’ın bileşen yaşam döngüsü modeli, deneysel, kararlı, dikkatli kullanılmalı ve kullanımdan kaldırılmış gibi durumlarla olgunluğu görünür kılar. Benzer bir durum modeli, ekiplerin hangi bileşene ne ölçüde güvenebileceğini açıklar.
Değişiklik türüne göre kimlerin onayı gerekir?
Her talebi aynı kişilere göndermek süreci yavaşlatır; hiçbir eşik tanımlamamak ise kontrolsüz değişime yol açar. Pratik çözüm, değişiklik sınıfına göre zorunlu onay ve danışılacak rolleri önceden belirlemektir.
Yalnızca dokümantasyondaki yazım hatasını düzelten bir talepte sistem sorumlusunun onayı yeterli olabilir. Token değeri, boşluk, ikon boyutu veya tipografi değişikliği görsel bütünlüğü etkilediğinden tasarım sorumlusu ile teknik sorumlunun birlikte incelemesini gerektirir. Kullanıcı akışını, form doğrulamasını, ödeme adımını veya izin davranışını değiştiren taleplerde ürün sahibi de zorunlu karar verici olmalıdır. Kişisel veri, kimlik doğrulama ya da ödeme verisi işleniyorsa güvenlik ve mevzuat sorumlusu sürece eklenmelidir.
Yeni bir bileşen veya mevcut bileşenin kırıcı biçimde değiştirilmesi en yüksek inceleme düzeyini gerektirir. Burada tasarım, ürün ve teknik onaya ek olarak gerçek kullanıcı testi, erişilebilirlik doğrulaması, geçiş maliyeti ve kanal bazlı yaygınlık değerlendirilir. Karar kaydında kimin onay verdiği kadar hangi kanıta dayanıldığı ve hangi riskin kabul edildiği de bulunmalıdır.
| Değişiklik | Zorunlu onay | Ek kontrol | Yayın koşulu |
|---|---|---|---|
| Dokümantasyon düzeltmesi | Sistem sorumlusu | İçerik doğruluğu | Küçük sürüm |
| Görsel token veya varyant | Tasarım + teknik | Ekran regresyonu | Çoklu kanal testi |
| Etkileşim davranışı | Tasarım + ürün + teknik | Erişilebilirlik | Kabul testi |
| Kırıcı değişiklik / yeni bileşen | Üçlü kurul | Kullanıcı testi ve geçiş etkisi | Ana sürüm ve geçiş rehberi |
Onay kararında kullanılacak beş temel ölçüt
Marka ve sistem tutarlılığı
Öneri mevcut renk, tipografi, boşluk, hareket ve ikon ilkeleriyle uyumlu olmalıdır. Ancak tutarlılık, her kanalın tamamen aynı görünmesi anlamına gelmez. Mobilde dokunma alanı, web’de klavye odağı ve e-ticarette yoğun ürün bilgisi farklı çözümler gerektirebilir. Ortak ilke korunurken platforma uygun davranış tanımlanabilir.
Kullanıcı ihtiyacı ve kullanılabilirlik
Değişiklik gerçek bir kullanıcı sorununa dayanmalı ve çözümün anlaşılabilirliği test edilmelidir. Sadece bir paydaşın kişisel tercihi veya rakip üründe görülmüş olması yeterli kanıt değildir. Özellikle sık kullanılan form, navigasyon, arama, sepet ve ödeme bileşenlerinde prototip testi ile görev başarısı gözlemlenmelidir.
Erişilebilirlik
Kontrast, görünür odak, klavye sırası, erişilebilir ad, hata bildirimi, ekran okuyucu duyurusu ve dokunma hedefi gibi kontroller kabul kriterine dönüştürülmelidir. Erişilebilirlik incelemesi yayın sonundaki genel bir test değil, tasarım kararının parçasıdır. Bir etkileşim yalnızca fareyle çalışıyor veya durumu yalnızca renkle anlatıyorsa görsel onay verilmiş olması yeterli değildir.
Teknik uygulanabilirlik ve güvenlik
Teknik ekip bileşenin bağımlılıklarını, veri sözleşmelerini, performans maliyetini, otomatik testlerini ve güvenlik yüzeyini değerlendirir. Özellikle dosya yükleme, giriş, ödeme ve kişisel veri içeren formlarda görsel revizyon işlevsel riski gizleyebilir. Projeye özel ihtiyaçlarda kurumsal web tasarımı ile yazılım mimarisinin eş zamanlı planlanması, tasarım kararlarının uygulanabilir ve sürdürülebilir kalmasını destekler.
Mevcut ekranlara ve kanallara etki
Değişiklik yalnızca yeni ekran üzerinden değerlendirilmemelidir. Bileşenin hangi ürünlerde, kaç varyantla ve hangi sürümlerde kullanıldığı bilinmelidir. React Native mobil uygulamada çalışan yapı web karşılığıyla aynı özellik adlarına sahip olmayabilir; e-ticaret platformunda ise tema, üçüncü taraf ödeme modülü veya kampanya kuralı ek bağımlılık yaratabilir. Etki envanteri olmadan verilen onay, görünmeyen regresyon riskini büyütür.
RACI benzeri sorumluluk modeli nasıl kurulabilir?
Her bileşen ailesi için bir “sorumlu”, bir “nihai onay sahibi”, gerektiğinde görüşü alınacak uzmanlar ve bilgilendirilecek ekipler tanımlanabilir. Örneğin form bileşeninde tasarım sistemi tasarımcısı çalışmayı yürütür; Design System Lead tasarım kararını, frontend lead teknik kararı, ürün sahibi ise iş önceliğini onaylar. Erişilebilirlik uzmanı danışılan; web, mobil ve e-ticaret ekipleri bilgilendirilen taraf olabilir.
Nihai onay tek bir kişinin sınırsız veto yetkisi anlamına gelmemelidir. Tasarım, ürün ve teknik alanlardan biri zorunlu kabul ölçütünü karşılamıyorsa talep “reddedildi” yerine “revizyon gerekli” durumuna alınmalıdır. Görüş ayrılığı sürerse karar, önceden belirlenmiş ürün veya tasarım sistemi kuruluna taşınmalı; gerekçe ve kabul edilen risk kayda geçirilmelidir. Böylece kararlar kişisel otoriteye değil görünür ölçütlere dayanır.
Sık yapılan yönetişim hataları
- Tasarım dosyasındaki değişikliği kod kütüphanesine ve dokümantasyona yansıtmamak.
- Talebi yalnızca görsel beğeni üzerinden değerlendirip kullanıcı kanıtını aramamak.
- Küçük ve kırıcı değişiklikleri aynı onay akışına sokmak.
- Web üzerinde test edilen bileşeni mobil ve e-ticaret kanallarında otomatik olarak güvenli kabul etmek.
- Erişilebilirliği yalnızca renk kontrastı kontrolüne indirgemek.
- Eski varyant için kullanımdan kaldırma tarihi ve geçiş rehberi yayımlamamak.
- Kararın sahibini belirleyip bileşenin bakım sahibini tanımlamamak.
Bu hataları önlemek için bileşen kataloğunda sahip, yaşam döngüsü durumu, desteklenen platformlar, son inceleme tarihi ve bilinen sınırlamalar tutulmalıdır. Değişiklik kaydı; problem, kanıt, etkilenen sürümler, kabul kriterleri, test sonuçları, onaylayanlar ve yayın planını tek yerde birleştirmelidir.
Kuruma uygun onay modeli nasıl hayata geçirilir?
İlk adım mevcut bileşenleri ve kullanıldıkları kanalları çıkarmaktır. Ardından bileşen aileleri için tasarım ve teknik sahipler atanmalı, değişiklik sınıfları tanımlanmalı ve her sınıfın zorunlu kontrolleri belirlenmelidir. Sonraki aşamada talep şablonu, karar kaydı, test ortamı, sürümleme yaklaşımı ve yayın iletişimi standartlaştırılmalıdır.
Küçük bir pilot ekip seçerek buton, form alanı veya modal gibi yüksek kullanımlı bir aile üzerinde süreç denenebilir. Ortalama karar süresi, revizyona dönen talepler, yayın sonrası hata sayısı ve eski sürümde kalan ekranlar izlenmelidir. Süreç gereksiz bekleme yaratıyorsa onay eşikleri sadeleştirilmeli; hatalar canlıya taşıyorsa etki analizi ve test kapıları güçlendirilmelidir.
Kumsal Ajans; Art Director liderliğindeki tasarım yaklaşımını projeye özel web yazılımı, React Native mobil uygulama ve e-ticaret geliştirme yetkinlikleriyle birlikte ele alır. Böylece bileşen kararları yalnızca tasarım kütüphanesinde değil, gerçek ürün davranışı, performans, güvenlik ve sürdürülebilir bakım açısından değerlendirilebilir.
Sonuç: Onay yetkisini role değil riske göre dağıtın
Tasarım sistemindeki bileşen değişikliklerini tek bir kişi değil, değişikliğin etkisini temsil eden roller onaylamalıdır. Tasarım sorumlusu sistem ve marka bütünlüğünü, ürün veya iş sahibi kullanıcı ihtiyacı ile iş değerini, teknik ekip uygulanabilirlik ve bakım etkisini güvence altına alır. Erişilebilirlik, güvenlik ve içerik uzmanları ise risk ortaya çıktığında sürece zorunlu olarak katılır.
Başarılı yönetişim daha fazla imza toplamak değil; talebi kanıtla tanımlamak, etkisini görünür kılmak, doğru kabul ölçütleriyle test etmek ve kararı izlenebilir biçimde yayımlamaktır. Tasarım sisteminizdeki bileşen sahipliğini, onay adımlarını ve web, mobil ve e-ticaret kanallarındaki etki kontrolünü Kumsal Ajans ile birlikte planlayın.