Persona mı, Jobs-to-Be-Done mu? İkisi Aynı Soruyu Sormuyor
Persona ile jobs-to-be-done aynı toplantıda yan yana anılır ama aynı soruyu sormazlar: biri kullanıcının kim olduğunu, diğeri ne başarmaya çalıştığını anlatır. Fark kulağa ince gelir, pratikte hangi ekranın önce yazılacağına kadar iner. İkisi rakip de değil, birbirinin yerine de geçmez: biri kitleyi ayırır, diğeri kapsamı daraltır.
Biri kimi, diğeri neyi anlatır
Persona, araştırmadan çıkan davranış örüntülerini tek bir kurgusal kişide toplar. İyi bir persona demografiyle değil, kullanıcının neyi nasıl yaptığıyla ilgilenir: hangi adımda vazgeçiyor, hangi bilgiyi nereden bekliyor, hangi hatayı tekrar tekrar yapıyor. "32 yaşında, İstanbul'da yaşıyor, telefonunu sık kullanıyor" cümlesi tek bir tasarım kararını bile değiştirmez.
Jobs-to-be-done kişiyi atlayıp duruma bakar. Kullanıcı bir ürünü sevdiği için değil, belirli bir koşulda belirli bir sonucu elde etmek için işe alır. Soru şuna döner: bu kişi bugün bu ekranı açtığında neyi bitirmeye çalışıyordu ve bitirdiğini nereden anlayacak?
Persona ne zaman rafta kalır
Persona'nın asıl faydası empati değil, önceliklendirme. İki kullanıcı grubunun ihtiyacı birbirini bastırıyorsa persona o çatışmayı masaya görünür biçimde koyar, ekip de hangisinden vazgeçtiğini bilerek vazgeçer.
Bir e-ticaret projesinde üç persona hazırlamıştık; altı ay sonra o dosyayı açan tek kişi ekibe yeni katılan tasarımcı oldu.
Rafta kalmasının sebebi çoğunlukla sayı. Beş altı personaya çıkıldığında hiçbiri karar verecek kadar keskin kalmıyor ve ekip "bunu hangi persona için yapıyoruz" sorusunu sormayı bırakıyor. Peki sayıyı neye göre kısarsın? Davranış farkı üretmeyen her segmenti birleştir: iki persona aynı akışı aynı sırayla kullanıyorsa onlar tek personadır, yaşları ve meslekleri ne olursa olsun.
JTBD'nin sessizce atladığı yer
Kargo şoförü örneği yöntemi iyi anlatır: asıl iş adresleri yazdırmak değil, teslimat rotasında hızlı yol bulmak. Peki bir adım yukarı çıksak? "Günün teslimatlarını zamanında bitirmek." Bir adım daha: "Akşam eve erken dönmek." Üçü de geçerli birer iş tanımı, ama üçü bambaşka ürünler tarif ediyor.
JTBD'nin yöntem olarak söylemediği şey tam burası: işin hangi soyutlama seviyesinde yazılacağı. Dar yazarsan mevcut çözümün kopyasını üretirsin, geniş yazarsan kiminle yarıştığını kaybedersin. İşe yarar bir ölçü var: bir seviye yukarı çıktığında rakip kümen tamamen değişiyorsa fazla yukarı çıkmışsındır. Navigasyon seviyesinde rakip harita uygulamaları; eve erken dönmek seviyesinde rakip vardiya planlaması, ki o senin ürününün çözeceği bir sorun değil.
Empati tartışması abartılıyor
JTBD'nin empatiyi geri plana attığı sıkça söylenir. Yöntemi besleyen şeyin ne olduğuna bakınca bu zor savunulur: JTBD görüşmesi "bunu en son ne zaman yaptınız, o gün tam olarak ne oldu" diye ilerler, yani kullanıcının gününe personadan daha yakından girer. Fark empatinin miktarında değil, nereye yazıldığında. Persona onu bir karakterde saklar, JTBD bir koşul cümlesinde.
Sıra sonucu değiştiriyor
"İkisini birlikte kullanın" tavsiyesi doğru ama eksik, çünkü hangisiyle başladığın çıktıyı değiştirir. Personayla başlayan ekip elinde hazır segmentler varken işi segmente uydurmaya çalışır, sonuçta her persona için ayrı bir özellik listesi çıkar. İşle başlayan ekip ise önce kapsamı daraltır, sonra aynı işi farklı koşullarda yapan kullanıcılar gerçekten ayrışıyorsa persona üretir. Varsayılan sıra bence budur: önce iş, sonra kişi.
İstisnası, kullanıcıları ayıran şeyin işin kendisi değil yetkinlik olduğu durumlar. Aynı raporu çıkaran bir muhasebeci ile bir genel müdürün işi aynıdır, arayüzü aynı olamaz: biri kısayol ve toplu işlem bekler, diğeri tek bir ekranda özet. Orada persona öne geçer, JTBD cümlesi ikisini de aynı kutuya koyduğu için ayrımı kaçırır.