Konu Başlıkları
Yükleniyor...

Journey-Centric Design: Pilot Yolculuk, Sahiplik ve Ölçüm

Yolculuk Odaklı Tasarım: Kimlik Birleştirme Olmadan Analitik Çalışmaz

Yolculuk odaklı tasarım, ekibin odağını tek bir ekrandan kullanıcının markayla kurduğu bütün temas zincirine kaydırmak demek. Kulağa strateji gibi geliyor, işin büyük kısmı ise operasyon: hangi adımın sahibi kim, sayılar nereden geliyor, iki farklı sistemdeki aynı kişiyi birleştirebiliyor musunuz. Geçişi deneyen ekiplerin çoğu haritayı çizmekte değil, haritanın altındaki veriyi toplamakta takılıyor.

Ürün ekibinin göremediği yer

Her ekip kendi ekranının hunisine bakar ve o huni genelde iyi görünür. Sorun ekranların arasında çıkar. Siparişi web'den veren, iptali çağrı merkezinden isteyen, paranın nerede olduğunu mobil uygulamada arayan bir kişi düşünün: üç ekibin de panosu yeşil, kişinin yaşadığı deneyim berbat. Yolculuk odaklı tasarımın tek iddiası bu boşluğu görünür kılmak.

Organizasyondaki karşılığı şu: birinin, kendi ürünü olmayan adımlar hakkında da konuşma hakkı olması.

Tek bir yolculukla başlayın

Bütün yolculukları birden haritalamaya kalkan ekipler üç ay sonra duvarda kimsenin bakmadığı bir şema bırakıyor. Hacmi yüksek ve şikayeti bol tek bir yolculuk seçin: iade, abonelik iptali, şifre sıfırlama gibi.

Pilotun çıktısı şema değil, şu üçü olmalı:

  • Adım adım temas noktaları ve her adımın hangi sistemde koştuğu.
  • Her adımın sahibi. Ekip adı değil, kişi adı.
  • Her adımın bugünkü sayısı: kaç kişi giriyor, kaç kişi orada bırakıyor, adım ortalama ne kadar sürüyor.

Üçüncüsü çoğu ekipte eksik çıkar. Pilotun asıl değeri de oradadır.

Yolculuğu birleştiremiyorsanız yolculuk analitiği de yok

"Kullanıcının tüm temas noktalarındaki izini analiz edin" tavsiyesi, o izlerin aynı kişiye ait olduğunu zaten bildiğinizi varsayar. Pratikte web tarafında anonim bir çerez kimliği, mobilde oturum açmış bir kullanıcı kimliği, çağrı merkezinde telefon numarası durur. Ortak bir anahtar yoksa elinizdeki şey tek bir yolculuk değil, üst üste konmuş üç ayrı huni olur, ve o üç huninin toplamı size yolculuk hakkında hiçbir şey söylemez.

Bu eşleştirmeyi genelde oturum açma anında anonim kimliği kullanıcı kaydına yazıp geçmiş olayları geri doldurarak çözerim. Müşteri veri platformu satın almadan önce denemeye değer, çünkü çoğu kurulumda bir alan ve bir arka plan işi yetiyor. Dikkat edilecek yer aynı cihazı paylaşan iki kişi: geri doldurmayı oturum açma anından geriye bir iki günle sınırlarsanız yanlış eşleşme oranı ciddi biçimde düşer.

Sahiplik olmayınca yolculuk bir posterdir

Çapraz fonksiyonel ekip kurmak tek başına bir şey çözmüyor. Haftada bir toplanıp durum konuşan komite ile yolculuğun sayısından sorumlu tutulan tek bir kişi arasında fark var, ve ikincisi işe yarıyor. O kişinin ürün ekiplerinin iş sırasına adım ekleyebilmesi gerekir; yetki verilmezse elindeki tek araç rica olur.

Kişiselleştirme sırada değil

Yolculuğu yapay zekayla dinamik olarak optimize etme fikri cazip, fakat model yalnızca beslendiği veriyi tanır. Kimlik birleştirmesi çalışmıyorsa sistem aynı kişiyi iki ayrı kullanıcı sanır, üstelik bunu kendinden emin şekilde yapar. Ölçüm düzgün kurulduktan sonra kişiselleştirme birkaç aylık bir iş; öncesinde pahalı bir tahmin makinesi.

Pilotu üç ay sonra aynı metriklerle tekrar ölçün. Sayılar kıpırdamadıysa sorun büyük ihtimalle yaklaşımda değil, yolculuğun sahibine gerçekten yetki verilmemiş olmasındadır.