Bir ürün ekibinde tasarım sorunları çoğu zaman tasarımın kendisinden çıkmaz. Aynı düğmenin üç farklı hâli, her sürümde yeniden açılan renk tartışması ya da geliştirme sırasında sessizce değişen bir akış; bunların hepsi kararların nasıl verildiğiyle ilgilidir. Bu yazı, tasarım kararlarını yönetilebilir kılan düzeni anlatıyor.
Kararın sahibi kim? #
İlk soru yetkiyle ilgilidir: bir ekran hakkında son sözü kim söyler? Cevap "herkes" ise karar toplantıda en yüksek sesle konuşana kalır. Cevap "kimse" ise karar geliştirme sırasında, zaman baskısıyla ve kayıt dışı verilir.
Karar sahipliği, başkalarının görüşünün alınmaması demek değildir. Ürün yöneticisi, geliştirici ve iş birimi görüş bildirir; tasarımın tutarlılığından sorumlu bir kişi kararı verir ve gerekçesini yazar. Bu kişinin kıdemli bir tasarımcı, bir tasarım lideri ya da dışarıdan bu rolü üstlenen bir ekip olması düzeni değiştirmez. Önemli olan rolün tanımlı olmasıdır.
Her karar aynı ağırlıkta değildir #
Bütün kararları aynı süreçten geçirmek ekibi yavaşlatır. Kararları iki gruba ayırmak işe yarar.
- Kolay geri alınan kararlar: bir metnin ifadesi, bir kartın düzeni, bir simgenin seçimi. Bunlar hızlı verilir, yayından sonra izlenir ve gerekirse değiştirilir.
- Zor geri alınan kararlar: gezinme yapısı, bilgi mimarisi, tasarım sisteminin temel değerleri, ürünün ses tonu. Bunlar daha fazla kanıt, daha geniş katılım ve yazılı gerekçe ister.
Ekiplerin zamanı sıkça birinci gruptaki kararları ikinci grubun ciddiyetiyle tartışırken harcanır. Ayrım baştan yapıldığında toplantılar kısalır.
Tek doğruluk kaynağı #
Bir kararın geçerli olması için herkesin aynı yerde aynı şeyi görmesi gerekir. Güncel tasarım dosyası hangisi, bileşenin doğru hâli nerede, onaylanan sürüm hangisi? Bu soruların cevabı kişilere değil, bir yere işaret etmelidir.
Tasarım sistemi bu ihtiyacı karşılar. Renk, aralık, bileşen ve kullanım kuralları bir kez kararlaştırılır ve hem tasarım hem kod tarafında aynı kaynaktan okunur. Sistemin ne zaman gerektiğini ve ne zaman yük olduğunu tasarım sistemi ne zaman gereklidir yazısında ele aldık. Sistem olmasa bile dosya düzeni, adlandırma ve "geçerli sürüm" kuralı yazılı olmalıdır.
Gözden geçirme ritmi #
Kararların iyi verilmesi için tasarımın erken ve düzenli görülmesi gerekir. Haftalık bir tasarım eleştirisi oturumu bu işi görür. Oturumun amacı beğeni toplamak değil, tasarımın hedefe uyup uymadığını sınamaktır. Sunan kişi hangi problemi çözdüğünü ve hangi konuda görüş istediğini söyler. Görüşler çözüm dayatmak yerine soru ve gözlem olarak verilir.
Ritim olmadığında tasarım ya çok geç görülür ya da herkes ayrı ayrı görüş bildirir ve tasarımcı çelişen yorumların arasında kalır.
Karar kaydı #
Önemli bir karar verildiğinde üç şey yazılır: ne kararlaştırıldı, hangi seçenekler elendi, neden. Kayıt uzun olmak zorunda değildir; birkaç satır yeterlidir.
Bu kayıt iki işe yarar. Ekibe yeni katılan biri aynı tartışmayı baştan açmaz. Koşullar değiştiğinde ise kararın hangi varsayıma dayandığı bilinir ve gerektiğinde bilinçli olarak değiştirilir.
Geliştirmeye teslim ve sonrası #
Tasarım kararı, kodda uygulandığı ölçüde geçerlidir. Teslim sırasında yalnız ekranlar değil, durumlar, sınır değerleri ve davranış kuralları da aktarılır. Yayından önce uygulanan ekran tasarımla karşılaştırılır; sapmalar göreve dönüştürülür.
Bu son adım atlandığında kararlar geliştirme sırasında sessizce değişir. Tasarımın koda geçerken nerede bozulduğunu Figma'dan çalışan ürüne geçiş yazısında ayrıntılı anlattık.
Birden çok ekip aynı ürüne dokunduğunda #
Marka iletişimini bir ajans, web sitesini başka bir ekip, mobil uygulamayı iç ekip, kurum içi araçları bir yazılım ortağı geliştiriyorsa kararlar kolayca parçalanır. Görsel dil bir yerde, kullanıcı deneyimi başka bir yerde, teknik uygulama farklı bir yönde ilerler.
Bu durumda eksik olan üretim kapasitesi değil, yöndür. Tasarım Liderliği hizmetinde iç ekiplerin ve üretim ortaklarının yerine geçmiyoruz. Marka, arayüz ve deneyim kararlarını ortak bir çerçevede topluyor, kalite standardını ve gözden geçirme ritmini kuruyoruz. Canlı bir üründe düzenli tasarım üretimi de gerekiyorsa bu rol Ürün Tasarım Desteği ile birlikte çalışır.
Nereden başlamalı #
Düzeni bir günde kurmak gerekmez. Sırayla şu üç adım çoğu ekip için yeterli bir başlangıçtır:
- Karar sahibini ve hangi kararların yazılı gerekçe istediğini belirleyin.
- Geçerli tasarım dosyasını ve bileşenlerin tek kaynağını ilan edin.
- Haftalık bir gözden geçirme oturumu koyun ve önemli kararları birkaç satırla kaydedin.
Bu üç adım oturduktan sonra tasarım sistemi, kalite kontrol ve ekipler arası koordinasyon gibi konular aynı düzenin üstüne eklenir.
Kaynaklar #
- Design Critiques: Encourage a Positive Culture to Improve Products, Nielsen Norman Group; tasarım eleştirisi oturumlarının düzeni
- Design Systems 101, Nielsen Norman Group; tasarım sisteminin ortak karar kaynağı olarak rolü
- Shape Up, Basecamp; kapsam ve karar sahipliği yaklaşımı
