UX Ekibini İşletmede Verimli Kullanmanın Yolları
Bir UX ekibi kurmak bütçenin kolay kısmı. Zor kısmı, o ekibin çıktısının ürüne ve gelire gerçekten dokunması. Çoğu şirket birincisini yapıp ikincisini şansa bırakıyor, sonra da tasarımdan verim alamadığından yakınıyor.
Ekibi kurmak işin sonu değil, başı
Bir UX ekibine bütçe ayırıp sonra geri çekilen yönetici yatırımı yarıda bırakmış olur. Ekip; şirketin ne sattığını, kime sattığını ve bu çeyrek hangi metriği önemsediğini bilmeden çalışırsa, teknik olarak temiz ama işe yaramaz ekranlar üretir. İlk iş hedefi paylaşmak: hangi sayı hareket edecek, hangi kullanıcı grubu öncelikli. Bunu bir kez söyleyip geçmeyin, öncelikler değiştikçe ekibe taşıyın.
Toplantıya herkesi doldurmak
İletişimi artıralım diye her toplantıya on kişi çağırmak iletişimi artırmaz, kararı yavaşlatır. Bir tasarım kararını dört kişi yarım saatte alır, on kişi bir saatte alamaz. İlgili olanı çağırın, gerisini kısa bir özetle bilgilendirin.
Burada çoğu kaynağın atladığı bir çelişki var: aynı yazılar bir yandan toplantıyı küçük tut der, bir yandan geliştiriciyi sürece erken kat der. İkisi aynı anda geçerli olamaz. Çözüm herkesi her toplantıya çağırmak değil, geliştiriciyi doğru toplantıya çağırmak: renk paletini seçtiğiniz yere değil, bu etkileşim gerçekten yapılabilir mi diye sorulan yere.
Teslim tarihini UX'e sormadan koymak
Araştırmanın ve testin süresi pazarlık konusu değil, ölçüm konusu. Lansmanı 15'inde yapıyoruz deyip araştırmaya iki gün bırakırsanız, ya araştırma yapılmaz ya da yapılmış gibi yapılır. Tarihi UX ekibiyle birlikte koyun, kaç kullanıcıyla ve ne kadar sürede test edileceğini onlar söylesin.
Ekranı çizenle kodlayanı aynı masaya oturtun
UX'i cam bir kule gibi ayrı bir departman olarak kurmakla, onu geliştiricilerin arasına oturtmak arasında ikincisini açık ara daha verimli buluyorum. Sebebi basit: ekranı çizen kişiyle onu kodlayan kişi arasındaki mesafe arttıkça, tasarımın koda geçen oranı düşer. Uzaktaki bir ekip kullanıcı buraya sürükleyip bıraksın diye akıcı bir akış çizer, ama o akışın iki saatlik mi yoksa iki haftalık bir iş mi olduğunu ancak kodu yazan bilir. Bu bilgi tasarım masasına ne kadar geç ulaşırsa o kadar çizim çöpe gider.
İşe yarayan şey, geliştiriciyi çıktıyı gördüğü an değil karar alınırken içeri almak. Ortak küçük bir atölye, açık bir kanal, bunu üç günde mi üç haftada mı yaparız diye sorulabilen bir yakınlık yeterli.
Veriye erişimi bürokrasiye boğmayın
UX ekibi kullanıcının ne yaptığını göremiyorsa tahmin eder, tahmin de çoğu zaman en üsttekinin sezgisine döner. Kullanım verisine, destek kayıtlarına ve temel analitiğe erişimi baştan açın. Her sorgu için izin bekleyen bir ekip sormayı bırakır, varsayıma geçer.
Bu maddelerin ortak yanı mesafe. UX ekibi hedeften, geliştiriciden ve veriden ne kadar uzaksa o kadar az iş görüyor. Mesafeyi kapatın, işin çoğu orada çözülür.
Kaynak