Nielsen'in 10 İlkesi: Kontrol Listesi Değil, Değerlendirme Aracı

Jakob Nielsen ile Rolf Molich'in on maddesi, kullanılabilirlik alanının en çok alıntılanan listesi. Alıntılanma biçimi ise çoğu zaman yanlış: maddeler bir tasarımın uyması gereken kurallar gibi okunuyor. Oysa liste, bitmiş bir arayüzde sorun bulmak için geliştirilmiş bir inceleme aracı. Ne tasarımı üretir, ne de tek tek işaretlenip geçilir.

Sezgisel değerlendirme ne yapar

Yöntem, kullanıcı testinin ucuz alternatifi olarak doğdu. Katılımcı bulmadan, laboratuvar kurmadan, birkaç değerlendiricinin arayüzü tek başına gezip sorunları not etmesine dayanıyor. On madde bu sırada iki işe yarıyor: incelemeye yön verir ve bulunan sorunun neden sorun olduğunu adlandırır.

Çıktısı sorun listesidir, çözüm listesi değil. "Sistem durumunun görünürlüğü ihlal edilmiş" cümlesi hangi geri bildirimi nereye koyacağını söylemez; onu tasarımcı karar verir. Yöntemi çözüm üreticisi sanmak, ekiplerin en sık düştüğü yer. Nielsen'in maddeleri tanıttığı metin de bunu açıkça söylüyor.

Kaç kişi, nasıl

1. Her değerlendirici arayüzü tek başına gezer. Birlikte gezmek ilk konuşanın çerçevesini herkese bulaştırır.
2. İki tur yapılır: ilkinde akış baştan sona kullanılır, ikincisinde tek tek ekranlara dönülür.
3. Bulgular sonra bir araya getirilir, tekrar edenler birleştirilir.
4. Her bulguya sıklık ve ciddiyet notu verilir. Notsuz liste, ekibin en kolay maddeden başlamasıyla sonuçlanır.

Tek değerlendirici sorunların yaklaşık üçte birini yakalar; Nielsen bu yüzden üç ila beş kişilik bir grup önerir. Aynı kişinin listeyi ikinci kez gözden geçirmesi bu açığı kapatmaz, çünkü ikinci turda kendi ilk turunun körlüğünü taşır.

Maddeler birbiriyle çatışır

On ilkeyi kontrol listesi gibi okuyunca ortaya çelişki çıkıyor, çünkü liste kendi içinde gerilimli. Hata önleme, kritik işlemlere onay adımı koymayı söyler; esneklik ve verimlilik, aynı onayın günde otuz kez o işlemi yapan kullanıcıyı yavaşlattığını söyler. Minimalist tasarım ekrandan öğe çıkarmayı söyler; tanımanın hatırlamaya üstünlüğü ise ipucunu ekranda tutmayı.

Bu çelişkiler kusur değil, kararın nerede verileceğini gösteren işaretler. Onay diyaloğu geri alınamaz işlemlerde kalır, geri alınabilir olanda kalkar ve yerine geri alma gelir. İpucu kullanıcının haftada bir uğradığı ekranda kalır, günde on kez girdiği ekranda kalkar. Ölçü, ilkenin kendisi değil; işlemin sıklığı ve hatanın maliyeti.

Bulgunun koda maliyeti

Değerlendirme raporları maliyeti nadiren ayırt eder, oysa aradaki fark büyük. Bir yükleme animasyonu koymak arayüz tarafında yarım saatlik iş; sunucunun işin gerçekten yüzde kaçının bittiğini raporlaması ise ayrı bir mesele, çoğu zaman kuyruk yapısına dokunmayı gerektirir (tasarım incelemelerinde en çok atlanan kalem bu). Sahte ilerleme çubuğu koymak da sorunu çözmez, sadece yerini değiştirir.

Aynı ayrım geri alma için de geçerli. Ekrana "Geri Al" düğmesi eklemek kolaydır, arkasında işlemi tersine çevirebilen bir durum modeli olmadıkça düğme yalandır. Bu yüzden raporu iki kolonlu tutmak işe yarıyor: bulgunun ciddiyeti bir kolonda, uygulama maliyetinin kaba tahmini diğerinde. İki kolon yan yana durduğunda hangi maddenin bu sprintte çözüleceği tartışma konusu olmaktan çıkar.