İçeriğe geç
DigiRise
Projenizi konuşalım

Yeni Bir Dijital Ürün İçin Kullanıcı Araştırması Nasıl Yapılır?

Ürün Geliştirme3 dk okuma

Yeni dijital ürün için kullanıcı araştırmasının amacı insanlara fikrinizi beğenip beğenmediklerini sormak değildir. Kullanıcının bugün hangi işi yapmaya çalıştığını, bunu nasıl çözdüğünü, nerede zorlandığını ve önerdiğiniz çözümün hangi varsayımlarının test edilmesi gerektiğini anlamaktır.

GOV.UK Service Manual, araştırmaya ekip varsayımlarını araştırma sorularına dönüştürerek başlamayı ve yöntemleri bu sorulara göre seçmeyi önerir. GOV.UK: Plan user research

Varsayımları araştırma sorusuna çevirin

Zayıf varsayım:

Küçük işletmeler stok uygulaması ister.

Araştırma sorusu:

Küçük işletmeler bugün stoklarını nasıl takip ediyor ve hangi durumda mevcut yöntemleri yetersiz kalıyor?

İkinci ifade kullanıcıya sonucu söylemez ve mevcut davranışı anlamaya odaklanır.

Başlangıçta şu başlıklarda varsayımlar çıkarılabilir:

  • Kullanıcı kim?
  • Problem ne?
  • Problem ne sıklıkta yaşanıyor?
  • Bugün nasıl çözülüyor?
  • Mevcut çözümün maliyeti veya zorluğu ne?
  • Yeni çözümü kullanmak için davranış değişikliği gerekiyor mu?

Doğru katılımcıyı seçin

Ürünün hedef kullanıcısı muhasebeciyse yalnızca arkadaşlarınızla konuşmak doğru veri üretmeyebilir.

Katılımcı kriterleri ürünün gerçek kullanımına göre belirlenmelidir.

Örneğin:

Araştırma grubu:
- Son 6 ay içinde en az 20 aktif müşteriyi manuel takip etmiş
- CRM kullanmıyor veya temel bir CRM kullanıyor
- Müşteri takibini kendi işi içinde düzenli yapan

Bu kriter örnektir. Gerçek ürün için hedef kullanıcıya göre değiştirilmelidir.

GOV.UK, kullanıcı araştırmasında mevcut veya muhtemel kullanıcılarla çalışmayı ve farklı kullanıcı ihtiyaçlarını kapsayacak katılımcılar seçmeyi önerir. GOV.UK: User research introduction

Görüşmede fikri satmaya çalışmayın

"Bu uygulama olsa kullanır mıydınız?" sorusu genellikle zayıf veri üretir.

Bunun yerine geçmiş davranışa odaklanın:

  • Son kez bu problemi ne zaman yaşadınız?
  • Ne yaptınız?
  • Hangi araçları kullandınız?
  • En uzun süren adım hangisiydi?
  • Hata olduğunda ne yaptınız?
  • Bunun için para ödüyor musunuz?
  • Bugünkü çözümü neden değiştirmediniz?

Derinlemesine görüşmeler, kullanıcıların koşullarını ve ihtiyaçlarını anlamak için kullanılabilir. GOV.UK rehberi de görüşmeleri kullanıcıların yaşamını, işini, mevcut deneyimlerini ve sorunlarını derinleştirmek için önerir. GOV.UK: In-depth interviews

Söylenen ile yapılanı ayırın

Kullanıcı bir özelliği "çok iyi fikir" olarak değerlendirebilir ancak gerçek hayatta bu probleme zaman veya para ayırmıyor olabilir.

Bu nedenle araştırmada:

  • Geçmiş davranış
  • Mevcut araç
  • Harcanan zaman
  • Mevcut ödeme
  • Oluşan hata
  • İş akışı

gibi somut kanıtları toplamaya çalışın.

Bu, kullanıcı görüşünü değersiz yapmaz. Sadece niyet ile davranışı ayrı veri olarak kaydetmenizi sağlar.

Ne zaman prototip kullanmalı?

Problem keşfi sırasında hiç tasarım göstermemek daha yararlı olabilir. Çünkü erken prototip kullanıcıyı sizin çözümünüze yönlendirebilir.

Çözüm varsayımlarını test etmeye geçtiğinizde ise:

  • Kağıt taslak
  • Figma prototipi
  • Tıklanabilir akış
  • Kod prototipi

kullanılabilir.

GOV.UK prototip rehberi, tasarım fikirlerini üretim koduna geçmeden önce keşfetmek ve kullanıcıyla test etmek için farklı doğruluk seviyelerinde prototipler kullanılabileceğini açıklar. GOV.UK: Making prototypes

Kullanılabilirlik testinde görev verin, yönlendirmeyin

Şöyle demek yerine:

Sol üstteki filtre butonuna basıp tarihi seçin.

şöyle bir görev verin:

Geçen ay oluşturduğunuz siparişleri bulmak istediğinizi düşünün. Nasıl yapardınız?

Moderasyonlu kullanılabilirlik testinde kullanıcıların belirli görevleri tamamlamasını gözlemlemek, anlamadıkları alanları ve kullanılabilirlik sorunlarını tespit etmeye yardımcı olur. GOV.UK: Moderated usability testing

Notları gözlem ve yorum olarak ayırın

Örnek:

Gözlem

Katılımcı "yeni kayıt" butonunu yaklaşık 20 saniye aradı ve önce Ayarlar menüsüne girdi.

Yorum

Ana işlem yeterince görünür olmayabilir.

İlk cümle gözlemdir. İkinci cümle ekip yorumudur. Bunları ayırmak analiz sırasında varsayımı gerçek davranış gibi yazmayı önler.

Kopyalanabilir araştırma planı

ARAŞTIRMA AMACI
Bu tur sonunda hangi kararı vermek istiyoruz?

ARAŞTIRMA SORULARI
1.
2.
3.

TEST EDİLEN VARSAYIMLAR
1.
2.

KATILIMCI KRİTERİ
Kimler:
Kimler değil:

YÖNTEM
[ ] Derinlemesine görüşme
[ ] Gözlem
[ ] Prototip testi
[ ] Moderasyonlu kullanılabilirlik testi
[ ] Anket
[ ] Diğer

OTURUM AKIŞI
Giriş:
Mevcut davranış:
Problem:
Mevcut çözüm:
Varsa prototip görevi:
Kapanış:

TOPLANACAK KANIT
Davranış:
Kullanılan araç:
Sıklık:
Maliyet / zaman:
Hata:
Alıntı:
Gözlem:

KARAR
Hangi bulgu ürünü değiştirmemize neden olur?
Hangi konu için yeni araştırma gerekir?

Araştırma bitince ne yapılmalı?

Görüşme notlarını tek tek "kullanıcı bunu istedi" listesine çevirmeyin.

Bulguları:

  • Tekrarlanan problem
  • Farklı kullanıcı grubu
  • Mevcut davranış
  • İhtiyaç
  • Risk
  • Ürün varsayımı

başlıklarında gruplayın.

Araştırma, tüm kullanıcıların aynı şeyi düşündüğünü kanıtlamak için yapılmaz. Bir ürün kararını daha az varsayımla verebilmek için yapılır.

İlk araştırma turunun sonunda yeni sorular çıkması normaldir. Kullanıcı araştırmasını yalnızca proje başında yapılan tek seferlik bir onay süreci yerine ürün geliştirme boyunca tekrarlanan öğrenme faaliyeti olarak ele almak daha sağlıklıdır.

kullanıcı araştırmasıdijital ürünürün geliştirmeux researchmvp

Benzer bir konuda yardım mı lazım?

Projenizi anlatın, nereden başlayacağımızı birlikte bulalım.

Bize yazın