Jobs to be Done (JTBD) Framework: Personaların Ötesinde Gerçek Kullanıcı İhtiyaçlarını Anlamak

Selam arkadaşlar, bu makalede size sıkça kullandığımız personaların bir adım ötesine geçerek kullanıcıyı anlamanın farklı bir yolunu, Jobs to be Done (JTBD) framework'ünü anlatmaya çalışacağım.

Çoğumuz tasarım sürecine başlarken kullanıcılarımızı tanımlamak için personalar oluştururuz. “Ayşe, 32 yaşında, İstanbul'da yaşıyor, pazarlama müdürü...” gibi. Bu bilgiler faydalıdır, evet. Ancak bazen bu demografik veriler, kullanıcının ürünümüzü neden kullanmak istediği sorusuna tam olarak cevap veremez. İşte bu noktada Jobs to be Done, yani “Yapılacak İşler” felsefesi devreye giriyor ve bize bambaşka bir bakış açısı sunuyor.

Jobs to be Done (JTBD) Tam Olarak Nedir?

JTBD, en basit haliyle, kullanıcıların bir ürünü veya hizmeti belirli bir “işi” halletmek için “kiraladıkları” fikrine dayanır. Clayton Christensen'in meşhur milkshake örneğini duymuşsunuzdur. Bir fast-food zinciri, milkshake satışlarını artırmak için her şeyi dener: tadını değiştirir, daha ucuz yapar, daha büyük porsiyonlar sunar. Ama hiçbir şey işe yaramaz. Sonunda müşterileri gözlemlediklerinde şunu fark ederler: İnsanların çoğu sabahları işe giderken uzun ve sıkıcı yolculuklarında kendilerini oyalayacak, tek elle tüketebilecekleri, doyurucu bir şey aradıkları için milkshake “kiralıyorlardı”. Aslında milkshake, bir muz veya bir simitle rekabet ediyordu.

İşte JTBD'nin özü budur: “İnsanlar matkap almak istemez, duvarda bir delik açmak isterler.” Kullanıcının demografik özelliklerinden çok, ulaşmak istediği sonuca, yani halletmek istediği “işe” odaklanırız.

Persona ve JTBD Arasındaki Temel Fark

Bu iki yaklaşım birbirinin düşmanı değil, tamamlayıcısıdır. Ancak aralarında önemli bir fark var:

• Persona: Kullanıcının kim olduğuna odaklanır. Nitelikleri, özellikleri ve davranış kalıplarını inceler. Bize empati kurma konusunda yardımcı olur. Daha önce yazdığım Kullanıcı Personaları ve Empati Haritaları yazısında bu konuyu detaylıca ele almıştım.
• Jobs to be Done: Kullanıcının neden bir şey yaptığını ve hangi ilerlemeyi kaydetmek istediğini anlamaya çalışır. Motivasyon ve bağlamı merkeze alır.

Örneğin, bir proje yönetim aracı tasarlıyorsanız, personanız “Proje Müdürü Pelin” olabilir. JTBD ise Pelin’in “dağınık ekip iletişimini tek bir merkezde toplayarak projelerin zamanında bitmesini sağlama” işine odaklanır. Gördüğünüz gibi, ikincisi bize çok daha net bir problem tanımı sunuyor.

"Job Story" Yazmak: Kullanıcı Hikayelerinin Güçlü Alternatifi

JTBD'nin en pratik çıktılarından biri de “Job Story” (İş Hikayesi) formatıdır. Geleneksel kullanıcı hikayeleri (“Bir kullanıcı olarak... yapmak istiyorum... böylece...”) yerine, Job Story'ler bağlam ve motivasyonu vurgular.

Formatı şöyledir: When _____ [durum], I want to _____ [motivasyon], so I can _____ [beklenen sonuç].

Etkili Bir Job Story Nasıl Yazılır?

İyi bir iş hikayesi, ekibinize net bir yön verir. İşte adımları:

• Durumu (Situation) Anlayın: Kullanıcıyı harekete geçiren tetikleyici nedir? Hangi bağlamda bu ihtiyacı hissediyor? Örnek: “Ekip toplantısından yeni çıktığımda...”
• Motivasyonu (Motivation) Keşfedin: Bu durumda ne yapmak istiyor? Asıl amacı ne? Çözümden bahsetmeyin, hedeften bahsedin. Örnek: “...toplantıda alınan kararları ve görevleri unutmadan ekibe dağıtmak istiyorum...”
• Beklenen Sonucu (Outcome) Belirleyin: Bu işi hallettiğinde hayatında ne daha iyi olacak? Hangi ilerlemeyi kaydedecek? Örnek: “...böylece herkes ne yapması gerektiğini bilir ve proje aksamadan ilerler.”

Tam Örnek: “Ekip toplantısından yeni çıktığımda, toplantıda alınan kararları ve görevleri unutmadan ekibe dağıtmak istiyorum, böylece herkes ne yapması gerektiğini bilir ve proje aksamadan ilerler.”

JTBD Framework'ünü Tasarım Sürecinize Nasıl Entegre Edersiniz?

Peki bu felsefeyi alıp kendi iş akışımıza nasıl dahil edeceğiz? Aslında düşündüğünüzden daha kolay.

1. Kullanıcı Mülakatları ve Gözlem: İşe kullanıcılarınızla konuşarak başlayın. Ancak onlara “Ne istersiniz?” diye sormak yerine, geçmişteki davranışlarını anlamaya çalışın. “En son X ürününü ne zaman aldınız? O gün neler oluyordu? Onu almadan önce ne kullanıyordunuz?” gibi sorular, altta yatan “işi” ortaya çıkarır. Bu süreçte pratik kullanıcı araştırma tekniklerini kullanmak size çok yardımcı olacaktır.
2. "İşleri" Tanımlama ve Gruplama: Mülakatlardan elde ettiğiniz verileri analiz ederek temel “yapılacak işleri” belirleyin. Bu işleri ana işler ve ilgili alt işler olarak gruplandırabilirsiniz.
3. Fırsatları Değerlendirme: Hangi işlerin kullanıcı için önemli olduğunu ama mevcut çözümlerin yetersiz kaldığını belirleyin. İşte sizin inovasyon fırsatınız tam olarak burası.
4. Çözümler Üretme ve Test Etme: Tanımladığınız “işlere” odaklanarak özellikler ve çözümler geliştirin. Bu aşamada, geliştirdiğiniz fikirleri hızlıca hayata geçirmek için prototipleme ve kullanıcı testi yöntemlerinden faydalanabilirsiniz. Ürününüz, kullanıcının işini ne kadar iyi ve verimli yapıyorsa o kadar başarılı olacaktır.

Son Söz

Jobs to be Done, sihirli bir değnek değil. Ancak bize, kullanıcıların karmaşık ve çoğu zaman ifade edemedikleri motivasyonlarını anlamak için güçlü bir mercek sunuyor. Persona oluşturmayı bırakın demiyorum; sadece cephaneliğinize yeni ve çok etkili bir araç ekleyin diyorum. Tasarım yaparken “kullanıcı ne istiyor?” sorusundan “kullanıcı hangi işi halletmeye çalışıyor?” sorusuna geçtiğinizde, ürettiğiniz çözümlerin ne kadar isabetli ve değerli olduğunu göreceksiniz. Unutmayın, insanlar ürünlerinizi sevmek zorunda değil; sadece işlerini görmek zorundalar. Eğer bunu başarırsanız, sevgi zaten arkasından gelecektir.

Umarım yazıyı faydalı bulmuşsunuzdur. Daha detaylı sorularınız için bana Linkedin üzerinden ulaşmaktan çekinmeyin.