Kullanıcı Hikâyesi Haritalama (Story Mapping) Nasıl Yapılır?

Story map nedir, düz bir backlog'dan farkı ne?

Story map, ürünün kullanıcı gözünden akışını yatay eksende, her adımın altındaki detay hikâyeleri dikey eksende gösteren iki boyutlu bir haritadır. Düz bir backlog yalnızca öncelik sırasını gösterir; story map ise hikâyelerin hangi kullanıcı hedefine ve hangi adıma hizmet ettiğini de görünür kılar.

Bu fark pratikte önemlidir. Düz bir listede iki yüz madde olduğunda ürünün bütününü kavramak zorlaşır, eksik bir adım fark edilmeden kalabilir. Harita ise bütünü tek bakışta gösterir: baştan sona bir kullanıcı akışı var mı, hangi adım zayıf, ilk sürümde hangi dilim yeterli?

Yöntem, kullanıcı hikâyelerini tek tek yazmaktan önce ortak bir resim oluşturmayı amaçlar. Ekip, aynı hikâyeyi farklı kafalarla okumak yerine aynı haritanın önünde konuşur.

Haritanın iskeleti: aktivite, adım ve hikâye

Haritanın üst katmanı kullanıcı aktiviteleridir. Bunlar kullanıcının ürünle yapmak istediği büyük işlerdir. Örneğin çevrim içi bir kitap mağazasında kitap bulmak, satın almak ve teslimatı takip etmek.

Her aktivitenin altına sırasıyla yapılan adımlar eklenir. Kitap bulmak için arama yapmak, kategori gezmek ya da öneri incelemek gibi. Yatay eksen böylece zaman sırasına göre okunur ve ürünün omurgasını oluşturur.

En alt katman, her adımı gerçekleştirmek için gereken kullanıcı hikâyeleridir. Aynı adım altında farklı ayrıntı düzeylerinde birçok hikâye olabilir. Dikey eksende üstte en gerekli, altta isteğe bağlı olanlar yer alır. Bu düzen, bir adımın basit bir sürümüyle zengin sürümünü aynı kolonda karşılaştırmayı mümkün kılar.

Kullanıcı tipleri farklı akışlar izliyorsa her tip için ayrı bir harita ya da haritada ayrı renkli notlar kullanmak karışıklığı önler. Örneğin kitap mağazasında satın alan müşteri ile iade talep eden müşteri aynı adımları izlemez. Haritanın ilk işi bu farkı görünür kılmaktır.

Adım adım: story map workshop'u nasıl yürütülür?

Workshop'a ürün sahibi, tasarım, geliştirme, test ve iş tarafından kişiler katılmalıdır. Gerekli malzeme bir duvar ya da dijital beyaz tahta ve yapışkan notlardır.

• Hedef belirleyin: hangi kullanıcı, hangi sorunu çözmek için ürünü kullanıyor?
• Hikâyeyi anlatın: katılımcılar kullanıcının baştan sona yolculuğunu sırayla, yüksek sesle anlatır ve her adımı not olarak yazar.
• Notları yatay sıraya dizin ve tekrarları birleştirin; gruplayıp aktivite başlıkları altında toplayın.
• Eksikleri bulun: sırayı yeniden okuyun, atlanan adım var mı diye sorun.
• Detayları ekleyin: her adım için alternatif yollar, istisnalar ve gereksinimler dikey olarak eklenir.
• Dikey öncelik verin: her kolonda en vazgeçilmez olanı üste taşıyın.

Oturumun çıktısı mükemmel bir hikâye listesi değil, ekibin paylaştığı ortak bir anlayıştır. Hikâyelerin ayrıntılı kabul ölçütleri sonradan, geliştirmeye yaklaştıkça yazılır.

Haritadan MVP ve sürüm dilimleri nasıl çıkarılır?

Harita hazır olduğunda yatay bir çizgiyle dilimlenir. En üstteki dilim, baştan sona çalışan en küçük kullanıcı akışını içerir. Buna yürüyen iskelet denir: her aktivitenin en basit sürümü bir araya gelir ve kullanıcı ürünü uçtan uca kullanabilir.

İlk dilimi tanımlarken şu soruya bakılır: bu kısmı çıkardığımızda kullanıcı hedefine ulaşabilir mi? Ulaşamıyorsa o hikâye dilimde kalmalıdır. Ulaşabiliyorsa sonraki dilime ertelenebilir.

Sonraki dilimler hedeflere göre kurgulanır. Örneğin ikinci dilim hızı artıran özellikleri, üçüncü dilim kişiselleştirmeyi içerebilir. Bu yaklaşım, ekibe 'tüm özellikler hazır olmadan yayın olmaz' yerine her dilimde kullanıcıya gerçek değer veren küçük sürümler planlama imkânı verir. MVP de bu şekilde bir özellik yığını değil, test edilebilir bir kullanıcı akışı olarak tanımlanır.

Dilimleri belirlerken risk de hesaba katılır. Belirsizliği yüksek bir hikâye erken dilimde küçük bir deneyle sınanırsa, ekip pahalı bir yatırımdan önce öğrenme fırsatı yakalar.

Kullanıcı senaryolarını nasıl yazarsınız?

Haritadaki bir hikâye geliştirmeye yaklaştığında senaryolara dönüştürülür. Hikâye genellikle 'bir kullanıcı olarak, şunu yapmak istiyorum, çünkü şunu elde etmek istiyorum' kalıbıyla yazılır. Senaryo ise bu hikâyenin hangi koşullarda nasıl çalışacağını somut örneklerle anlatır.

İyi bir senaryo şu unsurları taşır: • Başlangıç koşulu: kullanıcı hangi durumda? • Eylem: kullanıcı ne yapıyor? • Beklenen sonuç: sistem nasıl yanıt veriyor? • Alternatif ve hata durumları: eksik bilgi girilirse ne olur?

Haritadaki konum senaryonun bağlamını verir. Bir hikâyeyi tek başına okumak yerine, hangi adımda ve hangi kullanıcı hedefi içinde geçtiğini görmek yazımı ve testi kolaylaştırır. Ekip kabul ölçütlerini haritanın yanında paylaşırsa geliştirme sırasındaki yanlış anlaşılmalar azalır.

Sık yapılan hatalar ve haritayı canlı tutmak

Tipik bir hata, haritayı tek seferlik bir toplantı çıktısı olarak bırakmaktır. Ürün öğrenildikçe harita güncellenmelidir. Dilimleri her sürümden sonra gözden geçirmek ve yeni bulguları haritaya eklemek haritayı canlı tutar.

Diğer sık hatalar: • Kullanıcı yolculuğu yerine sistem özelliklerini sıralamak • Aşırı ayrıntıya erken girmek ve ilk günde her hikâyeyi bitirmeye çalışmak • Yalnızca tek bir rolün katılımıyla yürütmek; geliştirme, tasarım ve iş birlikte olmalıdır • Kullanıcıyı belirsiz bırakmak; farklı kullanıcı tipleri için ayrı haritalar gerekebilir • Dilimleri özellik sayısına göre değil, kullanıcıya sağladığı değere göre kurmamak

Dijital araçlar uzak ekipler için kullanışlıdır; fiziksel duvar ise ortak konuşmayı hızlandırır. Hangisini seçerseniz seçin, haritanın herkesin göreceği bir yerde durması ve düzenli güncellenmesi gerekir.

Mindset programlarında nerede çalışırsınız?

Mindset'in Story Mapping ve Kullanıcı Senaryoları eğitiminde konu şu başlıklarla ilerler: Story Map Nedir ve Neden Gereklidir, Kullanıcı Yolculuğu Haritası, Story Map Workshop Yürütme, Kullanıcı Senaryoları Yazımı, MVP Tanımı ve Sürüm Planlama ile Dijital Araçlar ve Sürdürülebilirlik.

Workshop yürütme ve MVP planlama başlıkları, yukarıdaki adımları uygulamalı olarak çalışmak isteyenler için doğrudan ilgilidir.