UX Yol Haritasına Ne Konur, Ne Konmaz

UX yol haritası, ekibin önümüzdeki aylarda hangi kullanıcı problemlerine bakacağını gösteren tek sayfalık bir belge. Özellik listesi değil problem listesi olduğu için teslim tarihi değil öncelik taşır. İşe yarayanı, paydaşın 'bu ne zaman biter' sorusunu 'bunu neden şimdi yapıyoruz' sorusuna çevirir.

Belgede ne durur

Dört şey yeter: sahibi ve son güncelleme tarihi, ulaşılmak istenen sonuç, üç zaman ufku, ufuklara dağılmış temalar. Bir tema satırı üç bilgi taşır: hangi kullanıcı grubunun hangi sorunu, çözülürse hangi ölçüt değişecek, işi kim üstleniyor.

Bunun dışında kalan her şey başka bir belgenin işi. Ekran akışı tasarım dosyasında, görev kırılımı backlog'da, tarih release planında durur. Yol haritasına ekran adı yazmaya başladığınız an belge stratejik olmaktan çıkıp bakım isteyen bir tabloya dönüşür.

Tarih değil ufuk yazın

Şimdi, Sonra, İleride. Üç sütun çoğu ekip için yeterli, çeyrek başlıkları yazmayın. Tarihi yazdığınız anda yol haritası bir taahhüt belgesi olur ve ilk kaymada paydaşın gözünde güvenilirliğini kaybeder; oysa aynı belge ufukla yazıldığında sıra değişikliği bir gecikme değil, bir öncelik kararı olarak okunur.

Sütunlar arası geçiş kuralını da yazın. Bir tema Sonra'dan Şimdi'ye ne zaman geçer: araştırma bulgusu geldiğinde mi, kapasite açıldığında mı? Bu kural yoksa sıralama toplantıda en yüksek sesle konuşana göre belirlenir.

Uzak sütun araştırmaya dayanamaz

Yol haritasının kullanıcı araştırmasına dayanması gerektiği doğru, ama bu kural her sütunda aynı ölçüde işlemez. Altı ay ötesine koyduğunuz bir temayı bugünkü görüşmelerle gerekçelendiriyorsanız, iş sıraya geldiğinde o gerekçe eskimiş olacak. Kullanıcı da ürün de rakip de o aralıkta değişir.

Pratik çözüm ucuz: her temanın yanına arkasındaki kanıtı tek kelimeyle yazın. Görüşme, log, destek talebi, varsayım. İleride sütunundaki satırların çoğunun karşısında 'varsayım' yazacak, olması gereken de bu. Bulgu gibi sunulan varsayım, yanlış çıktığında bütün belgenin itibarını götürür.

Roadmap, backlog, release planı

Roadmap neyi çözeceğinizi söyler, release planı neyi ne zaman teslim edeceğinizi, backlog bunun hangi işlere bölündüğünü. Üçünü tek dosyada birleştirme çabası genelde roadmap'i öldürür, çünkü detay girdikçe belge her hafta güncelleme ister ve kimse güncellemez. Paydaş toplantısında roadmap'i açın, sprint planlamasında backlog'u.

Yolculuk haritasıyla karıştırılması ayrı bir konu. Journey map kullanıcının bugün ne yaşadığını gösterir, roadmap ekibin bunu düzeltmek için ne yapacağını. Biri teşhis, diğeri tedavi planı; teşhis olmadan yazılan yol haritası genelde şirketin istek listesi çıkar.

Canlı tutmanın maliyeti

'Yaşayan doküman' cümlesi bedava değil. Güncelleme ritmi tanımlanmazsa belge üç ay içinde açılmaz olur. Ayda bir, yarım saat, tek sahip: biteni kaldırın, kanıtı değişeni taşıyın, artık kimsenin savunmadığı satırı silin.

Bir de teknik maliyeti not edin. Temanın arka uçta veri modeli değişikliği gerektirip gerektirmediği, yol haritasının sırasını çoğu tasarım tartışmasından daha fazla belirler. Arayüzde iki günlük görünen bir iyileştirme, tabloya yeni bir alan ve geçmiş kayıtların taşınması demekse o iş Şimdi sütununa değil Sonra'ya aittir. Bunu tasarım ve geliştirme birlikte işaretlemezse plan ilk sprintte kayar.