Sezgisel Değerlendirme: Nielsen'in 10 İlkesi Örneklerle

Sezgisel değerlendirme (heuristic evaluation), kullanılabilirlik sorunlarını kullanıcıyla test yapmadan bulmanın en yaygın yoludur. Prototip aşamasında bile uygulanabilir, kısa sürer ve bir ekibin kullanılabilirlik gözünü geliştirir. Bu yazı Nielsen'in 10 ilkesini Türkçe arayüz örnekleriyle açıklıyor, değerlendirmenin adımlarını ve yöntemin sınırlarını anlatıyor.

Sezgisel değerlendirme nedir?

Nielsen yöntemi, küçük bir değerlendirici grubunun arayüzü inceleyip kabul görmüş kullanılabilirlik ilkelerine uygunluğunu yargıladığı bir kullanılabilirlik mühendisliği yöntemi olarak tanımlıyor 3. "Sezgisel" (heuristic) kelimesi, ilkelerin ayrıntılı kurallar değil, geniş kapsamlı genel kurallar olduğunu anlatır 1.

İlkeler 1990'da Rolf Molich ile birlikte geliştirildi; Nielsen 1994'te 249 kullanılabilirlik sorununun faktör analizine dayanarak listeyi bugünkü hâline getirdi 1. NN/g 2020'de makaleye açıklama ve örnekler ekledi, tanımların dilini biraz düzeltti, ama 10 ilkenin kendisi 1994'ten beri değişmedi; makale en son Ocak 2024'te gözden geçirildi 1.

Nielsen'in 10 ilkesi ve Türkçe örnekler

Aşağıdaki tanımlar NN/g'deki güncel metne dayanıyor 1; örnekler ise belirli bir ürüne ait değil, yaygın arayüz durumlarından kurgulanmıştır.

1. Sistem durumunun görünürlüğü. Tasarım, kullanıcıyı uygun geri bildirimle ve makul bir sürede neler olduğu hakkında bilgilendirmelidir. Örnek: bir para transferi uygulamasında "Gönder"e basıldıktan sonra ekran birkaç saniye hiçbir şey göstermezse kullanıcı butona ikinci kez basabilir. "İşleminiz gönderiliyor" gibi bir durum ve ardından açık bir sonuç ekranı bu belirsizliği giderir.

2. Sistem ile gerçek dünya arasında uyum. Tasarım kullanıcının dilini konuşmalı, iç jargon yerine tanıdık kelimeler kullanmalıdır. Örnek: bir kargo uygulamasında "Transfer merkezinde, hat ataması bekleniyor" ifadesi şirket içi bir süreci anlatır; kullanıcı için "Paketiniz aktarma merkezinde, yarın dağıtıma çıkması bekleniyor" daha anlaşılırdır.

3. Kullanıcı kontrolü ve özgürlüğü. Kullanıcılar sık sık yanlışlıkla işlem yapar; uzun bir süreçten geçmeden çıkabilecekleri açık bir "acil çıkış" gerekir. Örnek: yemek siparişi uygulamasında sepetten yanlışlıkla silinen ürün için birkaç saniye görünen "Geri al" seçeneği, kullanıcıyı ürünü yeniden aramaktan kurtarır.

4. Tutarlılık ve standartlar. Kullanıcı farklı kelimelerin ya da eylemlerin aynı şeyi ifade edip etmediğini düşünmek zorunda kalmamalı; platform ve sektör alışkanlıklarına uyulmalıdır. Örnek: bir uygulamanın bir ekranında "Kaydet", diğerinde "Onayla", üçüncüsünde "Tamam" aynı işi yapıyorsa kullanıcı aralarında fark olup olmadığını merak eder.

5. Hata önleme. İyi hata mesajları önemlidir, ama en iyisi sorunu baştan önlemektir: hataya açık durumları ortadan kaldırmak ya da kullanıcı işlemi tamamlamadan önce bir onay sunmak. Örnek: randevu uygulamasında dolu saatlerin seçilebilir görünmesi ve kullanıcının ancak son adımda "Bu saat dolu" uyarısı alması yerine dolu saatlerin baştan seçilemez gösterilmesi.

6. Hatırlamak yerine tanıma. Kullanıcının bellek yükü, öğeleri ve seçenekleri görünür kılarak azaltılmalıdır. Örnek: fatura ödeme ekranında abone numarasını kullanıcının ezbere yazmasını beklemek yerine daha önce kaydedilmiş faturaları adlarıyla listelemek.

7. Kullanım esnekliği ve verimliliği. Acemi kullanıcıdan gizlenmiş kısayollar deneyimli kullanıcıyı hızlandırabilir; sık yapılan işlemler kişiselleştirilebilmelidir. Örnek: bir yönetim panelinde her gün aynı raporu açan kullanıcının bu raporu filtreleriyle birlikte kaydedip tek dokunuşla açabilmesi.

8. Estetik ve minimalist tasarım. Arayüz alakasız ya da nadiren gereken bilgi içermemelidir; her fazladan bilgi asıl bilgiyle yarışır. NN/g bunun düz tasarım zorunluluğu anlamına gelmediğini vurguluyor. Örnek: bir alışveriş uygulamasının ödeme ekranında kampanya bantları, öneri kartları ve bülten kutusu, toplam tutarın ve "Siparişi tamamla" butonunun önüne geçmemelidir.

9. Kullanıcıların hataları tanımasına, teşhis etmesine ve düzeltmesine yardım. Hata mesajları sade bir dille yazılmalı, hata kodu içermemeli, sorunu tam olarak göstermeli ve yapıcı bir çözüm önermelidir. Örnek: "Hata: 4012" yerine "IBAN'ınız TR ile başlamalı. Girdiğiniz numarada eksik hane var gibi görünüyor." Bu konuyu boş durum ve hata mesajları yazısında ayrıntılı ele alıyoruz.

10. Yardım ve dokümantasyon. En iyisi sistemin ek açıklamaya ihtiyaç duymamasıdır; ama yardım gerekiyorsa aranabilir, kullanıcının görevine odaklı ve somut adımlar içeren biçimde, mümkünse ihtiyaç anında sunulmalıdır. Örnek: e-fatura ayarları ekranındaki teknik bir alanın yanında, ayrı bir yardım merkezine yönlendirmek yerine kısa bir açıklama göstermek.

Değerlendirme nasıl yapılır?

NN/g'nin adım adım rehberi ve Nielsen'in yöntem açıklaması birlikte şu süreci tarif ediyor 2 3:

1. Değerlendiricileri seçin ve hazırlayın. İdeal olarak üç ila beş kişi. İlk kez yapılıyorsa herkes ilkeleri okusun ve basit bir arayüz üzerinde birlikte bir deneme yapılsın 2.
2. Kapsamı daraltın. Tek bir görev, uygulamanın tek bir bölümü, tek bir kullanıcı grubu ya da tek bir cihaz türü. Kapsam ne kadar darsa değerlendirme o kadar ayrıntılı olur 2.
3. Kayıt biçimini belirleyin. Çalışma kitabı, tablo ya da dijital beyaz tahta. Ortak bir alan kullanıyorsanız değerlendiriciler kendi değerlendirmeleri bitene kadar birbirlerinin notlarını görmemeli 2.
4. Bağımsız değerlendirin. Her değerlendirici yaklaşık bir ila iki saat ayırır; arayüzden en az iki kez geçer. İlk geçiş akışı ve kapsamı tanımak, ikincisi tek tek öğeleri ilkelere göre incelemek içindir 2 3.
5. Her sorunu ayrı yazın ve gerekçelendirin. "Beğenmedim" yetmez; hangi ilkeyi neden ihlal ettiği yazılmalı. Bir öğede üç sorun varsa üçü ayrı ayrı listelenir 3.
6. Bulguları birleştirin. Herkes bitirdikten sonra benzer sorunlar kümelenir; hangi konularda hemfikir olunduğu, hangilerinin en zararlı olduğu ve hangilerinin kullanıcı testinde ayrıca incelenmesi gerektiği tartışılır 2.
7. Önem derecesi verin. Aşağıda anlatıldığı gibi.

Alana özgü bir uygulamada değerlendiriciler alanı tanımıyorsa, gerçek kullanıcıların görevlerine dayanan tipik bir kullanım senaryosu vermek ve alanla ilgili sorularını cevaplamak değerlendirmeyi güçlendirir 3.

Neden birden fazla değerlendirici?

Nielsen'in altı projesinin ortalamasında tek bir değerlendirici sorunların yalnız yüzde 35'ini bulmuş 3. Farklı kişiler farklı sorunları yakalar ve en zor bulunan sorunlar bazen genel olarak az sorun bulan değerlendiricilerden gelir; bu yüzden "en iyi değerlendiriciyi" seçip yalnız ona güvenmek de işe yaramaz 3. Nielsen'in önerisi en az üç, tercihen beş değerlendiricidir; kullanılabilirliğin kritik olduğu sistemlerde daha fazlası kullanılabilir 3.

Tek kişilik değerlendirmelerin listesi küçük sorunlarla dolma eğilimindedir. Nielsen'in altı vaka çalışmasında yöntem 59 büyük ve 152 küçük sorun bulmuş; tek bir değerlendiricinin belirli bir büyük sorunu bulma olasılığı ortalama yüzde 42, küçük bir sorunu bulma olasılığı yüzde 32 5. Önem derecesi bu yüzden yöntemin vazgeçilmez tamamlayıcısıdır.

Önem derecesi vermek

Bir sorunun önemi üç etkenden oluşur: sıklık, etki ve süreklilik; bunlara pazar etkisi de eklenebilir 4. Nielsen'in 0-4 ölçeğinde 0 "sorun olduğu konusunda hemfikir değilim", 1 kozmetik, 2 küçük, 3 büyük, 4 ise yayından önce mutlaka düzeltilmesi gereken bir kullanılabilirlik felaketidir 4.

Nielsen, değerlendiricilerin sorun ararken iyi önem tahmini yapmakta zorlandığını, bu yüzden tüm sorunların birleştirilmiş listesinin oturumlardan sonra değerlendiricilere gönderilip puanların bağımsız olarak toplanmasını öneriyor; bu genellikle yaklaşık 30 dakika sürer 4. Tek bir kişinin puanları güvenilir değildir; üç değerlendiricinin ortalaması pratikte çoğu amaç için yeterlidir 4.

Sınırları: kullanıcı testinin yerini tutmaz

Sezgisel değerlendirme bariz sorunları bulmakta güçlüdür, sınırlı araştırma bütçesini esnetir ve tasarım sürecinin başında bile uygulanabilir; ama kullanıcı araştırmasının yerini alamaz 2. Kullanıcı deneyimi bağlama çok bağlıdır. NN/g'nin verdiği örnekte mobil sitede menüyü bir simgenin arkasına gizlemek hatırlamak yerine tanıma ilkesini ihlal eder, ama küçük ekranda bu çoğu zaman gerekli bir ödünleşimdir; bir ihlalin düzeltilmesi gerekip gerekmediği bağlama ve alternatiflere bağlıdır 2. Bilerek bir ilkeyi ihlal etmeden önce kararınızı kullanıcı araştırmasıyla doğrulamanız öneriliyor 2.

İki yöntem farklı sorun kümeleri bulur. Sezgisel değerlendirme, kullanıcı testinde ancak çok dikkatli bir analizle görülebilecek küçük tutarsızlıkları yakalar; buna karşılık değerlendiriciler alanı iyi tanımıyorsa alana özgü sorunları kaçırabilir 5. Nielsen'in önerdiği sıra, önce sezgisel değerlendirmeyle bariz sorunları temizlemek, tasarımı düzeltmek, ardından kalan sorunları bulmak için kullanıcılarla test etmektir 5. Böylece bulması zor katılımcılar bilinen sorunları yeniden göstermek için harcanmaz.

Değerlendirmeden rapora

Değerlendirmenin çıktısı, her biri bir ilkeye bağlanmış ve önem derecesi verilmiş sorunların listesidir. Yöntem doğrudan çözüm üretmez; ama sorun bir ilkeyle açıklandığı için düzeltme yönü çoğu zaman kendiliğinden belirir 3. Nielsen, son oturumdan sonra değerlendiricilerin ve tasarım ekibinin katıldığı bir toplantıda olası yeniden tasarımları tartışmayı ve tasarımın iyi yanlarını da konuşmayı öneriyor 3.

Bulguların bir raporda nasıl göründüğünü örnek UX denetimi sayfasında, ürününüz için hızlı bir ilk bakışı UX ön kontrol aracında görebilirsiniz. Birden fazla değerlendiriciyle yapılan kapsamlı bir inceleme için UX denetimi sayfamıza bakabilirsiniz.