Contextual Inquiry: Kullanıcıyı Kendi Ortamında İzlemek

Kullanıcıya ne yaptığını sormakla, ne yaptığını izlemek arasında ciddi bir fark var. Bağlamsal sorgulama (contextual inquiry) tam olarak bu farkı kapatmak için kurulmuş bir yöntem: araştırmacı kullanıcının kendi masasına gider, o işini yaparken izler ve gördüğünü orada, anında ona doğrulatır. Yöntemin dört ilkesi, dört aşaması ve çoğu ekibin hafife aldığı bir analiz yükü var.

Yöntemi ayakta tutan dört ilke

Bağlamsal sorgulamayı Hugh Beyer ve Karen Holtzblatt dört ilke üzerine kurar. Bunlardan biri düşerse geriye yöntem değil, nazik bir saha ziyareti kalır.

• Bağlam: Gözlem, kullanıcının kendi ortamında ve gerçek işini yaparken yapılır. Onu toplantı odasına çağırdığın anda anlattığı şey işin kendisi değil, işin hatırladığı kadarıyla özeti olur.
• Ortaklık: Konumun ne denetçi ne de misafirdir. Kullanıcı işi yapar, sen yanında durup çıraklık edersin; anlamadığın yerde durdurup sorarsın.
• Yorumlama: Çıkarımını kendine saklamazsın. “Bu ekranı her açışınızda önce sağ üste bakıyorsunuz, orada beklediğiniz bir sayı mı var?” diye sorarsın ve cevabı ya doğrular ya da yorumunu çöpe atar.
• Odak: Gittiğin yerde neyi araştırdığın bellidir. Odak olmadan not defteri dolar, bulgu çıkmaz.

Pratikte en çok atlanan üçüncüsü. Yorumu oturumda doğrulatmazsan, yanlış çıkarım rapora girer ve haftalar sonra kimsenin kaynağını hatırlamadığı bir tasarım kararına dönüşür.

Bir oturum nasıl ilerler

Açılışı kısa tut. Kendini tanıtırsın, ne kadar kalacağını söylersin, kayıt alıp almayacağını sorarsın. Katılımcı bu noktada genelde gergindir, çünkü test edilenin kendisi olduğunu düşünür. “Doğru yapmanızı beklemiyorum, normalde nasıl yaptığınızı görmek istiyorum” cümlesi bu yanlış anlamayı baştan keser ve gösteri moduna geçme riskini büyük ölçüde düşürür.

Ardından geçiş gelir. Sohbeti kesip katılımcıdan işine dönmesini istersin, sen de kenara çekilirsin. İlk on dakika sessiz kalmak işe yarar: kullanıcı senin varlığına alışana kadar sorduğun her soru akışı biraz daha bozar.

Asıl görüşme, izlemek ve aralara soru sıkıştırmaktan ibarettir. Sorular yargısız olmalı. “Neden böyle yapıyorsunuz?” savunmaya iter, “Bu adımda ne oluyor?” anlatmaya davet eder. Konu mevcut bir ürünse oturumun şikâyet listesine dönme ihtimali yüksektir; bunu kabalaştırmadan toplamak gerekir, çünkü şikâyetin kendisi de veridir ama tek başına iş akışını anlatmaz.

Kapanışta gördüklerini özetleyip katılımcıya okursun. Yanlış anladığın yerleri burada öğrenirsin, üç hafta sonra değil.

Notlardan bulguya

Oturumdan çıkan şey ham not, ses kaydı ve birkaç ekran görüntüsüdür. Bunu doğrudan tasarıma çeviremezsin. Yaygın yöntem affinity mapping: her gözlemi ayrı bir nota yazarsın, sonra ekip birlikte bu notları anlamlı öbeklere ayırır. Öbekler isimlendikçe tekrar eden sorunlar, örtük ihtiyaçlar ve kullanıcıların kafasındaki model ortaya çıkar.

Destek taleplerini okumakla editörün ekranına bakmak arasında seçmem gerekse ikincisini daha güvenilir bulurum. Talep açan kullanıcı sorunu zaten kendi zihnindeki modele çevirmiş, çözüm önerisine sıkıştırmıştır; izlerken ise aksaklığı ham haliyle, kullanıcının fark bile etmediği yerde görürsün.

Nerede fazla gelir

Yöntem, kullanıcının karmaşık ve kendine özgü bir iş akışı olduğu yerlerde karşılığını verir: bir depo yönetim ekranı, bir muhasebe modülü, çok yazarlı bir yayın süreci. Buna karşılık tek ekranlık bir form doldurma ya da bir sitede gezinme davranışı için oransız kaçar. Orada kayıt tabanlı analiz, ısı haritası ya da kısa bir kullanılabilirlik testi hem daha ucuz hem yeterli.

Maliyet ortadan kalkmıyor, yer değiştiriyor

Yöntemin tanıtımlarında sık geçen bir cümle var: daha az eforla daha isabetli tasarım. Cümlenin ilk yarısı doğru değil. Bir oturum, yol dahil yarım gününü alır; analiz bunun katı kadar sürer; beş kullanıcı görmek istiyorsan takvimde bir haftadan bahsediyorsun. Aynı metinlerin “zaman ve kaynak yönetimi zorluğu” başlığı açması da bunu itiraf ediyor zaten.

Kazanç başka yerde. Yanlış kurgulanmış bir iş akışını canlıya çıktıktan üç ay sonra düzeltmek, tek bir ekranı değiştirmek değildir: veri modeline dokunursun, eski kayıtları göçürürsün, entegrasyonu kullanan tarafa haber verirsin. Bağlamsal sorgulama bu masrafı ortadan kaldırmaz, onu tasarım aşamasına çeker. Ucuz olduğu için değil, orada ucuz olduğu için yapılır.