UX Ekiplerinin Asıl Sorunu: Etkiyi Gösterememek
UX ekiplerinin en sık şikayeti anlaşılmamak. Şikayet haksız değil, ama çözüm algıyı düzeltmeye çalışmakta değil: kimse sunumla ikna olmuyor. Etkisini bir sayıya bağlayamayan ekip, bütçe daralınca ilk kesilen yer oluyor. Aşağısı o sayının nasıl kurulacağı üzerine.
"Ölçülemez" demeden önce
Yatırım getirisini ölçmenin zor olduğu doğru, ama zorluk genelde yanlış yerde aranıyor. Tasarımın şirket cirosuna katkısını kimse izole edemez, denemeye de değmez. İzole edilebilecek olan çok daha küçüktür: tek bir akışın tamamlanma oranı, tek bir formun doğrulama hatası sayısı, tek bir ekrandan gelen destek talepleri.
Ölçümü genelde ürün analitiğine yeni bir olay ekleyerek çözerim. Ayrı bir UX panosu kurmaktansa mevcut olay şemasına iki alan eklemek hem daha ucuz oluyor hem de altı ay sonra hâlâ çalışıyor; kimsenin bakmadığı pano ise ilk sürümde ölüyor.
Yöneticiyi hangi cümle ikna eder
İkna eden sayı büyük olan değil, itiraz edilemeyen olandır. "Kullanıcı memnuniyeti arttı" tartışmaya açıktır; kimin, neye göre, hangi soruyla. Buna karşılık "kayıt formundaki doğrulama hatası oranı şu tarihten sonra şu seviyeye indi, aynı dönemde bu form hakkında açılan destek talebi de azaldı" cümlesi ya doğrudur ya değildir. Tartışılacak tarafı yoktur, sadece kontrol edilir.
Bunun ön şartı can sıkıcı: değişikliği yapmadan önce ölçümü kurmuş olmanız gerekir. Sonradan toplanan veri karşılaştırma noktası olmadığı için hikayeye dönüşür ve hikaye bütçe toplantısında yaşamaz.
Kaynak azsa kapsam daralsın, tur sayısı değil
Hızlı teslim baskısı altında UX'ten ilk kesilen şey genelde ikinci tur oluyor. Ters karar. Bir kez test edip bulguları düzeltmeden geçmek, hiç test etmemekten yalnızca biraz daha iyidir; asıl kazanç düzelt-tekrar test et döngüsündedir. Sıkışmışsanız üç ekranı bir kez test etmek yerine bir ekranı iki kez test edin.
- Kullanıcının en çok döküldüğü tek akışı seçin
- Değişiklikten önce mevcut oranı kaydedin
- Düzeltin, aynı ölçümü tekrarlayın
- Sonucu, iyi çıkmasa da paylaşın
Son madde en zoru ve en çok işe yarayanı. Kötü sonucu da paylaşan ekip, iyi sonucu paylaştığında inanılıyor.
Olgunluk modeli bir rapor aracıdır, plan değil
UX olgunluk modelleri kurumun nerede durduğunu anlatmakta işe yarar. Ekiplerin çoğu ise onu yol haritası sanıp seviye tartışmasına saplanıyor. Seviyenin kendisi kimseye ne yapacağını söylemez. Yılda bir kez, geçen yılla karşılaştırmak için kullanın, ondan sonra kaldırıp işe dönün.
Tasarım sistemi ne zaman kendini öder
Tekrar kullanılabilir bileşen fikri doğru ama bedava değil. Kaba bir eşik: aynı bileşeni üçüncü kez kopyalıyorsanız kütüphaneye taşımanın vakti gelmiştir, daha öncesinde kurulan sistem çoğunlukla iki ekran için yazılmış fazladan bir katman olarak kalır.
Kütüphanenin asıl maliyeti kuruluşta da değil, bakımında ortaya çıkar. Sürüm yükseltmesini üstlenen bir sahip yoksa ekipler kendi kopyalarını çatallar ve sonunda iki maliyet birden ödenir: hem sistemin bakımı, hem de sistemden sapmış kopyaların düzeltilmesi. Tasarım sistemi kararı vermeden önce sorulacak soru "tutarlılık ister miyiz" değil, "buna kim bakacak" sorusudur.