30 saniyelik özet
Hipotez, belirli bir koşul veya değişiklik hakkında sınanabilir bir açıklama ya da öngörüdür. Ürün çalışmasında hangi kullanıcı grubunda, hangi değişikliğin, hangi sonucu neden oluşturmasının beklendiğini açıklar. “Yeni ekran faydalı olacak” ifadesi bu ilişkiyi değerlendirmek için yeterli değildir. Hipotezin dayandığı kanıt, beklenen davranış ve değerlendirme yöntemi görünür olmalıdır. Product Owner, yani ürün sahibi, sonucu öğrenmeden önce hangi bilginin kararı değiştireceğini konuşmalıdır. Testte olumlu sonuç görülmemesi her zaman fikrin yanlış olduğunu göstermez; veri veya yöntem yetersiz olabilir. Amaç, fikri savunmak için kanıt seçmek yerine yatırım kararını daha sağlam bilgiyle vermektir.
Neden önemli?
Bir ekip ödeme akışını sadeleştirmek istiyor. Yönetici, daha az ekranın daha fazla satın alma getireceğini düşünüyor. Tasarımcı, kullanıcıların alanları daha kolay anlayacağını bekliyor. Geliştirici ise yükleme sürelerinin azalacağını öngörüyor. Aynı çözüm önerisinin arkasında farklı nedenler bulunuyor.
Bu nedenler açıklanmadığında sonuçların yorumlanması zorlaşır. Satın alma değişmediyse sorun tasarımda mı, beklenen ihtiyacın zayıflığında mı, yoksa çözümün kullanıcıya ulaşmamasında mı? Başlangıçta neyin sınandığı net değilse ekip teslimattan sonra birbirinden farklı hikâyeler anlatabilir.
Hipotez, bu konuşmayı geliştirme öncesine taşır. Kullanıcılar neden zorlanıyor? Önerilen değişiklik bu güçlüğü hangi yolla azaltacak? Başka bir açıklama olabilir mi? Soruların cevabı, büyük bir geliştirme yerine önce dar bir araştırma veya deneme yapılmasına yol açabilir.
Yönetim açısından hipotez, yatırım gerekçesinin belirsiz kısmını gösterir. “Bu özelliği yapmalıyız” cümlesiyle “Bu koşullarda şu davranışın değişmesini bekliyoruz” cümlesi farklı karar bilgileri sunar. İkincisi, kaynak ayırmadan önce neyin öğrenilmesi gerektiğini tartışmayı kolaylaştırır.
Hipotezle çalışmak bütün kararları geciktirmek anlamına gelmez. Belirsizlik düşük ve değişiklik küçükse değerlendirme daha hafif olabilir. Maliyetli bir yatırımın temel varsayımı zayıfsa daha güçlü kanıt gerekebilir. Araştırmanın kapsamı, kararın maliyeti ve yanlış olmanın etkisiyle birlikte düşünülmelidir.
Terim nedir?
Ürün hipotezinde genellikle kullanıcı grubu, mevcut sorun, önerilen değişiklik, beklenen sonuç ve gerekçe bulunur. “Yeni kullanıcıların kurulum adımındaki terimleri anlamadığını düşünüyoruz; açıklamaları görev bağlamında sunarsak kurulumu yardımsız tamamlama artacaktır” ifadesi bu ilişkiyi kurar.
Burada birden fazla iddia vardır. Terimlerin anlaşılmadığı bir problem iddiasıdır. Açıklamaların bunu gidereceği çözüm iddiasıdır. Yardımsız tamamlamanın artacağı ise beklenen sonuçtur. Hepsini tek deneyle incelemek her zaman mümkün değildir. Kullanıcı görüşmesi ve gözlem problemi anlamaya, bir taslak üzerindeki görev denemesi çözümü değerlendirmeye yardımcı olabilir.
Experiment, yani deney, hipotezi değerlendirmek için koşulları ve gözlemleri planlanan sınama sürecidir. A/B testi, bir değişikliğin etkisini mevcut durumla karşılaştırmak için kullanılabilen deney türüdür. Rastgele gruplara ayırma, grupların başka nedenlerle farklılaşması riskini azaltmaya yardımcı olur. Her ürün sorusu A/B testi gerektirmez.
Hipotezin değerlendirme ölçütü baştan açıklanmalıdır. Ne ölçülecek, hangi kullanıcılar kapsama girecek, ne zaman değerlendirilecek ve sonuç hangi kararı etkileyecek? Sayısal bir eşik gerekiyorsa mevcut veriler ve iş açısından anlamlı değişim değerlendirilmelidir. Kolay görünmesi için hedef rakamı uydurulmamalıdır.
Beklenen iyileşmenin yanında olumsuz sonuçlar da izlenebilir. İşlemi tamamlama artarken yanlış kayıtlar çoğalıyorsa çözümün faydası yeniden düşünülmelidir. Ana göstergeyi koruyan veya tamamlayan bu ölçütler, daha geniş etkileri gözden kaçırmamaya yardımcı olur.
Gerçek vaka: Booking.com’da tarih açıklığının sınanması
Harvard Business School’un 4 Aralık 2019 tarihli Creating the Experimentation Organization yayını, Stefan Thomke’nin araştırması üzerinden Booking.com’dan bir deney örneği aktarıyor. Kullanıcı araştırması, rezervasyon deneyiminde iyileştirme fırsatı bulunduğunu göstermiş.
Ekip, çocukların yaşlarıyla ilişkili seçim alanında “çıkış sırasında” ifadesinin belirsizlik yaratabileceğini fark etmiş. Çıkış tarihini açıkça göstermenin kullanıcıya daha fazla açıklık sağlayacağı düşüncesi iki farklı sürümle sınanmış.
Yayın, değiştirilen sürümün temel metrik üzerinde istatistiksel olarak anlamlı olumlu etki oluşturduğunu ve yeni sürümün standart hale getirildiğini belirtiyor. Ancak metrik adı, etki büyüklüğü ve ayrıntılı deney verileri metinde verilmemiş. Bu nedenle dönüşüm veya gelir artışına ilişkin oran eklemek doğru olmaz.
Bu vakada fikir, araştırma bulgusundan hareketle bir öngörüye dönüştürülmüş ve karşılaştırılmış. Küçük bir açıklama değişikliğinin etkisi, yalnızca tasarımcıların kanaatiyle değerlendirilmemiş.
Çıkarılabilecek ders, çözümün neden işe yarayacağının açıklanması ve bu beklentinin sınanmasıdır. Tek deneyin desteklediği sonuç da kapsamı içinde ele alınmalıdır; bütün arayüzlerde tarih göstermenin aynı faydayı sağlayacağı söylenemez.
Varsayımsal örnek: Kurulumdaki ilk veri aktarımı
Kurumsal bir yazılımda yeni kullanıcılar ilk veri aktarımını tamamlamadan ayrılıyor. Ekip başlangıçta sürecin uzun olduğunu düşünüyor. Görüşmeler ve görev gözlemleri, bazı kullanıcıların dosyanın kabul edilip edilmediğini anlayamadığını gösteriyor.
Ürün sahibi hipotezi daraltıyor: İlk veri aktarımını yapan kullanıcıya işlem durumunu ve düzeltmesi gereken alanları açıkça gösterirsek, kullanıcı belirsizlik nedeniyle süreci bırakmak yerine işlemi sürdürebilir.
Önce bu açıklamaların anlaşılıp anlaşılmadığı taslak üzerinden değerlendiriliyor. Kullanıcının gördüğü durumla sistemin gerçek durumu arasındaki tutarlılık inceleniyor. Taslak beğenilmesi, başarılı aktarımın arttığını gösteren kanıt olarak kullanılmıyor.
Çalışan çözüm uygun bir grupta denendiğinde aktarımın tamamlanması, tekrar denemeler ve destek ihtiyacı izleniyor. Kullanıcıların hangi koşullarda denemeye dahil edildiği kaydediliyor. Aynı dönemde dosya biçimi veya kurulum desteği değişirse bunun değerlendirmeyi etkileyebileceği not ediliyor.
Sonuç beklenen yönde değilse hemen daha fazla açıklama metni eklenmiyor. Ölçümün doğru çalışıp çalışmadığı, kullanıcıların yeni bilgiyi görüp görmediği ve asıl engelin farklı olup olmadığı araştırılıyor. Kanıt yeterliyse çözüm değiştirilebilir; yetersizse hipotez hakkında kesin hüküm verilmeden araştırma planı gözden geçirilir.
Yaygın üç hata
- Özellik talebini hipotez diye adlandırmak
“Durum ekranı yapacağız” bir çalışma niyetidir. Hangi kullanıcı davranışının neden değişmesini beklediğinizi açıklayın. Çözümle sonuç arasındaki ilişkiyi yazamıyorsanız önce ihtiyacı ve gerekçeyi araştırın.
- Sonucu gördükten sonra başarı ölçütünü seçmek
Beklenen gösterge değişmediğinde başka bir olumlu gösterge bulmak, başlangıçtaki öngörüyü desteklemez. Ana değerlendirmeyi önceden tanımlayın. Sonradan fark edilen bulguları yeni araştırma sorusu olarak kaydedin; ilk beklentinin sonucu gibi sunmayın.
- Destek bulunmamasını kesin yanlışlık saymak
Yetersiz veri, ölçüm hatası veya zayıf uygulama öngörüyü değerlendirmeyi engelleyebilir. Önce sınamanın geçerliliğini inceleyin. Hipotezin desteklenmesi, desteklenmemesi ve kararsız kalınması durumlarını ayrı ifade edin.
Mini uygulama / şablon
Önemli bir ürün önerisini seçip aşağıdaki alanları doldurun.
- Hedef kullanıcı ve kullanım koşulu
- —
- Gözlenen problem ve kanıtı
- —
- Önerilen değişiklik
- —
- Beklenen kullanıcı davranışı veya yetenek
- —
- Değişikliğin neden etkili olacağı
- —
- Alternatif açıklamalar
- —
- En belirsiz varsayım
- —
- Kullanılacak sınama yöntemi
- —
- Ana ölçüt ve başlangıç verisi
- —
- Olumsuz sonuç ölçütleri
- —
- Değerlendirme zamanı ve karar kuralı
- —
- Desteklenirse sonraki adım
- —
- Desteklenmezse sonraki adım
- —
- Kanıt yetersizse yapılacak çalışma
- —
Şablonu ekipçe okuyun. Hangi bulgunun fikrinizi değiştireceğini açıklayamıyorsanız sınamayı yeniden tasarlayın. Değerlendirme sonunda yalnızca sonuçları değil, bunların hangi yatırım kararına yol açtığını da kaydedin.
İlgili terimler
Assumption Mapping, Product Discovery, Customer Interview, Problem Statement, A/B Testing, Usability Testing, Prototype, Outcome ve Output, Product Goal, KPI ve Metrics, Continuous Discovery, Minimum Viable Product