Kullanılabilirlik testi nedir, nasıl yapılır?

Kısaca

Kullanılabilirlik testinde bir kullanıcıyı ürününüzün başına oturtur, ona bir iş verir ve susarsınız. Kullanıcı işi bitirmeye çalışırken siz izler ve not alırsınız. Testin sonunda elinizde fikir değil, gözlem vardır.

NN/g'nin temel rehberine göre çoğu testin üç parçası vardır: yönetici, görevler ve katılımcı. Yönetici oturumu yürütür ve katılımcının davranışını farkında olmadan etkilememeye çalışır. Görevler, katılımcının gerçek hayatta yapabileceği işlerdir. Katılımcı da ürünün gerçekçi bir kullanıcısı ya da hedef kitleye benzer geçmişte biridir.

Testin ölçtüğü şey kullanılabilirliktir: bir ürünün ne kadar kolay öğrenildiği ve kullanıldığı. Test bu kolaylığı kullanıcının davranışından okur.

Heuristik değerlendirme ve UX audit'ten farkı

Heuristik değerlendirmede kullanıcı yoktur, uzmanlar arayüzü ilkelere göre inceler. UX audit bunun üstüne erişilebilirlik ve içerik kontrolleri ekler. NN/g'nin heuristik değerlendirme rehberi açıkça yazar: bu yöntem kullanıcı araştırmasının yerini tutamaz. Ben ikisini sırayla kullanırım. Audit nereye bakacağımı söyler, test kullanıcının orada gerçekten takılıp takılmadığını gösterir.

Ne zaman yapılır

Kısa cevap: tasarım değişikliği hâlâ ucuzken. Kâğıt bir taslak, tıklanabilir bir prototip ya da yayındaki ürün test edilebilir. Nielsen'e göre sesli düşünme de esnek bir yöntemdir. Geliştirmenin her aşamasında ve çoğu arayüz türünde kullanılabilir.

Testi şu anlarda öneririm:

• Bir akışı kodlamadan önce, prototip aşamasında. Burada bulunan sorun bir öğleden sonrada düzelir.
• Yayından hemen önce, en önemli iki üç görev için.
• Analitikte bir adımın terk oranı yükseldiğinde. Sayılar nerede düştüğünü söyler, test nedenini gösterir.
• Yeniden tasarımdan önce, eski ürünle. Neyin çalıştığını bilmeden yenisini çizmek, iyi parçaları da çöpe atar.

Test her soruya cevap vermez. "Kullanıcı bu özelliği ister mi?" sorusu görüşme ya da pazar araştırması işidir. Test, var olan bir tasarımın kullanılıp kullanılamadığına bakar. Bir MVP fikrinin talep görüp görmeyeceğini söylemez.

Kullanılabilirlik testi türleri

Testleri iki soruyla ayırırım: oturumu biri yönetiyor mu, katılımcıyla aynı odada mısınız? Üçüncü ayrım amaçtadır. Test ya sorun arar ya da sayı toplar.

Moderasyonlu ve moderasyonsuz

Moderasyonlu testte bir yönetici oturum boyunca katılımcıyla birliktedir. Amy Schade'in NN/g yazısına göre yönetici, görevler bitince ek sorularla sorunların ayrıntısına inebilir. Sessiz kalan katılımcıyı da nazikçe daha fazla anlatmaya yönlendirebilir. Bir görev bittikten sonra "Orada ne bekliyordunuz?" diye sormak, kaydı izleyerek çıkaramayacağınız bilgiyi verir.

Moderasyonsuz testte katılımcı çalışmayı tek başına yapar. Oturum kaydedilir, siz kaydı sonra izlersiniz. Önceden yazılmış sorular eklenebilir, ama canlı takip sorusu yoktur. Schade bu türü, çalışma birkaç belirli öğeye odaklandığında ve süre dar olduğunda uygun bulur.

Moderasyonsuz testin bedeli kontrolü kaybetmektir. Takip soruları önceden yazılır ve herkese aynı sorulur. Görev metni kötüyse, oturum bitene kadar bunu fark etmezsiniz. Bu yüzden görev metni bu türde iki kat önemlidir.

Uzaktan ve yüz yüze

Uzaktan moderasyonlu test yüz yüze teste çok benzer. Fark, yöneticiyle katılımcının ayrı yerlerde olmasıdır. Schade'e göre yönetici katılımcıyla telefon, e-posta, sohbet ya da bunların bir karışımıyla iletişim kurar. NN/g'ye göre uzaktan test, yüz yüze çalışmaya göre çoğu zaman daha az zaman ve para ister.

Yüz yüze testte katılımcının yüzünü ve duraksamasını görürsünüz. Schade de genel kural olarak yüz yüze testi tercih eder. Ama bütçe ya da süre yetmiyorsa uzaktan testin hiç test yapmamaktan iyi olduğunu ekler.

Uzaktan çalışırken bir pratik uyarı daha: aynı yazı, gelmeyen katılımcılar için birkaç kişi fazla davet etmeyi önerir. Hattın öbür ucundaki sessizlik de belirsizdir. Schade'e göre katılımcı kafası karıştığı için, dikkati dağıldığı için ya da içeriğe daldığı için susuyor olabilir.

Nitel ve nicel

NN/g'nin ayrımı nettir. Nitel test, deneyimdeki sorunları bulmak için en iyisidir. Nicel test ise deneyimi anlatan ölçümler toplar, örneğin görev başarısı ya da görevde geçen süre. Kıyaslama (benchmark) için en iyisidir. Bu sayfa çoğunlukla nitel testi anlatıyor, çünkü ürün ekiplerinin en çok ihtiyaç duyduğu odur.

Kullanılabilirlik testi nasıl yapılır: adım adım

Bir testi yedi adımda kurarım. Sıra önemli: hedef yazılmadan görev, görev yazılmadan katılımcı seçilmez.

1. Hedefi yazın

Testten ne öğrenmek istediğinizi tek cümleyle yazın. "Misafir kullanıcılar ödeme adımını yardım almadan bitirebiliyor mu?" iyi bir hedeftir. "Sitemiz kullanıcı dostu mu?" ise cevaplanamaz.

Hedefin yanına, sonucu kimin kullanacağını ve hangi kararı etkileyeceğini de yazarım. Karar yoksa test de gereksizdir.

2. Görevleri seçin

Hedefe hizmet eden ve kullanıcının gerçekten yaptığı işleri seçin. Ben bir oturuma birkaç görevden fazlasını koymam. Yorulan katılımcı son görevlerde dikkatini kaybeder.

Her görev için bir başarı ölçütü yazın. "Katılımcı ödeme ekranına geldi" gibi açık bir bitiş noktası, analizde tartışmayı önler. Bu ölçütü katılımcıya söylemezsiniz, yalnızca siz bilirsiniz.

3. Katılımcıları bulun

Katılımcı, ürünün gerçek kullanıcısı ya da onunla aynı ihtiyaçlara sahip biri olmalıdır. Bir mobil bankacılık uygulamasını tasarım ekibindeki arkadaşınıza test ettirmek, neredeyse hiçbir şey söylemez.

Katılımcılara zamanları için bir teşekkür ödemesi yapılır. NN/g'nin temel rehberine göre basit bir çalışmada bu ödemeler toplamda genelde birkaç yüz dolar tutar. Ben hediye çeki gibi katılımcının gerçekten kullanacağı bir şeyi tercih ederim.

Ürününüz birbirinden çok farklı gruplara hitap ediyorsa her gruptan ayrı katılımcı alın. Kaç kişi gerektiğini aşağıda ayrıca anlattım.

4. Senaryoyu yazın

Senaryo, görevi bir hikâyeye koyar: katılımcı bunu neden yapıyor? Marieke McCloskey'in NN/g yazısı üç ipucu verir. Görev gerçekçi olmalı, katılımcıya işi yaptırmalı ve ipucu ya da adım tarifi içermemelidir. Yazı ayrıca senaryonun bağlam sunması gerektiğini söyler.

Yazıdaki en işe yarar uyarı şudur: arayüzde geçen kelimeleri görevde kullanmayın. "Bültene kaydolun" yerine "Etkinlik haberlerinin düzenli olarak e-postanıza gelmesini sağlayın" demek gerekir. Aşağıdaki oluşturucu bu farkı ürün tipine göre gösteriyor.

İlk gerçek katılımcıdan önce görevleri bir iş arkadaşıyla deneyin. Anlaşılmayan bir cümle, beş oturumu birden boşa harcatabilir.

5. Sesli düşünmeyi isteyin

Katılımcıdan, işi yaparken aklından geçeni sesli söylemesini istersiniz. Nielsen 2012 yazısında sesli düşünmeyi belki de tek başına en değerli kullanılabilirlik mühendisliği yöntemi diye anar. Yöntemi üç adıma indirir: temsili kullanıcılar bulun, onlara temsili görevler verin ve susun.

Susmak en zor kısımdır. Nielsen'in saydığı zayıflıklardan biri de budur: eğitimsiz bir yönetici araya girdiğinde, bu kullanıcının davranışını kolayca değiştirebilir. Katılımcı takıldığında "Ne yapmaya çalışıyorsunuz?" diye sorarım, "Sağ üste baktınız mı?" diye sormam.

Durum doğal değildir, bunu da bilin. Nielsen'e göre birçok kişi sürekli konuşmayı zor bulur ve bazıları söyleyeceğini önce süzer. Sessiz kalan katılımcıya kısa bir hatırlatma yapmak yeterlidir.

Oturumu her seferinde aynı sırayla yürütürüm. Önce katılımcıya test edilenin kendisi değil, ürün olduğunu söylerim. Yanlış cevap olmadığını, takıldığı her yerin işimize yaradığını da eklerim.

Sonra birkaç ısınma sorusuyla ürünü nasıl kullandığını dinlerim. Görevleri tek tek, yazılı olarak veririm. Kapanışta da genel izlenimini ve aklına takılan bir şey olup olmadığını sorarım. Görüşü en sona bırakmak, görevler sırasında davranışı bozmaz.

6. Not alın

Not, ne gördüğünüzü yazmaktır, ne düşündüğünüzü değil. "Fiyat filtresini bulamadı, üç kez yukarı kaydırdı" bir gözlemdir. "Filtre kötü tasarlanmış" ise bir yorumdur ve analize kalır.

Her görev için aynı satırları doldururum: başarılı mı, nerede duraksadı, ne dedi. Mümkünse oturumu kaydederim ve ekipten biri ayrı not alır. Yönetici hem soru sorup hem yazarken bir şeyleri kaçırır.

7. Analiz edin

Oturumlar bitince notları sorunlara dönüştürün. Aynı yerde takılan katılımcıları bir sorunun altında toplayın ve kaç kişinin takıldığını yazın. Tek bir katılımcının sorunu da listeye girer, ama yanında bu bilgi durur.

Sonra her sorunu önem derecesine göre sıralayın. Ben UX audit'te kullandığım 0–4 ölçeğini burada da kullanırım. Rapor kısa olmalı: en önemli sorunlar, her birinin kanıtı olan bir video kesiti ve somut bir düzeltme önerisi.

Kaç katılımcı gerekir

Sorun bulmak için yapılan nitel bir testte beş katılımcı çoğu zaman yeter. Bu sayı Jakob Nielsen'in 2000'de yayımladığı "Why You Only Need to Test with 5 Users" yazısından gelir. Yazının asıl önerisi ise beş kişiyle yetinmek değil, küçük testleri tekrarlamaktır.

Nielsen, sayıyı Thomas Landauer ile 1993'te INTERCHI konferansında yayımladıkları bir modele dayandırır. Modele göre n kullanıcıyla bulunan sorun sayısı N(1 − (1 − L)ⁿ) formülüyle hesaplanır. N tasarımdaki toplam sorun sayısı, L ise tek bir kullanıcının bulduğu paydır.

Nielsen, incelediği projelerde L değerini ortalama %31 bulur. Buna göre tek kullanıcı sorunların neredeyse üçte birini gösterir. Beş katılımcılı ilk çalışma sorunların yaklaşık %85'ini bulur. Yazıya göre kullanıcı ekledikçe aynı şeyleri tekrar tekrar görürsünüz ve giderek daha az öğrenirsiniz.

• 1 kişi%31
• 2 kişi%52
• 3 kişi%67
• 4 kişi%77
• 5 kişi%84
• 6 kişi%89
• 8 kişi%95
• 10 kişi%98
• 15 kişi%99,6

Şekil: Nielsen'in formülüyle, L = %31 alınarak hesaplanan paylar. Değerler yuvarlanmıştır.

Formül beş kişi için %84,4 verir, yazı bunu yaklaşık %85 diye yuvarlar. Eğrinin beşten sonra yatıklaştığına dikkat edin. On beşinci kişi neredeyse hiç yeni sorun göstermez.

Nielsen buradan şu sonuca varır: tüm sorunları bulmak için en az 15 kullanıcı gerekir, ama bu bütçeyi tek testte harcamayın. Beşer kişilik üç test yapın. İlk testten sonra tasarımı düzeltin. İkinci test düzeltmeleri dener ve ilk turun kaçırdığı sorunların çoğunu bulur. Üçüncüsü, yüzeydeki sorunlar temizlenince görünen derin sorunlar için gerekir.

Beş sayısının sınırları da aynı yazıda yazılıdır:

• Kullanıcılarınız birbirinden çok farklı gruplardan oluşuyorsa, örneğin alıcı ve satıcı, her gruptan ayrı katılımcı alın. Nielsen iki grup için grup başına 3–4, üç ve daha fazla grup için grup başına 3 kişi önerir.
• Nicel çalışmalarda, yani sayı toplarken, yazı sonraki bir NN/g önerisine bağlanır: 20 kullanıcı.
• Kart sıralama çalışmaları için aynı yazı 15 kullanıcıyı gösterir.

NN/g'nin 2019 tarihli temel rehberi de aynı çizgidedir: tipik bir nitel çalışma beş katılımcıyla yapılır.

Görev ve senaryo oluşturucu

Testin kalitesini en çok görev metni belirler. Aynı hedef, iyi yazılınca kullanıcının gerçek davranışını gösterir. Kötü yazılınca katılımcıya cevabı fısıldar.

Görev ve senaryo oluşturucu

Online mağaza · Satın alma ya da ödeme

İyi Katılımcıya okunacak görev

Kızınızın doğum günü gelecek hafta. Ona bütçenizi aşmayan bir kulaklık almak istiyorsunuz. Hediye cumartesiden önce gelmeli. Uygun bir ürün bulun ve ödeme adımına kadar ilerleyin.

Başarı ölçütü (yalnızca sizin notunuz): Bütçeye ve teslim tarihine uyan bir ürün sepette, katılımcı ödeme ekranında.

• Gerçekçi Katılımcının hayatında olabilecek bir iş.
• Yaptırıyor Anlattırmıyor, işi ekranda bitirtiyor.
• İpucu yok Menü adı ya da buton yazısı geçmiyor.

Kötü Aynı hedef, kötü yazılmış

Arama çubuğuna “kulaklık” yazın, “Sepete ekle” butonuna basın. Sonra ödeme sayfasını beğenip beğenmediğinizi söyleyin.

• Adımları söylüyor Yol tarif edilince test, arayüzün yolu gösterip göstermediğini ölçemez.
• Arayüzdeki etiketi veriyor Katılımcı aradığı kelimeyi görevden öğrenir. Ekranda o kelimeyi bulmak, işi anlamaktan kolaydır.
• Görüş soruyor Beğeni sorusu davranış göstermez. Katılımcı işi yaparken nerede takıldığını görmek istersiniz.

Ürün tipini ve kullanıcının hedefini seçin. Sol kart katılımcıya okunacak iyi bir görev metnini, sağ kart aynı hedefin kötü yazılmış halini ve neden kötü olduğunu gösterir. Görevler benim örneklerim, gerçek bir müşteri işinden alınmadı.

Kötü örneklerin çoğu aynı yerden bozulur: görevi yazan kişi ekranı ezbere biliyor. Yazdığınız görevde bir menü adı ya da buton yazısı görüyorsanız, onu kullanıcının kendi kelimesiyle değiştirin.

Sık hatalar

Görevde arayüzün kelimelerini kullanmak. Katılımcı görevi okur, ekranda aynı kelimeyi arar ve bulur. Test başarılı görünür ama hiçbir şey ölçmemiştir.

İşi yaptırmak yerine anlattırmak. McCloskey, katılımcıya nasıl yapacağını anlattırmak yerine işi yaptırmayı önerir. Katılımcının kendi anlatımı daha az doğrudur ve arayüzün ne kadar kolay ya da sinir bozucu olduğunu gizler.

Ekip içinden katılımcı almak. Ürünü bilen biri sorunları göremez. Katılımcı, gerçek kullanıcıya benzemelidir.

Katılımcıya yardım etmek. Takılan katılımcıyı kurtarmak doğal bir refleks. Ama yardım ettiğiniz an, o görevin verisi kaybolur. Önce "Burada ne bekliyordunuz?" diye sorun.

Tek büyük test yapmak. Yirmi kişiyle tek test, aynı sorunu yirmi kez izlemek demektir. Nielsen'in önerisi beşer kişilik küçük testleri tekrarlamaktır.

Gözlemle yorumu karıştırmak. Notta "kafası karıştı" yazmak yerine ne yaptığını yazın. Yorum, analizde birden fazla oturuma bakınca yapılır.

Sonuçları rapora gömmek. Kimsenin okumadığı uzun bir rapor, testi boşa harcatır. Kısa bir sorun listesi ve birkaç video kesiti ekibi daha hızlı harekete geçirir.

Mobil ürünü masaüstünde test etmek. Kullanıcılarınız telefondan geliyorsa test de telefonda yapılmalı. Mobil uygulama tasarımında başparmağın ulaştığı yer, masaüstünde hiç görünmeyen sorunlar çıkarır.

Benim notum

Ekiplerin en çok zorlandığı adım görev yazmak değil, oturumda susmak. Kullanıcı takıldığında ilk istek, ona yolu göstermektir. Ben bu anlarda içimden beşe kadar sayarım, sonra yalnızca ne beklediğini sorarım.

İkinci gözlemim: ilk testin en değerli çıktısı çoğu zaman görev metinlerindeki hatalardır. Bu yüzden pilot oturumu atlamayın. Bir iş arkadaşıyla yapılan yarım saatlik deneme, gerçek oturumları kurtarır.

Bütçeniz test için yetmiyorsa önce bir audit ile en riskli akışı belirleyin. Test bütçesini o akışa harcayın. Ürünün tamamına uçtan uca bakmak için UX Audit Pro var.