UX Tutarlılığını Test Etmek: Kaç Kullanıcı, Hangi Yöntem
UX testi denince ilk sorulan şey genelde "kaç kullanıcı yeter" oluyor. Cevap yönteme göre değişiyor, çünkü konsept testiyle kullanılabilirlik testi aynı soruyu sormuyor bile. Biri fikrin karşılık bulup bulmadığını arıyor, diğeri tasarımın nerede takıldığını. İkisini karıştırınca elinizdeki veriyi olduğundan güçlü sanıyorsunuz.
İki test, iki ayrı soru
Konsept testi projenin başında, elde wireframe ya da kaba bir prototip varken yapılır. Sorduğu şey basittir: bu fikir hedef kitleye bir şey ifade ediyor mu? Kullanılabilirlik testi ise ortada çalışan bir akış olduğunda devreye girer ve fikri değil, fikrin somutlaşmış halini yoklar. Kullanıcı görevi tamamlayabiliyor mu, nerede duraklıyor, neyi yanlış okuyor?
Sıra kaymamalı. Konseptin karşılık bulmadığı bir üründe kullanılabilirlik testi yapmak, yanlış binanın kapı kollarını ölçmeye benziyor.
Konsept testinde aslında ne ölçülüyor
Gösterdiğiniz görsel gerçeğe ne kadar yakınsa geri bildirim o kadar isabetli olur, ama bunun bir tuzağı var: cilalı bir mockup gösterdiğinizde insanlar fikri değil estetiği yorumlamaya başlar. Peki tersi işe yarar mı? Kaba bir çizimde de "bu daha bitmemiş" diyip yorumu askıya alırlar. Orta yol, tasarım dili oturmuş ama detayı kasten eksik bırakılmış bir prototipte.
Beş on kişiyle konuştuğunuzda eliniz nitel veriyle dolu olur, nicel veriyle değil. Beş kişinin ikisi "kullanmam" dediyse elinizde yüzde kırk yoktur; iki insanın gerekçesi vardır. O gerekçe çoğu zaman sayıdan değerlidir, çünkü sayıyı zaten sonra ölçebilirsiniz. SurveyMonkey ya da Google Forms üzerinden geniş bir kitleye anket açmak burada faydalı, fakat anketin verdiği şey ilgi eğilimidir, kabul kararı değil.
Kullanılabilirlik testi: beş kullanıcı meselesi
"Beş kullanıcı yeter" cümlesi Nielsen ve Landauer'in modelinden geliyor. Tek bir kullanıcının sorunların ortalama %31'ini açığa çıkardığı varsayımıyla, bulunan oran 1-(1-0,31)^n ile büyüyor: beş kullanıcıda %84, sekizde %95 civarı. Eğri hızla düzleşiyor, onuncu kullanıcının katkısı birincisinin onda biri kadar kalıyor.
Burada çoğu rehberin atladığı bir çelişki var. Aynı metinde hem "beş kişi yeter" hem "katılımcılar hedef kitlenizle örtüşsün" yazar. Bu iki tavsiye ancak tek bir kullanıcı tipi varsa yan yana durabilir. Birbirinden farklı davranan üç segmentiniz varsa, diyelim ilk kez giren ziyaretçi, düzenli müşteri ve kurumsal alıcı, beş sayısı segment başınadır ve toplam on beşe çıkar. Formül segmentin içinde çalışır, segmentler arasında değil.
Oturumun kendisi
- Görev yazın, soru değil. "Ödeme sayfasını nasıl buluyorsunuz" diye sorarsanız yorum alırsınız; "şu ürünü sepete ekleyip siparişi tamamlayın" derseniz davranış görürsünüz.
- Sesli düşündürün ve karışmayın. Kullanıcı takıldığında yardım etme dürtüsü güçlüdür, oysa test tam o anda veri üretmeye başlar.
- Söylenene değil yapılana bakın. Memnuniyet anketi oturumun sonunda gelsin, ortasında değil.
- Bulguları önem sırasına dizin. On sekiz maddelik düz bir liste, ekipte hiçbir şeyin düzelmemesinin en yaygın sebebi.
Bir ödeme akışında beş kullanıcının üçü aynı noktada durakladı; sorun sandığımız gibi sepet sayfasındaki butonda değil, bir önceki adımdaki "onayla" kelimesinin ödemenin çoktan alındığı izlenimini vermesindeydi.
Tutarlılık neyin tutarlılığı
Tutarlılık genelde görsel bir mesele gibi anlatılır: aynı renk, aynı buton, aynı boşluk. Asıl mesele davranışsal olanıdır. Aynı görünen iki butonun farklı iş yapması, farklı görünen iki butondan çok daha fazla can sıkar. Kullanıcı formu ezberlemez, sonucu ezberler.
Peki tutarlılık ne zaman bilerek bozulmalı? Bir ekranın işi diğerlerinden gerçekten ayrılıyorsa. Geri alınamayan bir silme işlemi, sistemdeki her onay düğmesiyle aynı görünmemeli; oradaki tutarsızlık kasıtlıdır ve doğrudur. Tutarlılığı kural değil araç saymak gerekiyor, yoksa tasarım sistemi bir süre sonra düşünmemek için bahaneye dönüşüyor.
Ölçümü sürekli hale getirmek
Test tek seferlik bir tören değil. Yeni özellik girdiğinde, akış değiştiğinde veya kitle kaydığında eski bulgular sessizce geçersizleşir. Isı haritası ve tıklama analizi neyin olduğunu gösterir, nedenini göstermez. Bu yüzden nicel araçları oturumların yerine değil öncesine koyun: nerede sorun olduğunu onlarla bulun, niye olduğunu kullanıcıyla konuşarak öğrenin.
Teknik taraf da kullanılabilirliğin parçası. PageSpeed Insights ya da WebPageTest'te görünen gecikme, kullanıcı testinde "tıkladım ama bir şey olmadı, tekrar tıkladım" diye geri döner. Uzaktan test platformları (UserTesting, Lookback, Maze) coğrafi kısıtı kaldırır, karşılığında ortamı kaybedersiniz: kullanıcının yanında oturmadan fark edemeyeceğiniz şeyler var, mesela ekranı gerçekten okuyup okumadığı.
Kaynaklar