Discovery fazı nedir, nasıl yürütülür?

Discovery fazı nedir

NN/g'den Maria Rosala discovery'yi, UX tasarım sürecinin problem alanını araştıran ön aşaması diye tanımlar. Bu aşamada çözülecek problemi çerçeveler ve sonraki adıma karar verecek kadar kanıt toplarsınız.

Türkçede "keşif aşaması" ya da "keşif fazı" da denir. Ürün ekipleri aynı işe çoğu zaman "product discovery" der. Ad değişir, soru aynı kalır: doğru problemi mi çözüyoruz?

Discovery'nin ana çıktısı bir karardır. GOV.UK Service Manual'a göre ekip bu fazın sonunda bir sonraki faza, yani alfaya geçip geçmeyeceğine karar verir.

Discovery ne zaman gerekir

Rosala'ya göre bilinmeyenin çok olduğu her durumda discovery gerekir. Ekip hedefler konusunda anlaşamıyorsa da işe yarar.

Rosala'nın saydığı tipik tetikleyiciler şunlar: yeni bir pazara girmek, şirket birleşmesi, yeni bir düzenleme, yeni bir kurum stratejisi. Uzun süredir çözülemeyen sorunlar da bu listede, örneğin hep düşük kalan satışlar. Yeni bir düzenleme yüzünden müşteri akışını değiştirmek zorunda kalan bir banka tipik bir örnektir.

Yine de bazı kurumlar bu aşamayı hiç yapmaz. NN/g'nin Ekim 2019'da 436 kişiyle yaptığı ankette, discovery'yi hiç yapmayan kurumlardaki katılımcıların %35'i neden olarak zaman baskısını gösterdi. Anketin örneklemi rastgele değil, bu yüzden oranları bir eğilim olarak okuyun.

Çevik (agile) ekipler için NN/g'den Anna Kaley'nin önerisi kısa: "scale it, not skip it." Yani discovery'yi atlamayın, küçültün. Kaley, kısa araştırma adımlarını bir iki kritik soruyla sınırlamayı önerir.

Discovery'nin amacı

Rosala bir discovery'den dört şey bekler:

• Kullanıcıları, ihtiyaçlarını ve problemin onları nasıl etkilediğini anlamak.
• Problemin nedenlerini, boyutunu ve getirdiği fırsatları anlamak.
• Mevcut iş süreçlerini, çözümleri ve kullanılabilir teknolojileri, yani kısıtları anlamak.
• İstenen sonuç ve başarının neye benzediği konusunda paydaşlarla ortak bir görüş kurmak.

GOV.UK kısıtları ikiye ayırır. Birincil mevzuat gibi sert kısıtlar pek değişmez. Mevcut süreçler gibi yumuşak kısıtları ise değiştirmek için çalışırsınız.

Bir şeyi de yapmazsınız. GOV.UK'nin cümlesi net: "You should not start building your service in discovery." Discovery'de ürün geliştirmeye başlanmaz.

Discovery aşamasında neler yapılır

Sıra projeye göre değişir. Ben genelde aşağıdaki sırayla ilerlerim, çünkü her adım bir sonrakinin sorularını keskinleştirir.

Hedef ve problem tanımı

GOV.UK önce discovery için bir hedef koymayı önerir. Hedef kapsamı belirler ve işin ne zaman bittiğini söyler.

Ekip çoğu zaman elinde hazır bir çözümle gelir: "uygulamaya sohbet botu ekleyelim." GOV.UK bu çözümü sorgulayıp bir problem olarak yeniden yazmayı önerir. Rosala da araştırmadan önce bir problem cümlesi yazmayı ve bu cümleye çözüm koymamayı tavsiye eder.

Paydaş görüşmeleri

Paydaş, projede çıkarı olan ya da işi bitirmek için birlikte çalışmanız gereken herkestir. NN/g'den Sarah Gibbons görüşme rehberini dört konu etrafında kurmayı önerir: başarı ölçütleri, öncelikler, geçmiş ve uzmanlık, süreç ve iş akışı.

Bence en değerli soru şudur: "Bunu daha önce denediniz mi, neden tutmadı?" Gibbons görüşmeleri birebir yapmayı ve sonunda "başka kiminle konuşmalıyım?" diye sormayı önerir. Ona göre ne kadar erken konuşursanız o kadar iyi.

Mevcut veri ve analitik

Yeni araştırmaya başlamadan önce elinizdekine bakın. NN/g'den Mayya Azarova buna masa başı araştırma (secondary research) der ve titiz bir araştırmanın standart ilk adımı sayar.

Kurumda genelde eski araştırma raporları, danışman çıktıları, müşteri hizmetleri kayıtları ve arama kayıtları vardır. Ben bunlara analitiği de eklerim: hangi sayfada çıkılıyor, hangi adımda form bırakılıyor? Clarity ve Hotjar gibi araçların oturum kayıtları da burada işe yarar.

Azarova bir uyarı da yapar: masa başı araştırma birincil araştırmanın yerini tutmaz. Benim deneyimimde veri ne olduğunu söyler, nedenini çoğu zaman söylemez.

Kullanıcı araştırması

Discovery'deki kullanıcı araştırması keşif amaçlıdır. Rosala en yaygın yöntemler olarak kullanıcı görüşmesini, günlük çalışmasını ve saha çalışmasını sayar. Daha geniş bir grup için anketten de söz eder. Rosala'ya göre discovery genelde bir hipotezi sınamaz ya da bir çözümü değerlendirmez.

Ben en sık kullanıcı görüşmesine başvururum. Kullanıcının bugün işi nasıl yaptığını, nerede takıldığını ve hangi geçici çözümlere başvurduğunu dinlerim.

GOV.UK bakışı geniş tutmayı önerir: işin öncesi ve sonrası, erişilebilirlik ihtiyaçları, dijital beceri ve internet erişimi. Çevrimdışı kanallar da sürecin parçasıdır, bu yüzden operasyon ekibiyle de konuşun.

Rakip bakışı

Kullanıcı sizi başka ürünlerle kıyaslar. Discovery'de kısa bir UX rakip analizi yapın: aynı görevi iki üç rakipte baştan sona deneyin.

NN/g anketinde katılımcıların son discovery'lerinde en sık yaptıkları işler kullanıcı görüşmesi (%62) ve paydaş görüşmesiydi (%60). Rakip analizi ve analitik incelemesi %49 ile onları izledi.

Varsayım listesi ve riskler

Discovery'nin en ucuz çıktısı varsayım listesidir. Ekipteki herkes "biliyoruz" dediği şeyleri yazar. Sonra her birinin neye dayandığına birlikte bakarsınız.

Kaley bunun için CSD matrisini anlatır: kesin bilgiler, kaynağa dayanan tahminler ve şüpheler. Kaley'ye göre matrisin amacı farklı bakışları toplayıp düzenlemektir. Herkesin aynı fikirde olması gerekmez. Hedef, tahminleri ve şüpheleri olabildiğince kesin bilgiye taşımaktır.

Listeyi sıralamak için Rosala iki soru sorar. Hangisi problemi çözmek için en önemli? Hangisi yanlış varsayılırsa büyük risk taşıyor? Ben bunu iki eksene indiririm: ne kadar eminim ve yanlışsa etkisi ne olur.

Az emin olduğunuz ve yanlışsa projeyi sarsacak varsayımlar ilk sırada test edilir. Aşağıdaki örnekte bunu kendiniz deneyebilirsiniz.

Varsayım haritası

Matris, örnek varsayımların başlangıç yerleşimini gösteriyor. JavaScript açıkken her kartı kendiniz işaretleyebilirsiniz.

Az eminim

Çok eminim

Yanlışsa etkisi yüksek

Yanlışsa etkisi düşük

Önce test edin (2)Öncelik

Az eminsiniz, yanlışsa proje sarsılır.

• V1 Uygulamadan randevu
• V2 Aylık abonelik

Kanıtını yazın (1)

Eminsiniz ama yanlışsa pahalıya patlar.

• V3 Takvim telefonda

Sonra bakın (2)

Bilmiyorsunuz ama yanlışsa kolay düzelir.

• V4 Hatırlatma işe yarar
• V5 Eğitimsiz kullanım

Kabul edin (1)

Eminsiniz ve risk düşük. İlerleyin.

• V6 Ödeme salonda

Önce test edin bölümünde 2 varsayım var: V1, V2.

• V1 Müşteriler randevuyu telefonla değil, uygulamadan almak istiyor.

  Az eminim · Yüksek etki · Yeri: Önce test edin

• V2 Salon sahipleri bu uygulama için aylık abonelik ücreti öder.

  Az eminim · Yüksek etki · Yeri: Önce test edin

• V3 Salonlar gün içindeki takvimi telefondan yönetir.

  Çok eminim · Yüksek etki · Yeri: Kanıtını yazın

• V4 Hatırlatma mesajı, randevuya gelmeyen müşteri sayısını azaltır.

  Az eminim · Düşük etki · Yeri: Sonra bakın

• V5 Çalışanlar uygulamayı eğitim almadan kullanabilir.

  Az eminim · Düşük etki · Yeri: Sonra bakın

• V6 Müşteriler ödemeyi uygulamada değil, salonda yapmayı tercih eder.

  Çok eminim · Düşük etki · Yeri: Kabul edin

"Sıram" adlı randevu uygulaması ve altı varsayımı benim uydurduğum örneklerdir. Seçimleriniz hiçbir yere gönderilmez.

Varsayım haritası: dört bölümün her biri bir sonraki adımı söyler. Az emin olduğunuz ve yanlışsa etkisi yüksek olan varsayımlar ilk sırada test edilir.

Matristeki yerleşim tartışmayı başlatır, bitirmez. Aynı varsayıma iki kişi farklı cevap veriyorsa, o fark başlı başına bir şüphedir. Kaley'nin önerdiği gibi onu bir soru olarak yazın ve şüpheler sütununa ekleyin.

Kapsam ve çıktılar

Rosala bir uyarı yapar: discovery, çıktı üretmek için yapılmaz. Yine de karar vermek için bazı belgeler gerekir. Ben bir discovery'yi şu üçü olmadan kapatmam:

• Problem tanımı. Kimin, hangi durumda, neyi yapamadığını anlatan bir iki cümle. Çözüm içermez.
• Başarı ölçütleri. GOV.UK, hangi veriyi toplayacağınızı ve hangi performans ölçütlerini kullanacağınızı bu fazda planlamanızı ister. HEART metrikleri burada iyi bir başlangıç çerçevesidir.
• Yol haritası. Sırada neyi, hangi sırayla deneyeceğiniz. GOV.UK'nin beklediği de buna yakın: alfada test edilecek fikirlerin listesi ve hangisinin önce deneneceğine dair bir görüş.

Gerekirse bunlara bir kullanıcı yolculuğu haritası, persona ya da kaba bir user flow eklenir. Rosala'nın olası çıktılar listesinde üst düzey konseptler ve wireframe'ler de var. Hepsi kararı desteklemek içindir.

Sonuç bazen "devam etmeyelim" olur. GOV.UK'ye göre araştırma bunu gösteriyorsa discovery sonunda durmak bir başarısızlık değildir. Bence yanlış ürüne harcanmayan bütçe, discovery'nin en somut getirisidir.

Süre ve ekip

Sabit bir süre yok. GOV.UK 4 ila 8 haftanın tipik olduğunu yazar. Hiç araştırılmamış bir problem daha uzun, ekibin iyi bildiği bir problem daha kısa sürebilir.

NN/g anketinde katılımcıların %58'i son discovery'lerinin en fazla iki hafta sürdüğünü söyledi. Rosala'ya göre kullanıcıya erişim kolay ve problem alanı küçük değilse iki hafta azdır.

Süreyi baştan sınırlayın. Rosala, ekiplerin işlerin süresini olduğundan kısa tahmin ettiğini hatırlatır; buna planlama yanılgısı denir. Kaley ise discovery süresini sprint uzunluğuna bağlamamayı önerir.

Ekip küçük ve farklı disiplinlerden olmalı. Rosala 3 ila 7 kişiyi ideal bulur: bir araştırmacı, bir kolaylaştırıcı, ekibe kapı açacak kadar etkili bir sahip ve teknik bir kişi. Teknik kişiyi atlamayın, kısıtları çoğu zaman ilk o görür.

Double Diamond ve product discovery

Ben discovery'yi Double Diamond modelinin ilk elmasına denk görürüm. Design Council bu elması Discover (keşfet) ve Define (tanımla) aşamalarından kurar. Önce problemi geniş araştırırsınız, sonra tek bir problem tanımına daraltırsınız.

Product discovery'de iş tek seferlik değildir. Kaley çevik ekiplerde discovery'yi küçük, yinelemeli adımlarla sürekli yürütmeyi anlatır. Yeni bir ürün için tam bir faz, çalışan bir ürün için sürekli küçük discovery'ler: ben farkı böyle görürüm.

Ajans teklifinde discovery neden ayrı fiyatlanır

Bu bölüm benim görüşüm. Bir ajans ya da serbest tasarımcı size discovery'yi ayrı bir kalem olarak öneriyorsa, bunun iyi bir nedeni vardır.

Discovery'den önce işin boyutunu kimse bilmez. Problem tanımı yokken yazılan bir tasarım fiyatı tahmindir. Tahmin ya şişirilir ya da proje ortasında ek ücret tartışmasına döner.

Discovery'yi ayırmak iki tarafı da korur. Siz küçük bir bütçeyle problemi netleştirirsiniz. Tasarım ve geliştirme teklifi de gerçek bir kapsama dayanır.

Bir de çıkış kapısı açılır. Discovery sonunda başka biriyle devam etmeye ya da hiç devam etmemeye karar verebilirsiniz. Problem tanımı ve ölçütler sizde kalır.

Sabit fiyatlı proje teklifi hazırlarken ben de önce aynı soruyu sorarım: kapsam yeterince net mi? Fiyatlama modellerini tasarım aboneliği mi sabit fiyat mı rehberinde ayrıca anlattım.

Benim notum

Discovery'de en sık gördüğüm hata, sonucu baştan belli bir çalışma yapmaktır. Ekip bir çözüme bağlanmıştır ve araştırmayı onu onaylatmak için kullanır. NN/g anketinde bir katılımcı da discovery'nin bazen ilk fikri onaylatmak için yapıldığını yazmıştı.

Bunu önlemenin en basit yolu, varsayım listesini ilk gün yazmaktır. "Önce test edin" bölümündeki varsayım çürürse ne yapacağınızı da baştan konuşun. Cevap "yine de yaparız" ise karar zaten verilmiştir ve discovery'ye gerek yoktur.

Küçük bir ekipseniz tam bir faz şart değil. Birkaç görüşme ve dürüst bir varsayım listesi bile, hiç araştırmadan çizmeye başlamaktan iyidir.