UX audit nedir, nasıl yapılır?

Kısaca

UX audit, ürününüze kullanıcı gözüyle ama elinizde bir ölçüt listesiyle bakmaktır. Bir akışı baştan sona kullanırım ve takıldığım her yeri not ederim. Sonra her notu bir ilkeye bağlayıp yanına bir düzeltme önerisi yazarım.

Audit'in çekirdeği Nielsen'in 10 kullanılabilirlik ilkesi ile yapılan heuristik değerlendirmedir. Jakob Nielsen bu ilkeleri 1990'da Rolf Molich ile geliştirdi, 1994'te bugünkü haline getirdi. Bunun üstüne akış, erişilebilirlik, içerik ve hız kontrolleri eklenir.

Audit kullanıcı testinin yerini tutmaz. NN/g'nin heuristik değerlendirme rehberi de bunu açıkça yazar: yöntem olası sorunları ucuza bulur ama kullanıcı araştırmasının yerine geçmez. Audit nereye bakacağınızı söyler, gerçek kullanıcı ise neden takıldığını gösterir.

• Kapsam tek bir akış da olabilir, ürünün tamamı da.
• Her bulgu bir ekrana, bir ilkeye ve bir önem derecesine bağlanır.

Ne zaman gerekir, ne zaman gerekmez

Audit en çok, bir şeyin ters gittiğini bildiğiniz ama nerede olduğunu bilmediğiniz anda işe yarar. Ödeme adımında terk artmıştır ya da destek talepleri hep aynı ekranı gösterir.

Şu durumlarda audit öneririm:

• Büyük bir yeniden tasarıma girmeden önce. Neyin bozuk olduğunu bilmeden yeniden çizmek, bozukluğu yeni ekrana taşır.
• Bir akışın sayıları düştüğünde. Analitik size nerede düştüğünü söyler, audit nedenini aramaya başlar.
• Yayından önce. Önem derecesi 4 olan bir sorunla yayına çıkmak, ilk kullanıcıları kaybetmeyi göze almak demektir.
• Ekip ürüne fazla alıştığında. Her gün aynı ekrana bakan biri, yeni gelenin takıldığı yeri artık görmez.

Şu durumlarda audit gerekmez ya da yetmez:

• Henüz ortada arayüz yoksa. O aşamada bir prototip ya da kullanıcı görüşmesi daha çok şey söyler.
• Asıl soru "doğru ürünü mü yapıyoruz" ise. Audit ürünün kolay kullanılıp kullanılmadığına bakar. Pazarın onu isteyip istemediği başka bir araştırmanın konusudur.
• Bulguları düzeltecek kimse yoksa. Uygulanmayan bir audit, çekmecede bekleyen bir PDF olarak kalır.

Kapsam: audit neye bakar

Audit beş alana bakar ama hepsi her işte aynı ağırlıkta değildir. Bir ödeme akışında akış analizi öne çıkar, bir içerik sitesinde içerik ve bilgi düzeni.

1. Heuristik değerlendirme

Her ekranı 10 ilkeyle tek tek karşılaştırırım. Örneğin sistem ne yaptığını gösteriyor mu, kullanıcı yanlış adımı geri alabiliyor mu? Bir ilke çiğneniyorsa bunu bulgu olarak yazarım.

Bir belediye uygulamasında borç sorgulayınca ekranda yalnızca "İşleminiz alınmıştır" yazdığını düşünün. Bu ekran, sistem durumunun görünür olması ilkesini çiğner. Kullanıcı işlemin bitip bitmediğini bilemez ve aynı butona yeniden basar.

NN/g burada bir uyarı yapar: bir ilkenin çiğnenmesi her zaman sorun değildir, doğru seçim bağlama göre değişir. Bu yüzden her bulguda önce kullanıcıya çıkan maliyeti yazarım. Hangi kuralın bozulduğu ikinci bilgidir.

2. Akış analizi

Kullanıcının bir işi bitirmek için geçtiği adımları tek tek sayarım. Gereksiz bir ekran var mı, aynı bilgi iki kez isteniyor mu? Bir de akışın, kullanıcının zihinsel modeline yani işin nasıl yürüyeceğine dair beklentisine uyup uymadığına bakarım.

Bunun en bilinen örneği 300 milyon dolarlık buton hikayesidir. Jared Spool'un 2009'da anlattığı vakada, sepeti dolduran alışverişçi ödemeden önce bir giriş ya da kayıt formuna takılıyordu. Spool'a göre "Kayıt ol" butonu kaldırılıp yerine "Devam" konunca satın almalar %45 arttı.

Böyle bir sorun tek tek ekranlara bakınca görünmez. Form kendi başına düzgündür. Sorun, formun akıştaki yerindedir.

3. Erişilebilirlik

Ölçüt W3C'nin WCAG 2.2 standardıdır. WCAG dört ilkeye dayanır: algılanabilir, işletilebilir, anlaşılabilir ve sağlam. Üç uyum seviyesi vardır: en düşük A, sonra AA ve en yüksek AAA.

Audit'te en temel ölçütleri kontrol ederim. Birkaç örnek:

• Normal metinde kontrast en az 4,5:1, büyük metinde en az 3:1 olmalı (WCAG 2.2, 1.4.3).
• Dokunma ve tıklama hedefleri en az 24 × 24 CSS piksel olmalı ya da yeterli boşlukla ayrılmalı (2.5.8, WCAG 2.2 ile geldi).
• Klavyeyle odağa gelen öğe, yapışkan başlık ya da çerez bandı gibi bir içeriğin altında tamamen kaybolmamalı (2.4.11).
• Girişte şifre hatırlamak ya da bulmaca çözmek gibi bir bilişsel test zorunluysa, bir alternatif ya da yardımcı yol sunulmalı (3.3.8).

Bunlara bir de klavye turu eklerim. Fareyi bırakıp akışı yalnızca Tab ve Enter tuşlarıyla bitirmeye çalışırım. Odak halkası görünmüyorsa ya da bir menüden çıkılamıyorsa bulgu olarak yazarım.

Bu kontroller tam bir erişilebilirlik uyum denetimi değildir. Ama sık görülen ve birçok kişiyi dışarıda bırakan sorunları yakalar.

4. İçerik

Arayüzdeki metinleri okurum: buton etiketleri, hata mesajları, boş durumlar, form yardımları. Metin kullanıcının dilini mi konuşuyor, yoksa ekibin iç jargonunu mu? "İşlem başarısız" yazan bir hata, kullanıcıya ne yapacağını söylemez.

Bir banka uygulamasında para gönderme ekranındaki alanın adı "Alıcı IBAN" değil de "Karşı hesap tanımı" olsun. Kullanıcı bu alanın ne istediğini tahmin etmek zorunda kalır. İçerik kontrolünde böyle etiketleri listeler, her birine kullanıcının kendi kelimesiyle bir karşılık öneririm.

Menülere ve başlıklara da burada bakarım. Kullanıcı aradığı şeyi beklediği yerde bulamıyorsa sorun çoğu zaman bilgi mimarisindedir.

5. Performans

Yavaşlık, iyi tasarlanmış bir sayfayı da kullanılmaz hale getirebilir. Burada Google'ın Core Web Vitals ölçütlerine bakarım. web.dev "iyi" sayılan eşikleri, sayfa yüklemelerinin 75. yüzdelik dilimi için şöyle verir:

• LCP (en büyük içeriğin yüklenmesi): 2,5 saniye ya da daha az.
• INP (etkileşime tepki): 200 milisaniye ya da daha az.
• CLS (görsel kayma): 0,1 ya da daha az.

Bu değerler gerçek kullanıcıların deneyimlerinin dağılımından gelir. Kendi bilgisayarınızda ölçtüğünüz sonuç, bu dağılımda yalnızca tek bir noktadır.

web.dev, eşiklerin mobil ve masaüstü için ayrı ayrı değerlendirilmesini önerir. Bu yüzden audit'te mobil sonuca ayrıca bakarım. Mühendislik raporu yazmam, kullanıcının hissettiği yere odaklanırım: butona basınca bir şey oluyor mu, sayfa yüklenirken içerik kayıyor mu?

Adım adım UX audit nasıl yapılır

Şekil: Bir audit'in beş aşaması. Her kutu aşağıdaki numaralı adımlardan birine karşılık gelir.

1. Kapsamı yazın. NN/g, değerlendirmeyi tek bir göreve, bölüme, kullanıcı grubuna ya da cihaza daraltmayı önerir. "Mobilde misafir olarak ödeme" iyi bir kapsamdır, "tüm site" ise çok geniştir.

2. Hedefi ve eldeki veriyi toplayın. Akışın amacı ne, başarı neye göre ölçülüyor? Analitikte bir düşüş noktası ya da destek taleplerinde tekrar eden bir şikayet varsa, audit'e başlamadan görmek isterim.

3. İlk geçiş: ürünü öğrenin. NN/g'nin önerdiği gibi ilk turda henüz değerlendirme yapmam, ürünü tanırım. Kullanıcının yapacağı işi gerçeğe yakın veriyle baştan sona bir kez bitiririm.

4. İkinci geçiş: sorunları yazın. Bu turda her ekranı ilkeler ve erişilebilirlik ölçütleriyle karşılaştırır, metinleri tek tek okurum. Her bulguyu ekran görüntüsü ve ilgili ilkeyle birlikte ayrı bir satıra yazarım.

5. Bulguları birleştirin. Aynı kökten gelen sorunları tek bulguda toplarım. Beş ekranda tekrar eden belirsiz bir hata mesajı, tek bir sistem sorunu olarak yazılır.

6. Önem derecesi verin. Her bulguya aşağıda anlattığım 0–4 ölçeğinden bir derece veririm. Nielsen'e göre derece üç şeyden oluşur: sorunun sıklığı, aşmanın zorluğu ve kalıcılığı. Bunlara pazardaki etkisi de eklenir.

7. Düzeltme önerin. "Bu kötü" demek yetmez. Her bulgunun yanına yeni bir metin ya da alanın yeni yeri gibi somut bir öneri yazarım. Ekip bulguyu okuyup aynı gün işe başlayabilmeli.

8. Sıraya koyun ve teslim edin. Liste önem derecesine ve düzeltme maliyetine göre sıralanır. Ben bunu bir Loom videosu ve yazılı listeyle teslim ederim. Ekranda gösterilen bir sorun, yazılı anlatımdan daha hızlı anlaşılır.

Bir bulgu nasıl yazılır?

Her bulguyu aynı kalıpla yazarım. Böylece ekip listeyi hızla tarayabilir, çünkü aradığı bilgi her kartta aynı yerdedir.

• Başlık: sorunun kendisi, tek cümleyle ve kullanıcı açısından.
• Yer: akış, adım ve ekran. Mümkünse ekran görüntüsü.
• Ne oluyor: kullanıcının yaşadığı şey, iki üç cümlede.
• İlke: hangi kullanılabilirlik ilkesine ya da WCAG ölçütüne dokunduğu.
• Önem derecesi: 0–4 arası, neden o derece olduğuyla birlikte.
• Öneri: ekibin uygulayabileceği somut bir değişiklik.

"Kupon validasyonu hatalı" bir geliştirici notudur. "Kupon hatası görünmüyor" ise kullanıcı açısından yazılmış, ekipteki herkesin anladığı bir başlıktır.

Çıktı neye benzer?

Audit'in sonunda elinizde iki şey olmalı. Birincisi, önem derecesine göre sıralanmış bulgu listesi. İkincisi, bu listeyi ekrandan gösteren bir anlatım: video ya da kısa bir sunum.

Listenin başında birkaç maddelik bir özet olur. Hangi sorunlar yayını bekletmeli, hangileri sonraya kalabilir? Yönetici yalnızca bu özeti okuyup karar verebilmelidir.

Ben listeyi önem derecesinin yanında düzeltme maliyetiyle de işaretlerim. Derecesi yüksek ve düzeltmesi ucuz bulgular en üste çıkar. Ekip ilk haftada en çok etkiyi bunlardan alır.

Ne kadar sürer?

Süreyi kapsam belirler. NN/g, her değerlendiricinin bağımsız çalışmasını yaklaşık 1–2 saatle sınırlamayı önerir. Nielsen'e göre önem derecelerini sonradan ayrı vermek, değerlendirici başına genelde 30 dakika kadar sürer.

Buna hazırlık, birleştirme ve raporlama eklenir. Tek bir akış için kendi UX Audit işimi 48 saat içinde teslim ediyorum. Ürünün tamamına bakmak daha uzun sürer.

Örnek bulgu kartı ve 0–4 önem derecesi ölçeği

Önem derecesi, sınırlı zamanınızı nereye harcayacağınızı söyler. Burada kullandığım ölçek, Jakob Nielsen'in 1994'te yayımladığı 0–4 ölçeğidir. Aşağıda kendi Türkçe karşılıklarımla veriyorum.

Derece	Adı	Ne demek
0	Sorun değil.	Değerlendiren kişi bunun bir kullanılabilirlik sorunu olduğuna hiç katılmıyor.
1	Kozmetik.	Yalnızca kozmetik bir sorun. Projede fazladan zaman kalmadıkça düzeltilmesi gerekmez.
2	Küçük sorun.	Küçük bir kullanılabilirlik sorunu. Düzeltmesine düşük öncelik verilir.
3	Büyük sorun.	Büyük bir kullanılabilirlik sorunu. Düzeltilmesi önemlidir, yüksek öncelik verilir.
4	Felaket.	Kullanılabilirlik felaketi. Ürün yayına çıkmadan önce düzeltilmesi şarttır.

Nielsen'in pratik bir notu var: arayüzde birkaç felaket düzeyinde sorun kaldıysa yayına çıkmak büyük olasılıkla doğru olmaz. Kalan sorunların hepsi kozmetikse yayına çıkılabilir.

Aşağıdaki kart, bir bulgunun nasıl yazıldığını gösteriyor. Derece değiştikçe ekibin bu bulguya ne kadar acil bakacağı da değişir.

Deneyin

Not 02 · Ürün sayfası

“Sepete ekle” butonu mavi olsun.

Ne oluyor: Bir ekip üyesi turuncu butonun mavi olmasını istedi. Butonun kontrastı yeterli, oturumdaki kullanıcıların hepsi onu hemen buldu ve kullandı.

İlgili ilke: Estetik ve sade tasarım (Nielsen, ilke 8). Bu ilke çiğnenmiyor, istek bir zevk tercihi.

Öneri: Değiştirmeyin. Notu bulgu listesinden çıkarın ve neden çıkardığınızı bir cümleyle yazın.

Önem: 0 · Sorun değil

Değerlendiren kişi bunun bir kullanılabilirlik sorunu olduğuna hiç katılmıyor.

Bulgu 11 · Sipariş özeti

Sepet ikonu yazıyla aynı hizada değil.

Ne oluyor: Sipariş özetinde sepet ikonu yanındaki yazıdan birkaç piksel aşağıda duruyor. Kimse bu yüzden takılmıyor ama ekran özensiz görünüyor.

İlgili ilke: Tutarlılık ve standartlar (Nielsen, ilke 4). Diğer ekranlarda ikonlar yazıyla ortalı.

Öneri: İkonu yazıyla ortalayın. Acele etmeyin, ekipte boş zaman olduğunda yapılabilir.

Önem: 1 · Kozmetik

Yalnızca kozmetik bir sorun. Projede fazladan zaman kalmadıkça düzeltilmesi gerekmez.

Bulgu 09 · Ödeme akışı · Adım 1 / 3

Seçili teslimat adresi zor fark ediliyor.

Ne oluyor: Kayıtlı adresler arasında seçili olan yalnızca ince gri bir çerçeveyle ayrılıyor. Kullanıcılar bir an duraksıyor ama doğru adresi seçip devam ediyor.

İlgili ilke: Sistem durumunun görünürlüğü (Nielsen, ilke 1).

Öneri: Seçili adrese belirgin bir işaret ve “Seçili” etiketi ekleyin.

Önem: 2 · Küçük sorun

Küçük bir kullanılabilirlik sorunu. Düzeltmesine düşük öncelik verilir.

Bulgu 07 · Ödeme akışı · Adım 2 / 3

Kupon hatası görünmüyor.

Ne oluyor: Geçersiz kupon girilince hata mesajı alanın yanında değil, sayfanın en üstünde çıkar. Mobilde sayfa aşağı kaydırılmış olduğu için kullanıcı mesajı görmez.

İlgili ilke: Kullanıcının hataları tanımasına, teşhis etmesine ve düzeltmesine yardım edin (Nielsen, ilke 9).

Öneri: Mesajı alanın hemen altına taşıyın ve alanı hatalı olarak işaretleyin.

Önem: 3 · Büyük sorun

Büyük bir kullanılabilirlik sorunu. Düzeltilmesi önemlidir, yüksek öncelik verilir.

Bulgu 01 · Ödeme akışı · Adım 3 / 3

Mobilde “Ödemeyi tamamla” butonu çalışmıyor.

Ne oluyor: Bazı telefonlarda butona dokununca hiçbir şey olmuyor. Ne yükleniyor işareti ne de hata mesajı çıkıyor. Kullanıcı siparişi veremiyor ve sayfadan çıkıyor.

İlgili ilke: Sistem durumunun görünürlüğü (Nielsen, ilke 1).

Öneri: Yayından önce düzeltin. Butonu mobil tarayıcılarda deneyin, dokunuşta yükleniyor durumu ve sorun çıkarsa açık bir hata mesajı gösterin.

Önem: 4 · Felaket

Kullanılabilirlik felaketi. Ürün yayına çıkmadan önce düzeltilmesi şarttır.

Bu örnek kartlar gerçek bir müşteri işinden alınmadı. Bir önem derecesi seçin, kart o dereceye uyan kendi örnek bulgusunu göstersin: başlık, ilke, öneri ve açıklama birlikte değişir. Ölçek, Jakob Nielsen'in 0–4 önem derecesi ölçeğinden uyarlandı.

İyi bir bulgu kartında dört şey olur: ne olduğu, nerede olduğu, hangi ilkeye dokunduğu ve ne yapılacağı. Bunlardan biri eksikse ekip kartı ya anlamaz ya da sıraya koyamaz.

Sık hatalar

Tek kişinin verdiği dereceye güvenmek. Nielsen, tek bir değerlendiricinin önem derecelerini güvenilir bulmaz ve üç kişinin ortalamasını çoğu pratik iş için yeterli sayar. NN/g ayrıca ideal olarak üç ila beş kişinin aynı arayüzü bağımsız değerlendirmesini önerir.

Değerlendirme sırasında derece vermek. Nielsen dereceleri değerlendirme oturumunda değil, sonradan toplamayı önerir. Oturumdayken dikkat yeni sorun bulmaya gider.

Kişisel zevki bulgu diye yazmak. "Bu rengi sevmedim" bir bulgu değildir. Her bulgunun bir ilkeye ve kullanıcıya çıkan bir maliyete bağlanması gerekir.

Sorunları sıralamadan teslim etmek. Önem derecesi olmayan 80 maddelik bir liste ekibi felç eder. Liste kısa ve sıralı olmalıdır.

Kapsamı açık bırakmak. "Siteye bir bakalım" diye başlayan audit, hiçbir akışa yeterince bakmadan biter.

Erişilebilirliği ayrı bir iş sanmak. Klavyeyle kullanılamayan bir form, herkes için de kötü bir formdur. Erişilebilirlik kontrolü audit'in parçası olmalıdır.

Ekran ekran bakıp akışı kaçırmak. Her ekran tek başına düzgün görünebilir. Sorun ekranlar arasındaki geçişte, aynı bilginin ikinci kez istenmesinde ya da yanlış sırada olabilir.

Boş bir hesapla bakmak. Boş bir hesapta sepet ya da geçmiş siparişler hiç görünmez. Gerçeğe yakın verisi olan bir test hesabı kullanılmazsa audit ürünün yarısını kaçırır.

Yalnızca masaüstünde bakmak. Kullanıcılarınızın çoğu telefondan geliyorsa audit de telefondan yapılmalıdır. Örnek karttaki hata mesajı sorunu masaüstünde hiç görünmeyebilir.

Audit'i kullanıcı testinin yerine koymak. Audit hipotez üretir. Büyük kararlar öncesinde bu hipotezleri gerçek kullanıcıyla doğrulamak gerekir.

Benim notum

Audit'lerde en sık gördüğüm sorun, ürünün ekibin diliyle konuşmasıdır. Menüde iç sistemin adı, hata mesajında bir kod yazar. Ekip bunu yıllardır gördüğü için fark etmez.

İkinci sırada hata mesajları gelir. Ya yanlış yerde çıkar ya da ne yapılacağını söylemez. Örnek karttaki kupon hatası birinci türden.

Ekipler çoğu zaman en görünür ekranı cilalar, asıl kayıp ise akışın ortasındaki sıkıcı bir adımda yaşanır. Bu yüzden audit'e ana sayfadan başlamam. İlk baktığım yer, kullanıcının para ya da zaman harcadığı adımdır.

Tek kişi olarak çalıştığım için Nielsen'in uyarısını ciddiye alıyorum. Dereceleri bulguyu yazarken vermiyorum, liste bittikten sonra ayrı bir turda veriyorum. Emin olmadığım bulguyu da açıkça öyle işaretliyorum.