Design Sprint: Beş Günün Gerçek Maliyeti ve Cuma Testinin Sınırı

Google'ın Design Sprint'i beş günlük sabit bir takvim: pazartesi problemi açarsınız, cuma gerçek kullanıcının önüne çıkarsınız. Arada eskiz, oylama ve tıklanabilir bir prototip var. Yöntemin işe yarayan tarafı da kimsenin konuşmadığı faturası da aynı takvimden çıkıyor.

Beş günün işleri

Sıra sabittir, bozmayın:

1. Pazartesi: problemi haritalayın, hedefi tek cümleye indirin, ekipteki uzmanları tek tek dinleyin.
2. Salı: herkes tek başına çözüm eskizler. Beyin fırtınası toplantısı yok, kağıt var.
3. Çarşamba: eskizler duvara asılır, sessiz oylamayla daraltılır, kazanan storyboard'a dökülür.
4. Perşembe: storyboard tıklanabilir bir cepheye dönüşür. Arka uç yazmayın, ekranları birbirine bağlamak yeterli.
5. Cuma: kullanıcılarla birebir görüşülür, ekip yan odadan izler.

Ucuz değil, hızlı

Sprint'in satış cümlesi "bir haftada sonuç". Doğru ama yarım. Beş gün, günde yedi saat, altı kişilik bir ekip: 210 kişi-saat. Takvimde bir hafta, bütçede altı kişinin tam haftası. Kazandığınız şey ucuzluk değil, cevabın ne kadar erken geldiği.

Buradan işe yarar bir kural çıkıyor: sprinti yalnızca yanlış cevabın 210 saatten pahalıya mal olacağı sorulara ayırın. Buton rengini, menü sırasını, kayıt formundaki alan sayısını sprintle çözmeyin. Onlar için canlıda A/B testi hem daha ucuz hem daha dürüst.

Cuma gününe kaç kullanıcı sığar

Kaynaklarda dolaşan "6 ile 20 arası kullanıcı" tavsiyesi tek güne sığmaz. Bir görüşme yaklaşık bir saat, araya not toparlama ve oda hazırlığı giriyor; günde beş görüşme dolu bir gün eder. Yirmi kişi dört gün demek, o dört günde prototip de değişmiş olur ve elinizde aynı ürüne ait olmayan bulgular kalır. Nielsen Norman Group'un ölçümü beş kullanıcının kullanılabilirlik sorunlarının yaklaşık %85'ini ortaya çıkardığını söylüyor. Beşten sonrası çoğunlukla aynı şeyi tekrar duymak (yirmi kişilik test gününü kimin gerçekten denediğini merak ediyorum).

Karar kolektif değildir

Fikir toplama aşaması demokratik olmalı, karar aşaması değil. Sprint'in kendi kitabı bu yüzden odaya bir Decider koyar: oylamada herkesin sesi vardır, son sözde bir kişinin. Kararı gruba bırakan sprintler çarşamba öğleden sonra tıkanır, çünkü kimse kimseyi kırmak istemez ve storyboard'a iki fikir birden sokulur. Perşembe akşamı da yarım kalmış iki prototiple kalırsınız.

Ne zaman sprint yapmayın

Sorun tanımlıysa ve çözüm belliyse sprint israftır; iki gün kod yazın, yayına alın, ölçün. Tıkanma teknik bir kısıttan geliyorsa (ödeme sağlayıcısı o akışa izin vermiyor gibi) kullanıcı testi size bunu söylemez, sistem dokümantasyonu söyler. Sprint, "hangi çözümün tutacağını bilmiyoruz ve yanlış seçim aylara mal olacak" durumunda karşılığını verir. Ürünün hayatındaki böyle anlar da yılda bir ya da iki tanedir; geri kalan haftalar için normal çalışma düzeniniz zaten yeterli.