Konu Başlıkları
Yükleniyor...

Web Tasarımda Kullanılabilirlik: Hangi Ölçüt Gerçekten Ölçülüyor

Usability Nedir, Nasıl Ölçülür? Kullanılabilirlik Ölçütleri

Kullanılabilirlik, bir arayüzün kullanıcıyı hedefine ne kadar az sürtünmeyle götürdüğünü anlatır. Tanım üzerinde uzlaşma var, ölçüm üzerinde yok: klasik beş ölçütün ikisi elinizdeki veriden çıkar, kalan üçü için kullanıcıyı izlemek ya da ona sormak gerekir. Bu ayrımı atlayan her kullanılabilirlik raporu, ölçmediği şeyler hakkında da konuşuyor demektir.

Beş ölçüt, ikisi loglardan çıkar

Kullanılabilirlik genelde beş başlıkta toplanır: öğrenilebilirlik, verimlilik, hatırlanabilirlik, hata oranı, memnuniyet. Liste doğru. Sorun, beşinin aynı yöntemle ölçülebiliyormuş gibi sunulması.

  • Verimlilik ve hata oranı mevcut veriden çıkar. Bir görevin kaç adımda bittiği, formun hangi alanında kaç kez doğrulama hatası döndüğü, kullanıcının kaç kez geri tuşuna bastığı. Bunlar zaten kaydediliyor, çoğu yerde kimse bakmıyor.
  • Öğrenilebilirlik ve hatırlanabilirlik aynı kişinin iki farklı zamandaki halini karşılaştırmayı gerektirir. Panelde gördüğünüz "geri dönen ziyaretçi" oranı bunu vermez; kimin geri geldiğini söyler, arayüzü hatırlayıp hatırlamadığını değil.
  • Memnuniyet sorulmadan bilinmez. Sitede geçirilen süre memnuniyet göstergesi değil; aynı sayı hem ilgiyi hem kaybolmayı anlatabilir.

Pratik sonucu şu: kullanılabilirliği yalnızca panele bakarak yönetirseniz elinizde ikisi kalır, beşini ölçtüğünüzü sanarak konuşursunuz.

Hız bir ölçüt değil, ölçümün önkoşulu

"Üç saniyede açılmayan sayfada kullanıcıların yarısı gider" cümlesi her yerde dolaşıyor, kaynağı gösterilmiyor. Yüzdeyi bir kenara bırakın. Hız kullanılabilirliğin ölçütü değil, ölçülebilmesinin önkoşulu: açılmayan sayfada navigasyonun sade olması hiçbir şey ifade etmez.

Ölçmek için iki sayı yeter. Sunucunun ilk baytı göndermesi (TTFB) ve ekrandaki en büyük içeriğin görünmesi (LCP). Birincisi altyapı tarafındadır, ikincisi çoğu zaman ön yüzde: sıkıştırılmamış görsel, geç gelen font, render bloklayan üçüncü parti script. Aynı sayfada TTFB 80 milisaniye, LCP 4 saniye olabilir. O tabloda sunucu değiştirmek hiçbir şeyi düzeltmez, ama satılan çözüm genelde budur.

Arama motoru kullanılabilirliği göremez

Google'ın kullanılabilirliği sıralama sinyali olarak kullandığı söylenir. Tam olarak öyle değil. Tarayıcı sizin menü hiyerarşinizin mantıklı olup olmadığını bilemez; ölçebildiği vekilleri ölçer. Core Web Vitals dediğimiz LCP, CLS ve INP, yükleme ve tepki tarafındaki teknik davranışı anlatır, bilgi mimarisini değil.

Yani sayfayı hızlandırmak ve kaydırma sıçramalarını gidermek sıralamaya yardım eder, kullanıcının aradığını bulamadığı bir siteyi kurtarmaz. İki ayrı iş. Birini yapıp diğerini de yaptığını sanmak çok kolay.

Araçlar neyi verir, neyi vermez

Performans tarafında Pingdom, WebPageTest ve Lighthouse aşağı yukarı aynı işi görür (Lighthouse'un tek seferlik mobil skoruna olduğundan fazla anlam yükleniyor). Oturum kaydı ve geri bildirim araçları kullanıcının nerede takıldığını gösterir, nedenini söylemez. Nedeni öğrenmenin ucuz yolu hâlâ değişmedi: beş kişiye görevi verip kendiniz susmak. Kullanıcı deneyimi literatürü bu noktada net; küçük örneklem, gözlemlenmiş davranışla birleştiğinde büyük anketten daha çok şey söyler.

Sınırlı zamanınız varsa sıra

Önce formlardaki hata oranı. Hem ölçülebilir hem doğrudan para kaybettiren yer orası, üstelik düzeltmesi çoğu zaman birkaç saatlik iş. Sonra LCP, çünkü ondan sonraki her iyileştirme onun üstüne biniyor. Kullanıcı testi listenin sonunda değil aslında, sadece pahalı olduğu için sona atılıyor. Menü yapısını baştan kurmak ise en çok tartışılan konu olmasına rağmen çoğu sitede en son gelmeli: değiştirmesi en riskli, ölçmesi en zor kalem o.