Deneyimi Özelliklerden Önce Tasarlamak
Bir ürünün hangi özellikleri taşıyacağını konuşmak kolaydır. O özellikleri kimin, nerede, ne kadar acele içinde kullanacağını konuşmak zordur, çünkü cevabı toplantı odasında değil dışarıda durur. Deneyimi önce tasarlamak, özellik listesini reddetmek değil; listeyi yazmadan önce kimin için yazdığını bilmektir.
Özellik listesi neyi gizler
Özellik listesi rahatlatıcıdır. Ölçülebilir, bölüştürülebilir, takvime yazılabilir. Kullanıcının bir işi bitirirken yaşadığı şey ise listede görünmez: iki ekran arasında kaybolan bağlam, üçüncü kez doldurulan aynı form, hata mesajının ne yapılacağını söylememesi.
Aynı tuzak, deneyim odaklı çalıştığını söyleyen ekipleri de yakalar. "Kullanıcı araştırması, persona, yolculuk haritası, prototip, test" diye ilerleyen bir süreç şeması, sonunda başka bir özellik listesidir; sadece adı değişmiştir. Ayırt edici soru şu: bu adımların çıktısı bir belge mi, yoksa yapılmayacağına karar verilen bir iş mi? Araştırma hiçbir özelliği kuyruktan düşürmüyorsa, araştırma yapılmamıştır.
Söylenenle yapılan çakıştığında
Görüşmelerde insanlar hatırladıklarını anlatır, gözlemde yaptıklarını gösterir. İkisi sık sık birbirini tutmaz. Kullanıcı "filtreleri hep kullanıyorum" der, kayda bakarsınız, üç oturumda bir kez açmış ve kapatmadan çıkmış.
Bu çeliştiğinde tereddüt etmeye gerek yok: davranış kazanır. Görüşme, davranışın nedenini anlamak için değerlidir, varlığını kanıtlamak için değil. Sıralama da bu yüzden önemli. Önce ne olduğunu ölçün, sonra niçin olduğunu sorun. Ters çevirirseniz, insanlara kendi hipotezinizi onaylatmış olursunuz ve bunu veri sanırsınız.
Kaç kişiyle test etmek yeter
Yaygın cevap beş. Kaynağı da belli: Jakob Nielsen'in modelinde bulunan sorunların oranı 1-(1-L) üzeri n ile büyür; burada n test edilen kişi sayısı, L ise tek bir kullanıcının yakaladığı sorunların ortalama payıdır. L=0,31 alındığında beş kişi sorunların yaklaşık %85'ini görünür kılar. Altıncı kişinin katkısı ilk kişinin yanında çok küçüktür, dolayısıyla otuz kişilik tek bir test yerine beş kişilik altı tur yapmak daha çok sorun bulur.
Formülün iki sınırı, tavsiye tekrarlanırken genellikle düşer. Birincisi, model tek bir kullanıcı grubu içindir. Bayi, son kullanıcı ve destek ekibi gibi üç ayrı davranış profiliniz varsa gereken sayı beş değil, grup başına beştir; on beşe çıkar. İkincisi, %85 rakamı L'ye bağlıdır. Arayüz zaten oturmuşsa her kullanıcının denk geldiği sorun payı düşer; L=0,15 olduğunda aynı beş kişi ancak %56'yı gösterir. Yani "beş kullanıcı yeter" kuralı en çok, en çok soruna sahip olan ham prototiplerde işe yarar. Cila aşamasında beş kişiyle test edip temiz çıkmak, temiz olduğunuz anlamına gelmez.
Bağlam arayüzün yarısıdır
Aynı ekran, masasında oturan bir muhasebeciyle depoda eldivenli telefon tutan bir sevkiyat sorumlusu için aynı ekran değildir. Ekran parlamasında okunmayan gri metin, tek elle erişilmeyen üst köşe butonu, kopuk bağlantıda kaybolan form: bunların hiçbiri tasarım dosyasında görünmez, hepsi sahada görünür.
Bu yüzden bağlam analizi, kullanıcı araştırmasının bir alt başlığı değil, ayrı bir iştir. Kullanıcının kim olduğunu bilmek yetmiyor; ürüne dokunduğu andaki hâlini bilmek gerekiyor. Elinde ne var, ne kadar vakti var, dikkatinin kaçta kaçı sizde.
Nereden başlanır
Pratik bir başlangıç: ürününüzün en sık yapılan işini seçin, beş kullanıcının o işi bitirmesini izleyin, konuşmayın ve yardım etmeyin. Çıkan sorunları özellik isteklerine çevirmeden önce, kaç tanesinin var olan bir özelliği kaldırarak çözüldüğüne bakın. Genellikle sanılandan fazlasıdır, ve o sayı ekibe deneyimi neden özelliklerden önce koymak gerektiğini herhangi bir sunumdan daha hızlı anlatır.
Kaynaklar