UX Hikayeleri: Bulguyu Anlatıya Çevirmenin Pratik Yolu

Bir araştırma raporunu kimse ikinci kez açmaz; aynı bulgu bir kullanıcının başından geçen olay olarak anlatıldığında ekipte haftalarca dolaşır. UX hikayesi bu farkı kullanmanın yolu. Riski de tam aynı yerde: hikaye, ölçmenin yerine geçtiği anda tasarımı yanlış tarafa çeker.

Hikaye, senaryo ve user story ayrı işler görür

Üçü birbirine karışıyor, sonra toplantıda herkes başka bir şeyden bahsediyor. User story bir gereksinim formatıdır, backlog'a girer. Senaryo adım listesidir, akışı doğrular. Storyboard kareleriyle sırayı gösterir. UX hikayesi ise tek bir karakteri, onun o an ne yapmaya çalıştığını ve önüne çıkan engeli anlatır; işe yaraması da karakterin gerçek bir görüşmeden gelmesine bağlı.

Bulguyu hikayeye çevirmenin kısa yolu

Görüşme notları elinizde varsayalım. Sıra şöyle:

1. Tek bir kullanıcı seçin. Birleştirilmiş persona değil, kaydı olan gerçek bir kişi.
2. Hedefini tek cümleyle yazın, ürünle ilgili olmasın: faturayı muhasebeciye yetiştirmek gibi.
3. Engeli yaşandığı yerde gösterin: hangi ekran, hangi cihaz, günün hangi saati, yanında kim vardı.
4. Sonu değiştirmeyin. Kullanıcı vazgeçtiyse hikaye vazgeçerek biter.
5. İçgörüyü sona bırakın; anlatının içine yorum sıkıştırmayın.

Bir ödeme akışında kart formunu yarıda bırakan kullanıcıları dinledikten sonra sorunun alan sayısı değil, klavye açılınca sipariş toplamının ekrandan çıkması olduğunu gördüm.

Hikayenin ölçekle imtihanı

Hikaye bir kişiyi anlatır, arayüz kararı ise o ekrana gelen herkesi etkiler. Anlatım gücü burada çoğu zaman ters çalışır: canlı anlatılmış nadir bir aksilik, kimsenin heyecanlanmadığı ama binlerce oturumun her gün geçtiği yoldan daha çok bütçe çeker.

Çaresi ucuz. Her hikayenin yanına o yolun kayıtlardaki sıklığını yazın: kaç oturum o ekrana geldi, kaçı bir sonraki adıma geçti. Sıklık bilinmiyorsa elinizdeki şey bulgu değil hipotezdir, öyle sunun. Hikayenin ikna ediciliği, temsil ettiği kullanıcı sayısıyla hiçbir şekilde orantılı değil.

Bir de maliyet sütunu

Toplantıda alkış alan çözüm, veri modelinde aynı alanın iki ayrı serviste tutulmasını gerektiriyorsa o tasarım kararı sprint'e sığmaz. Hikayeyi sunarken yanına iki satır koyun: bu değişiklik hangi ekranlara, hangi tablolara dokunuyor. Geliştiricinin sonradan soracağı soruyu önceden cevaplamak, hikayenin masada kalma süresini uzatan en pratik hamle.

Aynı hikayeyi tasarımdan sonra tekrar anlatın

Hikayenin en az kullanılan işlevi bu. Değişiklik yayına çıktıktan sonra aynı karakteri aynı hedefle yola çıkarın: engel kalktı mı, yoksa yer mi değiştirdi? Neyin düzeldiğini sayılar söyler, ama hangi sayıya bakacağınızı hikaye söyler. Bu ikisini birbirinin yerine koymadığınız sürece hikaye anlatımı elinizdeki en ucuz araçlardan biri.