Özellik mi Sonuç mu? Ürün Tasarımında Doğru Soruyu Sormak
Bir ekibe ne ürettiğini sorun, listeyi dakikalar içinde sayar. Ne değiştirdiğini sorun, cevap genelde uzar. Aradaki boşluk çıktı ile sonuç arasındaki farktır ve ürün tasarımında verilen kötü kararların çoğu tam oraya sığar.
Çıktı ile sonuç arasındaki fark neye yarıyor
Çıktı, ürettiğiniz şeydir: bir ekran, bir rapor, bir filtre. Sonuç, kullanıcının davranışında ölçebildiğiniz değişimdir. Rapor ekranını yayına almak çıktıdır; kullanıcının aynı kararı yarım saat yerine iki dakikada vermesi sonuçtur. İkisi aynı cümlede geçtiği için karışıyorlar, oysa biri sizin kontrolünüzde, diğeri değil.
Peki ekipler bunu bilmelerine rağmen neden çıktıya geri kayıyor? Sebep niyet değil, ritim. Çıktıyı iki haftada ölçebilirsiniz, sonucu genellikle çeyrek dolmadan göremezsiniz. Sprint sonunda gösterilecek bir şey gerektiğinde, elde ölçülebilir tek şey çıktıdır. Bu yüzden sonuç odaklı çalışmak bir zihniyet meselesi olmaktan çok bir takvim meselesidir.
Ölçüyü müdahaleden önce seçin
Sonuç hedefi koymanın zor tarafı, hedefin sizi bağlaması. Kolay yol, sürüm çıktıktan sonra iyi görünen grafiği bulup onu başarı ölçüsü ilan etmek. Bunu engellemenin tek pratik yolu, ölçüyü geliştirmeye başlamadan yazmak ve tek bir cümleye sığdırmak: hangi kullanıcı, hangi işi, ne kadar sürede yapacak.
Bir başka tuzak, aynı dönemde birden fazla değişiklik yayınlayıp sonucu bunlardan birine yazmak. Üç değişiklik aynı hafta çıktıysa, çeyrek sonundaki iyileşme üçünün ortak eseridir ve hangisinin katkı yaptığını söyleyemezsiniz. Ölçmek istediğiniz değişikliği ayrı yayınlayın, ölçüm penceresini önceden kapatın.
Özellik yığmanın gerçek maliyeti
Bir sağlık sigortası sitesine yemek tarifleri eklemek zararsız görünür. Kullanıcı oraya teminat detayı için gelir, tarif sayfası onun yolunu uzatır ve arama sonucunu bulandırır. Ama asıl maliyet ekranda değil arkada birikir. Kaldırılmayan her özellik, bir sonraki değişikliğin test edilmesi gereken yüzeyini kalıcı olarak büyütür. Bir özelliği geri almanın maliyetini eklemeden önce hesaplayın, yoksa o hesabı iki yıl sonra başkası çıkarır.
Bunun tersi de doğru: kullanıcının işini gerçekten hızlandıran tek bir değişiklik, aynı sprintte çıkan beş yeni ekrandan daha fazla bağlılık üretir. Ürün sayfanızdaki özellik listesinin uzunluğu bir güç göstergesi değil, çoğu zaman karar verememenin izidir.
Peki hangi ihtiyacın gerçek olduğunu nereden bileceksiniz
Anket size insanların ne söylediğini verir, davranış verisi ne yaptığını. İkisi çelişince davranışa güvenin. Persona, kullanıcı yolculuk haritası ve saha gözlemi bu noktada işe yarar, ama bir şartla: gerçek görüşmeden çıkmışlarsa. Ekip odasında varsayımla doldurulan persona, varsayımı belgeye dönüştürmekten başka bir iş görmez.
Prototiple erken test etmenin değeri de burada. Wireframe aşamasında yanlış olduğunu anladığınız bir akış size bir gün kaybettirir, üretimde anladığınız aynı akış bir çeyrek. Fikir ne kadar ucuzken test edilirse, yanlış çıkması o kadar sorunsuzdur.
Karar anında sorulacak tek soru
Yeni bir işi listeye almadan önce şunu yazın: bu iş yayına çıkarsa kullanıcının davranışında ne değişecek ve bunu nereden göreceğiz? Cevap veremiyorsanız iş kötü değildir, sadece henüz tanımlanmamıştır. Tanımlanmamış işi yapmak, yapmamaktan daha pahalıdır, çünkü sonunda elinizde bakımını üstlendiğiniz ama neye yaradığını kimsenin bilmediği bir özellik kalır.