User Journey ve User Flow: Fark Nerede, Hangisi Ne Zaman
User journey ile user flow'u ayıran şey çoğu yazıda "makro ve mikro" diye geçiştirilir. Ayrım daha keskin: biri senin ürününün dışına taşar, diğeri tamamen içinde kalır. Bu tek fark, haritayı kimin çizeceğini, neyle doğrulanacağını ve ne sıklıkla çöpe gideceğini belirler.
Kapsam farkı, tek cümlede
Journey map bir kişinin bir amaca ulaşana kadar geçtiği tüm temas noktalarını sırayla gösterir: arama motorundan telefon görüşmesine, e-postadan fiziksel ziyarete. Bu noktaların çoğu senin ürününde değil. User flow ise tek bir hedefin ürün içindeki adımlarını gösterir, sepeti tamamlamak ya da profil fotoğrafı değiştirmek gibi. Kullanıcının o anki ruh halini taşımaz, sadece ekran ve sistem tepkisi taşır.
| Journey map | User flow | |
|---|---|---|
| Sınır | Kanallar arası, ürün dışına taşar | Ürün içi, tek görev |
| İçerik | Temas noktası, beklenti, engel | Adım, karar noktası, sistem tepkisi |
| Kaynak | Saha çalışması, günlük çalışması, görüşme | Ekran envanteri, kod, olay kayıtları |
| Tazeleme | Yeni araştırma yapıldığında | Akışı değiştiren her sürümde |
Journey map araştırmasız çizilirse toplantı notudur
Bir hastanın süreci iyi örnek: belirti araması, randevu alma, hatırlatma SMS'i, muayene, sonuç bekleme, portaldan raporu görüntüleme. Bu zincirin sadece iki halkası senin yazılımında. Geri kalanını ancak saha çalışması, günlük tutma çalışmaları ve görüşmelerle öğrenirsin.
Ekibin oturup kendi tahminleriyle doldurduğu journey map, kullanıcıyı değil ekibin varsayımlarını haritalar. Böyle bir harita yanlış olduğunda da sessizce yanlıştır, çünkü onu yanlışlayacak veri hiçbir yerde birikmiyor.
"Tüm olası yolları çiz" tavsiyesi ölçeklenmez
User flow anlatan kaynakların çoğu aynı cümleyi kurar: bütün olası yolları ve karar noktalarını detaylandırın. Sayıya bakınca bu tavsiye kendi kendini yer. Her ikili karar noktası akışı iki dala böler, yani k karar noktası 2 üzeri k uç yol demektir. Beş karar noktası 32 yol, sekiz karar noktası 256 yol eder. Kimse 256 dallı bir şemaya bakmaz.
Beş karar noktalı bir akışı tek diyagramda toplamaya çalışma. Mutlu yolu çiz, en sık görülen iki hata dalını ayrı kutucuklar olarak ekle, gerisini yazıya bırak. Okunmayan şema bakımını da hak etmez, ilk sürümden sonra kimse güncellemez.
Bir kayıt formunun gerçek dal sayısını tahmin etmek yerine sayabilirsin: doğrulama kurallarının sayısı, akıştaki karar noktalarının alt sınırıdır. Zorunlu alan başına en az bir hata dalı vardır ve bunlar şemada yoksa şema ürünü değil, ürünün iyi günündeki halini anlatıyor demektir.
Asıl ayrım: hangisini neyle doğrularsın
User flow doğrulanabilir bir belgedir. Her adımı bir olaya bağlarsın, huni raporunda kaçıncı adımda kaç kişinin düştüğünü görürsün, kullanılabilirlik testinde beş kişiyle aynı akışı yürütürsün. Şema ile gerçeklik ayrıştığında bunu fark edersin.
Journey map için böyle bir mekanizma yok. Ürün analitiği hastanın telefonda ne kadar beklediğini bilmez. Haritanın eskidiğini ancak yeni bir araştırma turu söyler. Bu yüzden ikisini aynı ritimde güncellemeye çalışmak boşa emek: user flow sürüm temposuyla, journey map araştırma temposuyla yaşar.
Pratikte ikisi birlikte
Sıra şöyle işler. Önce journey map ile zincirin neresinde kayıp olduğunu bulursun. Diyelim ki sonuç bekleme ile raporu görüntüleme arasında insanlar çağrı merkezini arıyor. Sonra sadece o halkanın user flow'unu çıkarır, ölçer, düzeltirsin.
Tersi de işler ama daha pahalıdır: elinde düşük tamamlanma oranı olan bir akış varsa, sorunun akışta mı yoksa kullanıcının oraya yanlış beklentiyle gelmesinde mi olduğunu ancak zincirin tamamına bakarak anlarsın. Her iki durumda da haritanın kendisi çıktı değildir. Çıktı, haritanın gösterdiği yerde yapılan değişikliktir.