Dijital Ürün Fikri Nasıl Doğrulanır? İlk Kullanıcıdan Başlayın

Dijital ürün fikri doğrulama, bir uygulama fikrinin hangi ihtiyaca karşılık geldiğini davranış ve deneylerle araştırmaktır. Amaç, fikre olumlu yorum toplamak kadar, nerede yanlış düşünüldüğünü de görebilmektir. İnsanların bugün ne yaptığını anlamadan yeni bir aracın gerekli olduğuna karar vermek zordur.

“Ekipler için daha iyi bir uygulama” başlangıç fikri olabilir. Ancak kimin, hangi iş sırasında, neyi daha iyi yapacağı henüz belli değildir. İlk çalışma bu cümleyi daraltmak olmalıdır.

Kullanıcıyı bir iş anıyla tanımlayın

“Küçük işletmeler” çok geniş bir gruptur. “Her hafta müşteri onayı bekleyen işleri farklı mesajlaşma kanallarından toplayan ekip sorumluları” daha araştırılabilir bir tanımdır. Belirli bir durum, görüşeceğiniz kişileri ve soracağınız soruları seçmenizi kolaylaştırır.

GOV.UK keşif rehberi, olası kullanıcıların kim olduğunu, ne yapmaya çalıştıklarını, bugün nasıl ilerlediklerini ve hangi engellerle karşılaştıklarını anlamayı önerir. GOV.UK — User research in discovery

Başlangıçta bir sayfalık not yeterlidir. Kullanıcıyı, tekrarlayan işi, yaşanan sorunu ve mevcut çözümü yazın. Bilmediğiniz alanları tahminle doldurmak yerine soru olarak bırakın.

Görüşmelerde geçmiş davranışı sorun

Bir kişiye “Böyle bir uygulama kullanır mıydınız?” dediğinizde, cevap henüz yaşanmamış bir duruma ilişkin tahmindir. Bunun yerine yakın zamanda yaşadığı bir olayı anlatmasını isteyin.

Şu sorular somut ayrıntı üretir:

• Bu işi en son ne zaman yaptınız?
• İlk adımınız neydi, hangi araçları açtınız?
• Hangi noktada başka birinden bilgi beklediniz?
• Yanlış veya eksik bilgi olduğunda ne yaptınız?
• Sonucu nasıl kontrol ettiniz?

Görüşmenin başında ürününüzü uzun uzun anlatmayın. Kişinin anlattığı olayla ilgilenin. “Tam da bunu çözüyoruz” demek yerine, anlamadığınız adımı açmasını isteyin. Birbirinden farklı kullanıcıların farklı sorunları olabilir; hepsini aynı fikre kanıt saymayın.

Mevcut çözümün neden kullanıldığını anlayın

Bir elektronik tablo da çözümdür. Bir mesaj grubunda sabitlenen not da. İnsanların bunları kullanması, yeni bir uygulama istediğini göstermez. Mevcut araç tanıdık olabilir, ekip zaten orada çalışıyor olabilir veya iş yeterince seyrek yapılıyor olabilir.

Örneğin bir onay süreci dağınık görünürken asıl sorun “en güncel dosyanın hangisi olduğu” olabilir. Bu durumda kapsamlı proje yönetimi yerine sürüm ve onay bilgisini netleştiren küçük bir çözüm sınanabilir. Bu örnek, bir ürün özelliği vaadi değil; problemi daraltma alıştırmasıdır.

En riskli varsayım için küçük bir deney kurun

Her fikrin belirsizliği aynı yerde değildir. Bazen insanların işi önemseyip önemsemediği, bazen önerilen çözümü anlayıp anlamadığı, bazen de alışkanlık değiştirip değiştirmeyeceği bilinmez.

İhtiyacın sıklığını bilmiyorsanız kısa bir iş günlüğü tutturabilirsiniz. Akışın anlaşılmasını sınamak için tıklanabilir prototip kullanabilirsiniz. Çıktının yararını görmek için işlemin bir bölümünü elle yürüterek örnek sonuç sunabilirsiniz. Deneyde manuel yapılan bölümleri katılımcıya açıkça anlatın.

Bir prototipin anlaşılması, insanların ürüne düzenli olarak döneceğini kanıtlamaz. Her deneyin hangi soruyu cevapladığını baştan yazmak bu ayrımı korur.

Devam kararını önceden tanımlayın

Deney bittikten sonra her sonucu başarı olarak yorumlamak kolaydır. Bunun önüne geçmek için hangi gözlemin bir sonraki adımı destekleyeceğini önceden belirleyin.

Örneğin: “Katılımcı, yardım almadan doğru dosyayı bulup onay durumunu anlayabiliyorsa bu akışı geliştireceğiz.” Bu ölçüt yalnızca kullanılabilirliğe ilişkindir. Ödeme isteği ve sürekli kullanım için ayrıca kanıt gerekir.

Pist Studio’nun ürün odağında, yapmaya değer işi seçmek geliştirme becerisi kadar önemlidir. İlk kullanıcıyla görüşmeye giderken bir satış sunumu yerine, cevaplanabilir birkaç soru taşıyın. Ürünün biçimi, o cevaplar geldikçe netleşsin.