UX Nasıl Ölçülür? Görev Başarısı, SUS ve HEART

"Kullanıcı deneyimimiz iyi mi?" sorusu, ölçülmediği sürece bir görüş tartışmasıdır. Ölçüm bu tartışmayı veriye taşır, ama yanlış metrik seçildiğinde yanlış kararı da veriyle süsler. Bu yazı kullanılabilirlik testlerinde kullanılan temel metrikleri, SUS anketinin nasıl puanlandığını, Google'ın HEART çerçevesini ve bir ürün için hangi metriğin ne zaman seçileceğini anlatıyor.

Ölçmeden önce: kullanılabilirliğin üç boyutu

SUS'u geliştiren John Brooke, kullanılabilirliğin ölçümünü üç bileşene ayıran ISO 9241-11 standardını hazırlayan grubun başkanlığını yaptığını anlatır. Bu üç bileşen, kullanım bağlamına göre tanımlanır: etkililik (kişilerin görevlerini tamamlayıp hedeflerine ulaşıp ulaşamadığı), verimlilik (bunun için ne kadar kaynak harcadıkları) ve memnuniyet (bunu yaparken duydukları rahatlık) 4. Brooke'un vurguladığı nokta şudur: görevleri tamamlatan ama büyük zaman ve emek isteyen, herkesin memnun olmadığı bir sistem kullanılabilir sayılamaz 4.

Nielsen'in kullanılabilirlik metrikleri yazısı da aynı temel dörtlüyü sayar: başarı oranı, görev süresi, hata oranı ve öznel memnuniyet 2.

Görev başarısı

NN/g görev başarı oranını, bir çalışmada görevi tamamlayabilen kullanıcıların yüzdesi olarak tanımlar ve "kullanılabilirliğin en basit metriği" olarak niteler; kullanıcı hedeflediği görevi tamamlayamıyorsa geri kalan her şey önemini yitirir 1.

Başarıyı ölçmek, onu önceden tanımlamayı gerektirir. NN/g yalnız "başarılı" ve "başarısız" ayrımı yerine ara düzeyler önerir: tam başarı, küçük sorunla başarı (örneğin hediye notunu unutmak), büyük sorunla başarı (örneğin yanlış teslimat adresi) ve başarısızlık 1. Her düzey ayrı bir yüzde olarak raporlanır. Aynı yazı önemli bir uyarı da yapar: düzeylere verilen numaralar yalnız etikettir, sıralı veridir ve ortalaması alınmamalıdır 1.

Görev başarısı ölçümü için pratik bir sıra:

1. Görevi gerçekçi bir senaryo olarak yazın. "Fatura menüsüne gidin" değil, "Geçen ayın faturasını indirin".
2. Başarı kriterini testten önce yazın. Hangi ekrana ulaşılması, hangi değerin doğru girilmesi gerektiğini belirleyin.
3. Ara düzeyleri tanımlayın. Hangi sapmanın küçük, hangisinin büyük sorun sayılacağına önceden karar verin.
4. Her düzeyi ayrı yüzde olarak raporlayın. Örneklem büyükse güven aralığını da ekleyin.
5. Başarısızlıkların nedenini kayıtlardan çıkarın. Metrik nerede sorun olduğunu söyler; nedenini gözlem söyler.

Testin nasıl planlanıp yürütüleceğini kullanılabilirlik testi nasıl yapılır yazısında ayrıntılı anlattık.

Görev süresi ve hata oranı

Görev süresi, verimliliğin en doğrudan göstergesidir; hata oranı ise kullanıcının görevi yaparken yaptığı yanlışları sayar 2. İkisi de görev başarısından daha fazla hazırlık ister:

• Başlangıç ve bitiş noktaları net olmalıdır. Süre, görev okunduktan sonra mı başlıyor, ilk tıklamada mı? Kriter bir kez belirlenir ve tüm katılımcılarda aynı uygulanır.
• Neyin hata sayılacağı önceden yazılmalıdır. Yanlış menüye girmek, yanlış alana veri yazmak, geri dönmek zorunda kalmak gibi.
• Sesli düşünme protokolü süreyi etkiler. Katılımcıdan düşündüklerini sesli söylemesi istenen testlerde süre, gerçek kullanımdan uzun olabilir; süre ölçümü öncelikliyse protokolü buna göre seçin.
• Süreler genellikle birkaç çok uzun değer içerir. Tek bir aşırı değerin ortalamayı çarpıtmaması için dağılıma da bakın.

Nielsen'in 2001 tarihli yazısı, metrik toplamanın pahalı olduğunu ve kısıtlı bütçede nitel yöntemlerin genellikle daha iyi bir yatırım olduğunu hatırlatır 2. Bu uyarı bugün de geçerlidir: metrikler bir tasarımın ne kadar iyi olduğunu söyler, nasıl iyileştirileceğini söylemez.

SUS: 10 soruluk kullanılabilirlik ölçeği

System Usability Scale (SUS), John Brooke tarafından Digital Equipment Corporation'da geliştirildi. Brooke ölçeği 1986'da meslektaşlarıyla serbestçe paylaştığını, yaklaşık on yıl sonra da bir kitap bölümüyle yayımladığını anlatır 4. Ölçek, kullanıcıların algıladığı kullanılabilirliği kısa sürede ölçmek için tasarlandı; olumlu ve olumsuz ifadeler, hızlı cevap vermenin yarattığı yanlılığı azaltmak için sırayla dizildi 4.

Puanlama. Her madde beş dereceli bir ölçekle cevaplanır. Brooke'un anlattığı puanlama şöyledir: tek numaralı (olumlu) maddelerde katkı, verilen cevaptan 1 çıkarılarak; çift numaralı (olumsuz) maddelerde 5'ten verilen cevap çıkarılarak bulunur. Her maddenin katkısı 0 ile 4 arasındadır; toplam 2,5 ile çarpılarak 0 ile 100 arasında bir puana dönüştürülür 4 5.

Örnek bir hesap (varsayımsal bir katılımcı):

Katkıların toplamı 32'dir; 32 çarpı 2,5 ile bu katılımcının SUS puanı 80 olur.

Yorumlama. Brooke'un açıkça uyardığı nokta, SUS puanının 0 ile 100 arasında olmasına rağmen bir yüzde olmadığıdır; karşılaştırma için yüzdelik dilime bakmak gerekir 4. Jeff Sauro'nun yaklaşık 500 değerlendirmeyi ve 5.000'den fazla kullanıcıyı kapsayan analizinde ortalama SUS puanı 68'dir; 68'in üzeri ortalamanın üstünde, altı ortalamanın altında kabul edilir 5. Brooke, Sauro'ya atıfla 70 civarındaki bir puanın ortalamaya, yani yaklaşık 50. yüzdelik dilime denk geldiğini aktarır 4.

Sınırları. Brooke'un özetlediği bulgulara göre SUS güvenilir ve geçerlidir ama tanı koymaz; bir sistemi neyin kullanılabilir ya da kullanışsız yaptığını söylemez 4. Faktör analizleri ölçeğin öğrenilebilirlik ve kullanılabilirlik olmak üzere iki alt boyut içerdiğini göstermiştir; SUS puanlarının görev performansıyla ilişkisi ise orta düzeydedir 4. Ölçeği Türkçe kullanacaksanız maddeleri kendiniz çevirmek yerine geçerlik çalışması yapılmış bir Türkçe uyarlamayı tercih edin ve hangi uyarlamayı kullandığınızı raporda belirtin.

HEART: ürün ölçeğinde kullanıcı merkezli metrikler

HEART çerçevesi, Kerry Rodden, Hilary Hutchinson ve Xin Fu'nun CHI 2010'da yayımlanan makalesinde tanımlandı 6. Makale, sayfa görüntüleme, çalışma süresi, gecikme, yedi günlük aktif kullanıcı ve gelir gibi yaygın iş ve teknik metriklerin (yazarların deyişiyle PULSE) kullanıcı deneyimini yalnız dolaylı ölçtüğünü savunur. Örneğin bir özelliğin sayfa görüntülemesindeki artış, özelliğin sevilmesinden de, kullanıcının kafası karışıp çıkış yolu aramasından da kaynaklanabilir 6.

HEART beş kategoriden oluşur 6:

• Happiness (memnuniyet): Memnuniyet, görsel beğeni, tavsiye etme eğilimi ve algılanan kullanım kolaylığı gibi tutumsal metrikler; genellikle düzenli bir anketle toplanır.
• Engagement (bağlılık): Belirli bir süredeki etkileşim sıklığı, yoğunluğu ya da derinliği; toplam sayı yerine kullanıcı başına ortalama olarak raporlanması önerilir.
• Adoption (benimseme): Belirli bir dönemde ürünü ya da özelliği kullanmaya başlayan yeni kullanıcılar.
• Retention (elde tutma): Bir dönemdeki kullanıcılardan sonraki bir dönemde hâlâ aktif olanlar.
• Task success (görev başarısı): Görev süresi, tamamlanan görev yüzdesi ve hata oranı gibi geleneksel davranışsal metrikler.

Makale, her kategoriden metrik kullanmanın her zaman uygun olmadığını açıkça belirtir; çerçeve, bir kategoriyi dahil etme ya da dışarıda bırakma kararını bilinçli vermeye yarar. Örneğin kullanıcıların işleri gereği kullandığı kurumsal bir üründe Engagement anlamlı olmayabilir 6. Yazarlar ayrıca bu büyük ölçekli metriklerin yayındaki ürünleri değerlendirmek için yararlı olduğunu, erken dönem kullanıcı araştırmasının yerine geçmediğini vurgular 6.

Hedef, sinyal, metrik: doğru metriği seçmek

HEART makalesinin belki de en kullanışlı parçası, metrik seçimi için önerdiği üç adımlı süreçtir 6:

1. Hedef: Ürünün ya da özelliğin kullanıcı deneyimi açısından neyi başarması gerektiğini yazın. Ekip içindeki farklı görüşleri bu aşamada toplayın; bir özelliğin hedefi ürünün genel hedefinden farklı olabilir.
2. Sinyal: Hedefe ulaşıldığında kullanıcı davranışında ya da tutumunda neyin değişeceğini belirleyin. Sinyal, hedefe duyarlı ve özgü olmalı; deneyim iyileştiğinde ya da kötüleştiğinde hareket etmeli, alakasız nedenlerle değil. Bazen başarısızlığı yakalamak daha kolaydır: görevin yarıda bırakılması, geri alma eylemleri gibi.
3. Metrik: Sinyali zaman içinde izlenebilecek bir sayıya çevirin. Ham sayılar kullanıcı tabanı büyüdükçe artacağı için oran, yüzde ya da kullanıcı başına ortalama genellikle daha anlamlıdır.

Örnek: bir faturalama panelinde yeni "toplu fatura" özelliği için hedef "kullanıcılar çok sayıda faturayı daha az emekle kesebilsin" olabilir. Sinyal, toplu fatura akışını başlatıp tamamlayan kullanıcılar ve akışın yarıda bırakılmasıdır. Metrikler ise haftalık aktif kullanıcılar içinde özelliği kullananların oranı (Adoption), akışın tamamlanma oranı (Task success) ve özellik sonrası kısa bir memnuniyet sorusunun ortalamasıdır (Happiness). Bu örnek yöntemi göstermek içindir; hedef değerler ürününüzün kendi verisinden çıkmalıdır. Panel ekranlarında bu metriklerin nasıl gösterileceğini dashboard tasarımı yazısında ele aldık.

Örneklem büyüklüğü ve sık yapılan hatalar

Nitel ve nicel çalışmalar farklı sayıda katılımcı ister. NN/g, nitel testlerde toplanan metriklerin çoğu zaman yanıltıcı olduğunu ve genel kitleye genellenemeyeceğini, nicel çalışmalarda ise genellikle 30'dan fazla, dar güven aralıkları için 40 ya da daha fazla katılımcı gerektiğini belirtir 3. Nielsen'in 2001 tarihli metrik yazısında önerilen sayı 20 idi 2; güncel öneri daha yüksektir. Katılımcı sayısı konusunu kaç kullanıcıyla test yapılmalı yazısında ayrıca tartıştık.

Sık yapılan hatalar:

• SUS puanını yüzde gibi okumak. 70 puan "yüzde 70 memnuniyet" demek değildir 4.
• Başarı düzeylerinin ortalamasını almak. Düzey numaraları etikettir, puan değildir 1.
• Beş kişilik nitel testten yüzde raporlamak. Bu sayılar genellenemez 3.
• Belirsiz metrikleri deneyim göstergesi saymak. Sayfa görüntülemesindeki artış iyi de kötü de olabilir 6.
• Kaynağı belirsiz karşılaştırma değerleri kullanmak. Hedef değer, ya kendi önceki ölçümünüzden ya da yöntemi açık bir kaynaktan gelmelidir.

Ürününüz için görev senaryolarını, başarı kriterlerini ve SUS ölçümünü içeren bir test planlamak isterseniz kullanılabilirlik testi hizmetimize göz atabilirsiniz.