UX Ekiplerinde İş Birliği: Araç Değil, Tek Adres Sorunu
UX projelerinde iş birliği çoğu zaman araç eksikliğinden değil, araç fazlalığından tökezler. Tasarım Figma'da duruyor, yorumlar Slack'e düşüyor, karar bir toplantı notunda kalıyor; iki hafta sonra kimse o kararın nerede verildiğini bulamıyor. Sorun "hangi aracı alalım" değil, geri bildirimin nerede duracağı.
Önce tek adres belirle
Araç karşılaştırmasına girmeden önce ekipte üç şeyin yerini sabitle: yorum, karar, haber. Yorum tasarımın üstünde durur, çünkü bağlamı orada. Karardan çıkan iş bir görev kaydına yazılır, çünkü takip edilecek olan o. Slack ya da e-posta yalnızca haber verir, karar orada yaşamaz.
Ben genelde bu üçlüyü şöyle kurarım: yorumlar tasarım dosyasında, karar tek satır halinde issue açıklamasında, mesajlaşma kanalında sadece "şu ekran güncellendi" bilgisi. Kural basit olduğu için ekibe anlatması da kolay oluyor, üç günde oturuyor.
Araç sayısının görünmeyen maliyeti
Her yeni araç, geri bildirimin durabileceği bir yer daha demek. Beş aracın olduğu bir projede yeni katılan tasarımcı bir ekranın geçmişini öğrenmek için beş yeri taramak zorunda; üstelik hepsinin kendi hesabı, kendi izin ayarı ve kendi dışa aktarma formatı var.
Bu yüzden "entegrasyon kolaylığı" ile "her iş için uzmanlaşmış araç" tavsiyeleri birbirini yer. Entegrasyon gerçekten öncelikliyse en kısa yol daha iyi entegrasyon aramak değil, araç sayısını düşürmek. Entegrasyon bir bakım yükü; kurulduğu gün çalışır, altı ay sonra API değişince kimsenin sahiplenmediği bir kırık bağlantıya döner.
İhtiyacı işleve göre ayır
Yıllar önce ayrı ayrı satın alınan işlevlerin çoğu bugün tasarım aracının içinde. Listeyi araç adıyla değil, işlevle çıkarmak gerekiyor:
- Görsel üzerine yorum: Figma ve benzerleri bunu zaten yapıyor. Ayrı bir araca ancak dosya tasarım aracında değilse gerek var: video, PDF, canlı sitede işaretleme.
- Versiyon geçmişi: Tasarım aracının kendi geçmişi çoğu ekibe yetiyor. Yetmediği yer, tasarımın koda döndüğü yer; orada zaten sürüm kontrolü var.
- Prototip paylaşımı: Test edilecek akış tıklanabilir olsun yeter. Animasyon zenginliği kullanıcı testinde işe yaramıyor, hatta dikkati dağıtıyor.
- Affinity ve oylama: Araştırma notlarını gruplamak ve önceliklendirmek için pano araçları (Mural, eski adıyla Murally; FigJam, Miro) uygun. Burası hâlâ ayrı bir araca değebilecek tek başlık.
Kalan ihtiyaç genelde yoktur. Bir işlevin ayrı araçla çözülmesini savunmak için önce o işlevi mevcut araçta denemiş olmak gerekir.
Paydaş geri bildirimi araçla değil, soruyla düzelir
Müşteri prototipe bakıp "bir şey eksik gibi" yazdığında hiçbir yorumlama aracı bunu kullanılabilir hale getirmez. Açık uçlu davet, açık uçlu cevap üretir.
Paylaşım mesajına neye bakılacağını yaz: bu ekranda kullanıcının ilk yapması gereken ne, nerede duraksadın, hangi bilgi eksik hissettiriyor. Üç sorulu bir çerçeve, en pahalı geri bildirim aracından daha çok işe yarıyor. Yorum kutusunu boş bırakırsan renk tartışması gelir, akış tartışması gelmez.
Uzaktan ekipte asıl kıymetli olan yazılı iz
Dağınık ekiplerde eş zamanlı düzenleme sanıldığı kadar kritik değil. Aynı dosyada aynı anda çalışmak günde birkaç dakika kazandırır; asıl fark, kararın yazılı ve aranabilir olmasından gelir. Farklı saat dilimlerindeki bir ekipte "neden bu tasarımdan vazgeçtik" sorusunun cevabı bir yerde yazıyorsa toplantı sayısı kendiliğinden düşüyor.
Yeni bir araç almadan önce şunu sor: bu araç ekibe yeni bir yetenek mi kazandırıyor, yoksa mevcut dağınıklığın üstüne bir katman mı ekliyor? İkinci cevap çıkıyorsa, ücretsiz plan bile pahalı.
Kaynaklar