30 saniyelik özet
User Story Mapping, kullanıcı hikâyelerini kullanıcının yapmak istediği işin akışı içinde düzenleme yöntemidir. Türkçede kullanıcı hikâyesi haritalama olarak ifade edilebilir. Harita, temel faaliyetleri ve bunların altında daha ayrıntılı ihtiyaçları gösterir. Amaç, tek tek özelliklerin yanında bütün deneyimi görebilmektir. İlk sürüm için seçilen işler, hedef kullanıcıya anlamlı bir görevi tamamlatabilmelidir. Her aşamayı aynı ayrıntıda geliştirmek gerekmez; kapsam, belirli kullanıcı ve kullanım koşulları için daraltılabilir. Harita bir kapasite hesabı veya teslimat garantisi değildir. İhtiyaç kanıtı, teknik bağımlılıklar ve değerlendirme planıyla birlikte kullanıldığında ürün kararlarını destekler.
Neden önemli?
Bir danışmanlık pazar yerinde ekip gelişmiş uzman profillerini, arama filtrelerini ve kayıt ekranını tamamlıyor. Ancak müşteri seçtiği uzmanla görüşme başlatamıyor. En üst sıradaki maddeler teslim edilmiş olsa da kullanıcının temel işi yarım kalıyor.
Düz bir iş listesi sıralamayı gösterebilir; maddelerin birlikte nasıl bir deneyim oluşturduğunu ayrıca açıklamak gerekir. Kullanıcı ihtiyacını tanımlamak, uygun kişiyi değerlendirmek ve onunla iletişime geçmek farklı kartlarda tutulduğunda aradaki boşluklar kolayca gözden kaçabilir.
Story mapping bu boşlukları konuşmayı kolaylaştırır. Hangi adım kullanıcı için zorunlu? Nerede başka bir kişiden bilgi gerekiyor? Bir aşama tamamlanmadan sonraki aşama yapılabiliyor mu? Ekip bu soruları bütün akışı görerek değerlendirebilir.
Yönetici açısından yöntem, kapsam seçimlerinin sonucunu anlamaya yardımcı olur. Gelişmiş bir filtre ertelenebilir; fakat kullanıcı hiçbir aday bulamıyorsa ilk deneyim çalışmayabilir. Bütçe daraldığında her bölümden rastgele özellik çıkarmak yerine, hangi kullanım senaryosunun korunacağı kararlaştırılabilir.
Harita aynı zamanda ekipler arasındaki farklı bakışları görünür kılar. Satış temsilcisi müşterinin anlaşmaya ulaşmasını, tasarımcı seçenekleri değerlendirmesini, geliştirici veri erişimini düşünüyor olabilir. Ortak akış üzerinde konuşmak, her katkının hangi kullanıcı görevini desteklediğini açıklamaya alan açar. Ancak bu ortak anlatının gerçek kullanıcı davranışıyla karşılaştırılması da gerekir.
Terim nedir?
Jeff Patton’ın Story Mapping rehberinde haritanın yatay yönü, kullanıcının hikâyesini anlatacağımız akışa göre düzenlenir. Üst düzey faaliyetler ve görevler backbone, yani omurga olarak adlandırılan yapıyı oluşturur. Daha küçük görevler, ayrıntılar ve farklı kullanım biçimleri bu omurganın altında yer alır.
Release slice, yani sürüm dilimi, belirli kullanıcıların hedeflerine ulaşmasını sağlayan işlerin birlikte seçilmesidir. Harita üzerinde farklı sürümler veya küçük deneyler için bu dilimler oluşturulabilir. Her dilimin hangi sonucu amaçladığı ayrıca açıklanır.
Yöntem kaynağı: Jeff Patton, Story Mapping Quick Reference.
Haritada soldan sağa diziliş, geliştirme işlerinin kesin sırası olarak okunmamalıdır. Kullanıcı bir adımı önce yapıyor diye ekip mutlaka o adımın yazılımını önce geliştirecek değildir. Teknik bağımlılıklar ve öğrenilmesi gereken riskler uygulama sırasını etkileyebilir.
User story, yani kullanıcı hikâyesi, bir ihtiyacı kullanıcı açısından ifade eden kısa iş maddesidir. Product Backlog ise ürün için gereken işlerin sıralı listesidir. Harita bu maddelere kullanım bağlamı kazandırabilir. Kullanılan araçta harita ile iş kayıtları arasındaki bağlantı korunmalıdır; aynı işin farklı yerlerde farklı durumlarla görünmesi kararları zorlaştırır.
Story map ile müşteri yolculuğu haritası arasında da kullanım amacı farkı olabilir. Müşteri yolculuğu araştırması ürün dışındaki temasları ve deneyimleri de ayrıntılı inceleyebilir. Story mapping çalışmasında bu bilgilerden yararlanarak hangi ürün ihtiyaçlarının birlikte ele alınacağı ve sürüm kapsamının nasıl bölüneceği tartışılır.
Gerçek vaka: Twitter’da geliştirici deneyimini ortaklaştırmak
Atlassian’ın 23 Mayıs 2016 tarihli yazısında Nick Muldoon, Twitter’da ürün sahibi olarak çalışırken ekip üyelerinin ve kurum içindeki paydaşların neyi, neden geliştirdikleri konusunda aynı anlayışa sahip olmasının önemini anlatıyor. Geliştirici deneyimi üzerinde çalışırken vizyonu açıklamak, destek almak ve odağı korumak için story mapping kullandıklarını belirtiyor.
Muldoon, daha önce kullandığı düz backlog’un özellikleri sıraladığını, ancak müşterinin yolculuğunu veya ulaşmaya çalıştığı amacı açıklamadığını söylüyor. Haritalama yaklaşımında temel faaliyetler omurga üzerine yerleştiriliyor ve ilgili hikâyeler bunların altında düzenleniyor. Ardından sürüm kapsamları yatay dilimler halinde ele alınıyor.
Bu, çalışmada yer alan kişinin deneyim aktarımıdır. Yazı uygulanan yöntemi açıklıyor; Twitter’daki teslimat süresi veya kullanıcı davranışı üzerindeki etki için sayısal karşılaştırma sunmuyor. Haritalamanın bütün ekiplerde aynı sonucu sağlayacağı çıkarılamaz.
Vakadan çıkarılabilecek ders, tekil iş maddelerinin daha büyük kullanıcı amacı içinde tartışılmasıdır. Haritanın katkısı, kartları farklı bir biçimde dizmekten çok bu ortak konuşmayı desteklemesinde aranmalıdır.
Varsayımsal örnek: İlk danışmanlık görüşmesine ulaşmak
Bir pazar yeri, şirketlerin uygun danışmanla ilk görüşmelerini başlatmasını kolaylaştırmak istiyor. Product Owner, yani ürün sahibi, ekiple birlikte belirli bir kullanıcı grubunu seçiyor: İhtiyacını bilen fakat uygun uzmanı bulmakta zorlanan şirket temsilcileri.
Temel akış, ihtiyacı belirtme, uzmanları değerlendirme, uygunluğu kontrol etme, görüşme isteme ve talebin durumunu öğrenme faaliyetleriyle anlatılıyor. Her faaliyet altında ilgili ihtiyaçlar toplanıyor. Değerlendirme aşamasında temel uzmanlık bilgisi, proje örnekleri ve gelişmiş filtreler; görüşme aşamasında talep iletme ve uygun zaman belirleme seçenekleri bulunuyor.
İlk sürümün hedefi bütün danışmanlık sürecini yönetmek olarak belirlenmiyor. Kullanıcının uygun bir adayla ilk görüşmesini kararlaştırabilmesi yeterli kapsam olarak ele alınıyor. Bu nedenle sözleşme ve iş takibi daha sonraki değerlendirmelere bırakılabilir; ilk sürümde görüşme sürecinin tamamlanması korunur.
Ekip gelişmiş filtreleri erteleyip temel arama, anlaşılır uzman profili, görüşme talebi ve talep durumunu birlikte sunmayı değerlendiriyor. Uzman tarafında talebin alınması ve cevaplanması da haritada görünür tutuluyor. Yalnızca müşterinin ekranları tamamlanırsa deneyimin çalışmayacağı fark ediliyor.
Bazı adımlar başlangıçta operasyon ekibinin desteğiyle yürütülecekse bu geçici yöntemin sorumlusu, kapasitesi ve kullanıcıya etkisi açıklanıyor. Manuel çalışmanın varlığı gizlenmiyor; ilk deneyimi destekleyip destekleyemeyeceği değerlendiriliyor.
Deneme sonrasında sadece tamamlanan ekranlar sayılmıyor. Kullanıcıların aday bulup bulamadığı, taleplerin cevapsız kalıp kalmadığı ve ilk görüşmeye ulaşmada hangi engellerin sürdüğü inceleniyor. Başlangıç verisi görülmeden artış oranı yazılmıyor. Öğrenilenler haritaya ve sıradaki işlere yansıtılıyor.
Yaygın üç hata
- Haritayı ekran başlıklarından oluşturmak
“Profil ekranı, arama ekranı, mesaj ekranı” sıralaması kullanıcının amacını açıklamayabilir. Faaliyetleri kullanıcının yaptığı işler üzerinden anlatın. Ekranları çözüm ayrıntısı olarak ilişkilendirin; mevcut tasarımı ihtiyaç haritası gibi kabul etmeyin.
- İlk sürümü yalnızca bir bölümü parlatacak şekilde seçmek
Aramanın bütün seçeneklerini geliştirirken iletişim adımını eksik bırakmak, hedef görevi engelleyebilir. Sürüm dilimini belirli kullanıcı ve senaryo üzerinden değerlendirin. Her sütundan mekanik olarak kart seçmek yerine görevin gerçekten tamamlanabildiğini kontrol edin.
- Haritayı değişmeyen plan saymak
Araştırma veya kullanım verileri akışın yanlış olduğunu gösterebilir. Yeni ihtiyaçları, geçersiz varsayımları ve değişen kapsamı kayda yansıtın. Harita ile uygulanan işler arasındaki bağlantıyı düzenli gözden geçirin.
Mini uygulama / şablon
Yaklaşan bir ürün çalışması için aşağıdaki alanları doldurun.
- Hedef kullanıcı ve kullanım koşulu
- —
- Tamamlamak istediği iş
- —
- Akışı destekleyen araştırma kanıtı
- —
- Temel faaliyetler ve sıraları
- —
- Her faaliyetin altındaki ihtiyaçlar
- —
- Eksik bilgi ve istisnalar
- —
- İlk sürümde korunacak senaryo
- —
- Ertelenecek seçenekler ve gerekçeleri
- —
- Teknik ve operasyonel bağımlılıklar
- —
- Geçici yöntemler ve sorumluları
- —
- Beklenen kullanıcı sonucu
- —
- Değerlendirme zamanı ve veri kaynağı
- —
Ardından ilk sürümü kullanıcının gözünden anlatın. Bir adımın çıktısı sonraki adım için yeterli mi? Başka bir kişinin katkısı gerekiyor mu? Kullanıcı nerede duruyor? Cevaplar netleşmeden haritadaki dilimi teslimat taahhüdüne dönüştürmeyin.
İlgili terimler
User Story, Product Backlog, Customer Journey, Product Goal, Minimum Viable Product, Release Planning, Acceptance Criteria, Product Discovery, Backlog Refinement, Dependency Management, Product Roadmap, Outcome ve Output