Kullanılabilirlik Önerilerini Kabul Ettirmenin Yolu: Ekibi Teste Sokmak

Kullanılabilirlik önerileri çoğu projede içerik sahibinin kişisel tercihine çarpıp geri döner. Bunun sebebi karşı tarafın bilgisiz olması değil; iki taraf da kendi beğenisinden konuştuğu sürece tartışma kimin daha yüksek sesle konuştuğuna kalıyor. Bu döngüden çıkmanın tek pratik yolu, kararı bir tercih meselesi olmaktan çıkarıp gözlemlenebilir bir şeye bağlamak.

"Ben beğenmedim" itirazının içindeki haklı kısım

İçerik sahibi kendi alanını sizden iyi bilir. Hangi bilginin yanlış anlaşıldığını, hangi sorunun telefonda kaç kez sorulduğunu, hangi cümlenin hukuken böyle yazılmak zorunda olduğunu bilir. Bu gerçek bir uzmanlık ve masadan kaldırılamaz.

Sorun, o uzmanlığın kullanıcı davranışı hakkında da geçerli sanılması. Ekipteki insan konuya motive, arayüzü aylardır kullanıyor ve terminolojiyi biliyor; hedef kitle bunların hiçbirine sahip değil. Ama peki ya siz? Kendi öneriniz de bir sezgiden ibaretse, karşı tarafın sezgisinden neden daha ağır bassın? Ekip toplantılarında kaybedilen tartışmaların iyi bir kısmı bu yüzden kaybediliyor, çünkü ortada iki tahmin var ve biri yönetici koltuğunda oturuyor.

Tartışmayı bitiren şey odada olmak

Bir kullanıcının arayüzde tıkandığını izlemek, o tıkanmayı anlatan hiçbir rapora benzemez. Rapor tartışılabilir, izlenen oturum tartışılamaz. Bu yüzden ikna çabasının büyük kısmını sunuma değil, itiraz eden kişiyi teste getirmeye harcamak gerekiyor.

Bir projede en sert itirazı yapan kişiden test görevlerini kendisinin yazmasını istedim; ilk katılımcı ana menüde kaybolunca tartışma o oturumda bitti.

Kurulum için özel bir laboratuvara ihtiyaç yok. Ekran paylaşımı, yirmi dakika ve dört beş katılımcı yeterli. Görevleri şüphecinin yazması ise ayrıca işe yarıyor: sonucu beğenmediğinde "yanlış soru sordunuz" diyemiyor.

Beş kullanıcı kuralı gerçekte ne diyor

"Beş kullanıcı yeter" cümlesi sektörde sloganlaştı ama arkasındaki hesap basit ve okunmaya değer. Model, tek bir kullanıcının sorunların ortalama %31'ini ortaya çıkardığını varsayar ve n kullanıcının bulacağı oranı 1-(1-0,31)^n ile verir. Beş kullanıcı için bu %84 civarına denk geliyor. Nielsen Norman Group'un bu konudaki yazısı hesabın kendisini de anlatıyor.

Formülün gizlediği şey n değil, varsayımlar. Hesap tek ve türdeş bir kullanıcı grubu kabul ediyor. Kitleniz iki farklı segmentten oluşuyorsa, örneğin ilk kez giren kullanıcı ile günlük kullanan bayi, beş kişi ikisini birden temsil etmiyor; her segment için ayrı ayrı üç dört kişi gerekiyor ve toplam sessizce büyüyor. Aynı şekilde bu oran tek tur için geçerli. Beş kişiyle test edip düzeltip tekrar test etmek, on kişiyle tek seferde test etmekten daha fazla sorun buluyor.

Yani beş sayısı proje başına değil, segment ve tur başına. Bu ayrımı kurmadan "beş kişi yeterli" demek, ilk itirazda elinizde kalıyor.

Hangi kanıt ayakta kalır

Her çalışma eşit değil. Bir bulguyu ekibe götürmeden önce dört şeye bakın:

1. Örneklem gerçekten kitleyi temsil ediyor mu? Ofisten geçen stajyerlerle ya da alanın uzmanlarıyla yapılan test, kendi ekibinizin görüşünü kullanıcı kılığında geri getirir.
2. Görev hayattan mı alınmış? "Şu sayfayı bulun" ile "faturanı indirip muhasebeye göndereceksin" arasında ölçtüğünüz şey değişir.
3. Moderatör yönlendirdi mi? Katılımcı takıldığında verilen küçük bir ipucu, kaydı izlerken görünmez olur ama sonucu değiştirir.
4. Bulgu tekrarlandı mı? Tek katılımcının sıra dışı davranışı ilgi çekici olduğu için rapora giriyor, oysa asıl anlamlı olan üç kişinin aynı yerde durması.

Peki ya elinizde sadece analitik varsa? Analitik nerede terk edildiğini söyler, nedenini söylemez; ikisini karıştırmak kanıtın en hızlı çürüdüğü yer.

Güven hangi anda kuruluyor

En işe yarayan alışkanlık şu: testten önce herkesin tahminini yazıya dökmek. Ekipteki her kişi hangi görevin kaç kişide tıkanacağını önceden söylesin, kağıt masada dursun. Test bittiğinde tartışılacak bir şey kalmıyor, çünkü herkes kendi tahmininin nerede tuttuğunu görüyor. Bunu birkaç kez yaşayan ekip, sonraki tartışmalarda kendiliğinden "test edelim" demeye başlıyor.

İkinci alışkanlık teknik tarafla ilgili. Bir değişikliği önerirken uygulamada ne kadar tutacağını bilmek, önerinin ağırlığını değiştiriyor. Yazılım ekibine iki günlük bir iş olduğunu bilerek gittiğinizde konuşma başka türlü ilerliyor, üç haftalık bir refactor'ü "küçük bir düzeltme" diye sunduğunuzda ise bir sonraki öneriniz baştan indirimli dinleniyor.