← Yazılar

16 dk

Usability Testing Nedir? CRO’da Kullanıcıların Nerede Takıldığını Nasıl Buluruz?

1 Eylül 2026 · Berke Dalar

Usability testing, kullanıcıya “siteyi beğendiniz mi?” diye sormak değildir. Gerçek veya hedef kullanıcıya gerçekçi bir görev verip, bu görevi tamamlamaya çalışırken ne yaptığını gözlemleme yöntemidir.

Bir kullanıcı görüşmede:

“Checkout gayet kolaydı.”

diyebilir.

Aynı kullanıcı gerçek bir satın alma görevi sırasında:

teslimat bilgisini bulamayabilir,
adres alanını yanlış anlayabilir,
aynı butona birkaç kez basabilir,
önceki adıma geri dönebilir,
kupon kodu arayabilir,
hangi seçeneği işaretlemesi gerektiğini anlayamayabilir.

İşte usability testing bu farkı görünür hale getirir.

Nielsen Norman Group usability testing’i, bir facilitator’ın katılımcıya belirli görevler verdiği ve katılımcı bu görevleri tamamlarken araştırmacının davranışı gözlemleyip geri bildirimi dinlediği UX research yöntemi olarak tanımlar.^[1]

NN/g’ye göre usability testing’in temel amaçları genellikle üç başlıkta toplanır:

tasarımdaki problemleri bulmak,
iyileştirme fırsatlarını keşfetmek,
hedef kullanıcıların davranışları ve tercihleri hakkında öğrenmek.

CRO açısından bunun anlamı şudur:

Kullanıcının neden conversion olmadığını yalnız tahmin etmek yerine, hedefe ulaşmaya çalışırken karşılaştığı problemi doğrudan gözlemleyebiliriz.

Usability testing nedir?

Usability testing, gerçekçi kullanıcıların gerçekçi görevler üzerinden bir web sitesi, uygulama, ürün veya prototiple etkileşiminin gözlemlendiği araştırma yöntemidir.

En temel model üç parçadan oluşur:

FACILITATOR
↓
TASK
↓
PARTICIPANT

NN/g de usability testlerin çekirdeğini facilitator, task ve participant olarak tanımlar.^[1]

Facilitator, testi yönetir ve katılımcıyı gözlemler.

Task, katılımcının gerçekleştirmeye çalıştığı gerçekçi aktivitedir.

Participant, test edilen ürün veya hizmetin gerçek veya gerçekçi hedef kullanıcısıdır.

Bu üç parçadan biri yanlışsa research kalitesi hızla düşebilir.

Usability testing CRO’nun neresine oturur?

Usability testing, CRO’nun tamamı değildir. Conversion research içindeki farklı evidence kaynaklarından biridir.

Örneğin araştırma sistemini şöyle düşünebiliriz:

GA4 / ANALYTICS
"Nerede problem var?"

↓

FUNNEL ANALYSIS
"Kullanıcı hangi aşamada kaybediliyor?"

↓

SESSION RECORDINGS
"Gerçek oturumlarda ne yapıyor?"

↓

VoC
"Ne söylüyor, ne istiyor, neye itiraz ediyor?"

↓

USABILITY TESTING
"Belirli bir görevi yapmaya çalışırken
nerede ve nasıl takılıyor?"

↓

PROBLEM DEFINITION
↓
HYPOTHESIS
↓
CHANGE / EXPERIMENT

Bu yöntemlerin hiçbiri diğerinin yerine geçmez.

Farklı research sorularına cevap verirler.

Voice of Customer ile usability testing arasındaki fark nedir?

Voice of Customer araştırması özellikle müşterinin:

ne söylediği,
ne istediği,
hangi problemden bahsettiği,
hangi konuda tereddüt ettiği,
hangi dili kullandığı

hakkında bilgi sağlar.

Bu büyük ölçüde attitudinal, yani self-reported veridir.

Usability testing ise behavioral tarafa daha yakındır:

Kullanıcı söylediği şeyden bağımsız olarak, görevi yapmaya çalışırken gerçekte ne yapıyor?

Örneğin interview sırasında:

“Ürünleri karşılaştırmak çok kolay.”

diyen kullanıcı usability test sırasında hangi iki ürünü karşılaştıracağını bulamayabilir.

Bu iki bulgudan biri diğerini geçersiz kılmaz.

Bize farklı şeyler söyler:

VoC
Kullanıcının algısı

USABILITY TESTING
Kullanıcının görev içindeki davranışı

Session recording ile usability testing aynı şey midir?

Hayır.

İkisinde de kullanıcı davranışı gözlemlenebilir ama araştırma setup’ı farklıdır.

Alan	Session Recording	Usability Testing
Görev	Kullanıcının doğal oturumunda ne yaptığı izlenir.	Araştırmacı belirli ve gerçekçi bir görev verir.
Bağlam	Kullanıcının gerçek amacı her zaman bilinmeyebilir.	Görevin amacı ve başlangıç koşulu bellidir.
Soru sorma	Genellikle mümkün değildir.	Moderated testte nötr follow-up soruları sorulabilir.
Motivasyon	Davranıştan çıkarım yapılır.	Davranış gözlemlenir ve katılımcıdan açıklama alınabilir.
Örneklem	Çok sayıda doğal oturum incelenebilir.	Daha küçük fakat araştırma amacıyla seçilmiş katılımcı grubu kullanılır.

Örneğin recording’de kullanıcının pricing sayfasında üç kez geri döndüğünü görebiliriz.

Ama neden?

Usability test sırasında katılımcı:

“Bu pakette kaç kullanıcı dahil anlayamadım.”

diyebilir.

Böylece davranış belirli bir görev ve düşünce bağlamına oturur.

Kullanıcıya “siteyi incele” demek usability testing midir?

Tek başına pek güçlü bir task değildir.

Usability testing’in değerli olabilmesi için katılımcının gerçek dünyada gerçekleştirebileceği anlamlı bir aktiviteye ihtiyacı vardır.

NN/g usability task’larının gerçekçi olması, kullanıcıyı arayüzle etkileşime teşvik etmesi ve cevabı veya kullanılacak interface öğesini ele vermemesi gerektiğini önerir.^[2]

Örneğin:

Zayıf:

“Filtreleri kullanarak siyah Nike ayakkabıları bulun.”

Burada kullanıcının hangi özelliği kullanması gerektiğini zaten söyledik.

Daha iyi:

“2.000 TL bütçeniz var. Koşu için kullanabileceğiniz uygun bir ayakkabı bulup satın alma aşamasına kadar ilerleyin.”

Bu durumda kullanıcı:

arama,
kategori,
filtre,
ürün karşılaştırması

arasından kendi yolunu seçebilir.

Biz de gerçek interface davranışını gözlemleyebiliriz.

İyi usability task nasıl yazılır?

İyi bir görev üç özelliğe sahip olmalıdır.

1. Gerçekçi olmalı

Kullanıcının gerçek hayatta yapabileceği bir işi temsil etmelidir.

Örneğin e-ticaret için:

“Yaklaşık 3.000 TL bütçeyle evde kullanabileceğiniz bir darbeli matkap bulun. Size uygun ürünü seçip sepete ekleyin.”

2. Bir hedef vermeli

Kullanıcı neden bu işlemi yaptığını anlamalıdır.

Yalnız:

“Bu siteye bakın.”

dediğimizde neyin başarı sayılacağı belirsiz kalır.

3. Çözüm yolunu ele vermemeli

Görev:

“Sol taraftaki fiyat filtresini kullanın.”

derse artık filtreden kullanıcı doğal olarak yararlanıyor mu sorusunu test edemeyiz.

NN/g task wording içindeki küçük ipuçlarının bile kullanıcı davranışını priming yoluyla etkileyebileceğini belirtir.^[1]

Participant neden gerçek hedef kullanıcıya benzemeli?

Usability testing’de herhangi beş kişiyi yakalayıp siteyi kullandırmak her zaman anlamlı sonuç üretmez.

NN/g participant’ın ürün veya hizmet için gerçekçi bir kullanıcı olması gerektiğini belirtir.^[1]

Bu kişi:

mevcut müşteri,
potansiyel müşteri,
aynı ihtiyaca sahip hedef kullanıcı,
benzer domain bilgisine sahip kişi

olabilir.

Örneğin endüstriyel HVAC ekipmanı satan bir B2B sitede teknik satın alma kararlarını hiç vermeyen bir arkadaşınıza:

“Doğru VRF sistemini seç.”

demek yanlış participant seçimi olabilir.

Kullanıcının asıl problemi interface değil domain bilgisinin olmaması olabilir.

Usability test sırasında kullanıcıya yardım edilmeli mi?

Mümkün olduğunca müdahale azaltılmalıdır.

Çünkü kullanıcı takıldığında:

“Sağdaki yeşil butona basabilirsiniz.”

dediğimiz anda artık interface’in kendi başına yönlendirme kapasitesini test etmiyoruz.

Kendi açıklamamızı test ediyoruz.

NN/g facilitator’ın yüksek kaliteli ve geçerli veri elde etmek için katılımcının davranışını yanlışlıkla etkilememesi gerektiğini özellikle vurgular.^[1]

NN/g’nin usability-test facilitation rehberi de mümkün olduğunca az konuşmayı ve kullanıcının sorularına doğrudan çözüm vermek yerine nötr tekniklerle cevap vermeyi önerir.^[3]

Nötr soru nasıl sorulur?

Kullanıcı:

“Buradan mı devam edeceğim?”

dediğinde:

Zayıf cevap:

“Evet, aşağıdaki Devam Et butonuna basın.”

Daha nötr:

“Sizce burada nasıl devam ederdiniz?”

veya:

“Şu anda ne arıyorsunuz?”

olabilir.

Yanlış soru:

“Checkout butonunu bulamadınız mı?”

Çünkü hem problemi isimlendirdik hem de kullanıcının ne araması gerektiğini söyledik.

Think-aloud yöntemi nedir?

Usability testing sırasında katılımcıdan yaptığı işlemleri ve düşüncelerini sesli biçimde anlatması istenebilir.

NN/g bunu think-aloud method olarak tanımlar ve facilitator’ın bu sayede kullanıcının davranışı yanında hedefleri, düşünceleri ve motivasyonları hakkında ek bağlam kazanabileceğini belirtir.^[1]

Örneğin kullanıcı:

“Burada teslimat bilgisini arıyorum ama sanırım aşağıdadır.”

dediğinde yalnız scroll davranışını değil, ne aradığını da öğreniriz.

Ancak think-aloud özellikle qualitative insight için kullanışlıdır.

Task time gibi hassas quantitative ölçümleri aynı anda yorumlarken dikkat gerekir çünkü kullanıcının sürekli konuşması normal task süresini etkileyebilir.^[4]

Qualitative ve quantitative usability testing arasındaki fark nedir?

Usability testing yalnız nitel yöntem değildir.

NN/g qualitative ve quantitative usability testing’i ayrı amaçlarla ele alır.^[1]

Qualitative usability testing daha çok:

problemleri keşfetmek,
davranış pattern’lerini görmek,
friction alanlarını anlamak,
tasarım fırsatları üretmek

için kullanılır.

Quantitative usability testing ise:

task-success rate,
time on task,
error rate

gibi ölçümlerle benchmark üretmeyi hedefleyebilir.

Alan	Qualitative	Quantitative
Temel amaç	Problemi ve davranışı keşfetmek	Usability performansını ölçmek
Çıktı	Problem, pattern, insight	Metric ve benchmark
Tipik metric	Zorunlu değildir	Task success, task time vb.
Katılımcı ihtiyacı	Daha küçük örneklemle çalışılabilir	İstatistiksel ölçüm için daha büyük örneklem gerekir

CRO araştırmalarında çoğunlukla ilk ihtiyaç qualitative taraftadır:

Kullanıcı nerede ve neden zorlanıyor olabilir?

Usability testing için gerçekten sadece 5 kullanıcı yeterli mi?

“Her usability test için kesinlikle beş kişi yeterlidir” şeklinde evrensel bir kural yoktur.

NN/g’nin güncel Usability Testing 101 rehberi tipik, qualitative ve tek bir kullanıcı grubunu inceleyen çalışma için yaklaşık beş katılımcı önerir.^[1]

NN/g’nin özet materyalinde 5–8 katılımcı aralığı da verilir.^[5]

Beş kullanıcı yaklaşımının arkasındaki mantık qualitative problem keşfinde diminishing returns oluşmasıdır: yeni katılımcılar geldikçe bazı problemler tekrar etmeye başlar.^[6]

Örneğin:

USER 1
Pricing farkını anlamadı.

USER 2
Aynı alanda yanlış paketi seçti.

USER 3
Paket karşılaştırmasına geri döndü.

USER 4
"Hangisinin bana uygun olduğunu bilmiyorum" dedi.

USER 5
Aynı seçimde duraksadı.

Burada artık tek kişinin yaşadığı garip bir durumdan değil, tekrar eden bir problem pattern’inden bahsedebiliriz.

Ne zaman 5 kullanıcı yeterli olmayabilir?

Özellikle farklı kullanıcı gruplarının:

farklı görevleri,
farklı domain bilgileri,
farklı beklentileri

varsa her grup ayrıca incelenebilir.

NN/g de geniş ve farklı kullanıcı gruplarında tek bir beş kişilik grubun yeterli olmayabileceğini belirtir.^[7]

Örneğin bir B2B yazılımında:

ADMIN
≠
END USER
≠
PROCUREMENT
≠
MANAGER

olabilir.

Hepsinin aynı görevi ve aynı zihinsel modeli paylaşması gerekmez.

Ayrıca quantitative usability benchmark üretmek istiyorsak beş katılımcı yeterli bir istatistiksel örneklem değildir. NN/g quantitative çalışmalarda daha büyük örneklem gerektiğini açıkça ayırır.^[8]

Beş kullanıcı bir büyülü sayı değil; küçük ve iteratif qualitative testlerin maliyet-fayda mantığıdır.

Usability testing ile funnel analysis nasıl birlikte çalışır?

Conversion funnel analizi kullanıcının hangi aşamada daha fazla kaybedildiğini gösterebilir.

Örneğin:

PRODUCT VIEW
10.000

↓

ADD TO CART
2.000

↓

CHECKOUT
1.300

↓

PURCHASE
500

Analytics bize checkout → purchase aşamasında önemli drop-off olduğunu gösterebilir.

Usability test burada belirli görevle devreye girer:

“Bu ürünü satın almak istediğinizi varsayın. Siparişi ödeme aşamasına kadar tamamlayın.”

Sonra izleriz:

Kullanıcı nerede duruyor?
Hangi alanı yanlış anlıyor?
Geri dönüyor mu?
Ek bilgi arıyor mu?
Beklemediği bir şey görüyor mu?
Görevi tamamlayabiliyor mu?

Böylece:

FUNNEL
"Problem nerede?"

+

USABILITY
"Bu problem görev sırasında nasıl ortaya çıkıyor?"

ilişkisini kurabiliriz.

Triangulation CRO açısından neden güçlüdür?

Tek bir evidence kaynağı bize önemli sinyal verebilir.

Ama farklı yöntemler aynı problem alanını işaret ettiğinde problem tanımı güçlenebilir.

Örneğin:

Kaynak	Bulgu
GA4	Mobil checkout drop-off desktop’tan yüksek.
Session Recording	Adres alanında tekrar eden tıklamalar ve geri dönüşler görülüyor.
VoC	Kullanıcılar adres formatını anlamakta zorlandıklarını söylüyor.
Usability Testing	Beş katılımcının dördü aynı alanda duraksıyor veya hata yapıyor.

Bu noktada:

“Form biraz kötü olabilir.”

gibi genel bir fikirden daha güçlü bir problem tanımı yapabiliriz:

Mobil checkout’taki adres alanının beklenen giriş formatını yeterince açık göstermemesi, kullanıcıların görevi tamamlamasını zorlaştırıyor olabilir.

Hâlâ “kesin neden budur” demiyoruz.

Ama evidence seviyesi tek bir anekdottan çok daha güçlüdür.

Usability problem nasıl kaydedilmelidir?

Test sırasında yalnız:

“Kullanıcı zorlandı.”

yazmak yeterli değildir.

Daha yararlı kayıt:

TASK
Uygun ürünü seç ve sepete ekle.

OBSERVATION
Kullanıcı beden seçmeden CTA'ya bastı.

SYSTEM RESPONSE
Sayfa hata gösterdi fakat error message
CTA'nın üzerinde kaldı.

USER BEHAVIOR
Kullanıcı CTA'ya tekrar bastı.

OUTCOME
Task ilerlemedi.

POSSIBLE ISSUE
Validation feedback görünür değil.

Bu yapı gözlem ile interpretation’ı ayırır.

“CTA’ya iki kez bastı” gözlemdir.

“Kullanıcı validation’ı anlamadı” yorumdur.

İkisini aynı şey gibi yazmamak research kalitesini artırır.

Usability problem severity nasıl değerlendirilir?

Her gözlenen problem aynı öneme sahip değildir.

Basit bir CRO severity modeli şöyle kurulabilir:

Kriter	Soru
Frequency	Kaç katılımcı bu problemi yaşadı?
Impact	Problem görevi yavaşlatıyor mu, tamamen engelliyor mu?
Journey Stage	Problem conversion’a ne kadar yakın?
Recoverability	Kullanıcı kendi başına problemi aşabiliyor mu?
Business Impact	Bu görev işletme açısından ne kadar değerli?

Örneğin:

ISSUE A
Footer linkinin yeri beklenenden farklı.
1/5 kullanıcı zorlandı.
Task yine tamamlandı.

ISSUE B
Ödeme alanındaki validation görünmüyor.
4/5 kullanıcı zorlandı.
3 kullanıcı task'ı tamamlayamadı.

İki problem aynı backlog priority’sine sahip olmamalıdır.

Observed issue doğrudan çözüm müdür?

Hayır.

Usability testing’in çıktısı önce problem evidence’ıdır.

Örneğin:

OBSERVATION
4/5 kullanıcı pricing paketleri arasında
geri dönüyor.

↓

PROBLEM
Plan farkları yeterince açık olmayabilir.

Buradan doğrudan:

“Pricing kartlarının rengini değiştirelim.”

sonucu çıkmaz.

Bir sonraki aşama:

OBSERVATION
↓
EVIDENCE
↓
PROBLEM DEFINITION
↓
POSSIBLE CAUSE
↓
SOLUTION IDEA
↓
HYPOTHESIS
↓
METRIC
↓
EXPERIMENT / CHANGE

olmalıdır.

Research bulgusunun bu zincirde nasıl ilerletileceğini CRO hipotezi oluşturma sürecinde ayrı ele alıyorum.

Her usability problemi A/B test edilmeli mi?

Hayır.

Test sırasında:

butonun çalışmadığını,
form validation’ın görünmediğini,
mobil menünün açılamadığını,
checkout’ın hata verdiğini

gözlemlediysek bunlar açık bug olabilir.

Bug’ı A/B test etmek için kullanıcıların yarısını bozuk forma göndermek epey yaratıcı ama gereksiz bir insan faaliyeti olur.

Bazı bulgular:

hemen düzeltilebilir,
daha fazla araştırılabilir,
instrumentation gerektirebilir,
hypothesis oluşturup experiment’a taşınabilir.

CXL’in conversion-research modelinde de user testing usability, clarity ve friction problemlerini belirlemek için kullanılır; araştırma bulguları daha sonra kategorize edilip test hypothesis’lerine dönüştürülebilir.^[9]

Usability testing düşük trafikli sitelerde işe yarar mı?

Evet. Hatta düşük trafikli sitelerde qualitative research’in önemli avantajlarından biri budur.

A/B testing için yeterli event hacmi bulunmayabilir.

Fakat bir kullanıcıya:

“Bu hizmetin size uygun olup olmadığını anlamaya çalışın ve iletişim aşamasına kadar ilerleyin.”

görevi vermek için ayda yüz bin ziyaretçiye ihtiyacımız yoktur.

Bu nedenle düşük traffic:

A/B TESTING
için sınırlayıcı olabilir.

AMA

USABILITY TESTING
için otomatik engel değildir.

Bu, “beş kişi söyledi, kesin conversion %30 artar” anlamına gelmez.

Qualitative test uplift tahmin etmek için değil, problemleri keşfetmek ve kullanıcı davranışını anlamak için kullanılır.

Landing page usability testing nasıl yapılabilir?

Landing page optimizasyonunda yalnız kullanıcıya:

“Bu sayfa hakkında ne düşünüyorsunuz?”

diye sormak yerine bir görev verilebilir.

Örneğin:

“Bu hizmeti şirketiniz için değerlendiriyorsunuz. Size uygun olup olmadığını anlamaya çalışın ve ilgilenirseniz iletişim aşamasına kadar ilerleyin.”

Sonra şu journey izlenebilir:

Aşama	Araştırılan Davranış
Arrival	Sayfanın ne sunduğunu anlayabiliyor mu?
Relevance	Teklifin kendisiyle ilgili olup olmadığını anlayabiliyor mu?
Evaluation	Hizmet kapsamını ve faydayı değerlendirebiliyor mu?
Trust	Karar vermek için hangi proof’u arıyor?
Objection	Hangi noktada tereddüt ediyor?
Action	Sonraki adımı bulup tamamlayabiliyor mu?

E-ticaret usability testing nasıl yapılabilir?

E-ticarette görev daha işlem odaklı olabilir.

Örneğin:

“Evde kullanmak için 5.000 TL altında bir akülü matkap arıyorsunuz. Size uygun bir ürün bulun ve satın alma aşamasına kadar ilerleyin.”

Bu tek görev içinde şu sistemlerin tamamı test edilebilir:

NAVIGATION
↓
CATEGORY
↓
FILTERS
↓
PRODUCT COMPARISON
↓
PDP
↓
VARIANT SELECTION
↓
ADD TO CART
↓
CHECKOUT

Katılımcı:

kategori bulabiliyor mu,
filtreleri anlayabiliyor mu,
ürün özelliklerini karşılaştırabiliyor mu,
stok bilgisini görüyor mu,
uyumluluğu anlayabiliyor mu,
teslimat maliyetini bulabiliyor mu,
checkout’ı tamamlayabiliyor mu

gözlemlenir.

Bu aynı zamanda e-ticaret CRO’da tek bir sayfadan çok uçtan uca kullanıcı yolculuğunu değerlendirmek için güçlü bir yöntemdir.

Usability testing search traffic için kullanılabilir mi?

Evet.

Özellikle organic landing page’ler için görevin başlangıç bağlamını search intent üzerinden kurabiliriz.

Örneğin:

“Google’da ‘e-ticaret SEO danışmanlığı’ aradığınızı ve bu sayfaya geldiğinizi varsayın. Hizmetin size uygun olup olmadığını anlamaya çalışın.”

Burada araştırılan şey ranking değildir.

Post-click experience’dır.

Kullanıcı:

doğru sayfaya geldiğini hissediyor mu,
arama niyetinin devamını görüyor mu,
teklifi anlıyor mu,
proof buluyor mu,
sonraki adımı keşfedebiliyor mu

gözlemlenebilir.

Bu yaklaşım acquisition ile kullanıcı yolculuğu arasındaki boşluğu araştırmak için özellikle değerlidir.

20 dakikalık basit bir usability test nasıl yapılır?

İlk çalışma dev usability lab gerektirmez.

Basit bir qualitative test şöyle kurulabilir:

1. Tek bir araştırma sorusu seç

Örneğin:

“Kullanıcılar hizmetin kendilerine uygun olup olmadığını anlayabiliyor mu?”

2. Gerçekçi kullanıcı seç

Test edilen görevi gerçek hayatta yapabilecek birini bul.

3. Tek bir gerçekçi görev yaz

“Bu hizmeti kendi şirketiniz için değerlendiriyorsunuz. Size uygun olup olmadığına karar vermeye çalışın ve isterseniz iletişim aşamasına kadar ilerleyin.”

4. Görevi ver ve sus

Interface’i açıklama.

Kullanıcı yardım istediğinde mümkün olduğunca nötr follow-up kullan.

5. Davranışı kaydet

Aşama	Kullanıcının Yaptığı	Gözlenen Problem
Arrival	Hero’yu okudu	Hizmetin hedef kitlesini anlamadı
Evaluation	Hizmet kapsamını aradı	Paket bilgisini bulmakta zorlandı
Trust	Referans aradı	Proof alanını ilk geçişte görmedi
Decision	CTA’ya yaklaştı	Fiyatın nasıl belirlendiğini sorguladı
Action	Formu açtı	Telefon alanında duraksadı

6. Görev bittikten sonra nötr follow-up sor

Örneğin:

En zor kısım neydi?
Bir noktada ne yapacağınızı bilemediğiniz oldu mu?
Karar vermek için eksik kalan bir bilgi oldu mu?

7. Çözüm üretmeden önce problemi yaz

İlk çıktı:

OBSERVED USABILITY PROBLEMS

olmalıdır.

Henüz:

REDESIGN BACKLOG

değil.

Usability test sonucu nasıl raporlanmalı?

Basit bir finding kartı yeterlidir:

ISSUE
Kullanıcı teslimat bilgisini bulamadı.

TASK
Ürün seçip satın alma aşamasına ilerlemek.

OBSERVED IN
4 / 5 participants

IMPACT
3 katılımcı checkout'a ilerlemeden
teslimat bilgisini aramak için geri döndü.

EVIDENCE
Session notes + recording

INTERPRETATION
Teslimat bilgisinin görünürlüğü
karar sırasında yetersiz olabilir.

SEVERITY
High

NEXT STEP
Diğer research evidence ile doğrula
ve solution hypothesis üret.

Böyle bir format problemi:

gözlem,
yorum,
öncelik,
sonraki aksiyon

olarak birbirinden ayırır.

Usability testing sonuçları CRO metriğine nasıl bağlanır?

Qualitative usability testing’in görevi doğrudan conversion uplift ölçmek değildir.

Ancak bulunan problem daha sonra ölçülebilir davranışa bağlanabilir.

Örneğin:

USABILITY FINDING
Kullanıcılar formun neden şirket telefonu
istediğini anlamıyor.

↓

HYPOTHESIS
Telefon bilgisinin neden istendiğini açıklarsak
form abandonment azalabilir.

↓

PRIMARY METRIC
Form completion

↓

GUARDRAIL
Qualified lead rate

Metric hierarchy’nin nasıl kurulacağını CRO metrikleri ve measurement framework’ünde detaylandırıyorum.

Usability testing’de sık yapılan hatalar

Kullanıcıya siteyi beğenip beğenmediğini sormak

Bu attitude ölçer. Task usability’sini göstermez.

Gerçek görev vermemek

Katılımcı amaçsız biçimde sayfada dolaşır ve gerçek karar davranışı oluşmaz.

Task içinde cevabı söylemek

“Filtreyi kullanarak…” gibi wording kullanıcı davranışını yönlendirir.

Yanlış katılımcıyla test yapmak

Domain bilgisi olmayan kullanıcının yaşadığı sorun interface problemi olmayabilir.

Kullanıcı takılınca yardım etmek

Facilitator interface’in eksik yönlendirmesini telafi eder.

Leading question sormak

“Fiyatı bulmak zor olmadı mı?” research sorusu değil, cevap önerisidir.

Tek katılımcıyı pattern sanmak

Tekil bulgu araştırmaya değer olabilir ama tekrar eden problem olarak sunulmamalıdır.

Beş kullanıcıyı bilimsel yasa sanmak

Kullanıcı grubu ve research amacı katılımcı ihtiyacını değiştirir.

Qualitative testten conversion uplift hesaplamak

Beş katılımcıdan üçünün başarılı olması site-wide conversion’ın %60 olduğu anlamına gelmez.

Her gözlemi doğrudan çözüm fikrine çevirmek

Önce problem tanımlanmalı, gerekirse başka evidence ile doğrulanmalıdır.

Usability testing ile heuristic analysis arasındaki fark nedir?

Heuristic analysis’te uzman interface’i belirli prensip veya kriterlerle değerlendirir.

Usability testing’de ise hedef kullanıcı interface üzerinde gerçek görev yapar.

HEURISTIC ANALYSIS
"Uzman burada problem olabileceğini düşünüyor."

USABILITY TESTING
"Kullanıcı burada gerçekten zorlanıyor."

İki yöntem birlikte kullanılabilir.

Heuristic review araştırılacak alan üretebilir.

Usability test gerçek kullanıcı davranışıyla bunlardan bazılarının ortaya çıkıp çıkmadığını gösterebilir.

Usability testing CRO araçlarından bağımsız düşünülebilir mi?

Evet.

Yöntem herhangi bir özel yazılıma bağlı değildir.

Ekran kaydı, video-call platformu veya dedicated user-testing aracı işi kolaylaştırabilir.

Ama:

USER TESTING TOOL
≠
USABILITY TESTING METHODOLOGY

Bir arkadaşınızla aynı masada oturup gerçekçi görev üzerinden sistematik gözlem yapmak bile ilk usability insight’larını üretebilir.

Tool stack’in hangi research sorularına göre seçilmesi gerektiği CRO araçlarının ayrıca ele alınması gereken tarafıdır.

Usability testing’in CRO’daki asıl değeri nedir?

Analytics dashboard’da şu sayıyı görebiliriz:

FORM COMPLETION RATE
%6.2

Bu sayı bize sonucu söyler.

Session recordings davranış pattern’leri gösterebilir.

VoC müşterinin kendi açıklamasını verebilir.

Usability testing ise kullanıcıya belirli bir hedef vererek şunu gözlemlememizi sağlar:

Bu kişi gerçekten yapmak istediği şeyi bu interface ile yapabiliyor mu?

CRO açısından temel soru da çoğu zaman budur.

USER INTENT
↓
TASK
↓
INTERFACE
↓
BEHAVIOR
↓
FRICTION
↓
TASK SUCCESS / FAILURE
↓
RESEARCH FINDING
↓
HYPOTHESIS
↓
CHANGE
↓
MEASUREMENT

CXL de conversion research çerçevesinde user testing’i usability ve clarity problemlerini, friction kaynaklarını ve sonraki testlerde araştırılabilecek alanları bulmak için ayrı bir araştırma adımı olarak konumlandırır.^[9]

Usability testing’in amacı kullanıcıyı test etmek değildir

Son bir isimlendirme problemi var.

“User testing” denildiğinde sanki başarısız olan taraf kullanıcıymış gibi anlaşılabilir.

Aslında test edilen kullanıcının zekâsı veya yeteneği değildir.

Test edilen:

arayüz,
bilgi mimarisi,
copy,
form,
checkout,
ürün akışı

gibi deneyim katmanlarının kullanıcının gerçek görevini destekleyip desteklemediğidir.

Kullanıcı görevi yapamıyorsa ilk soru “kullanıcı neden anlamadı?” değil, “biz bunu anlaşılır hale getirebildik mi?” olmalıdır.

Bu nedenle usability testing’i CRO araştırma sisteminin güçlü parçalarından biri yapan şey yalnız problem bulması değildir.

Ekibin kendi tasarımına içeriden bakmasını bırakıp gerçek kullanıcının görevi üzerinden deneyimi değerlendirmesini sağlamasıdır.

Usability testing, kullanıcının site hakkında ne söylediğini değil; bir hedefe ulaşmaya çalışırken sitenin kullanıcıya gerçekte ne yaptırdığını gösterir.

Kaynaklar ve teknik referanslar

Organik kanalı beraber büyütelim.

Sitenizi anlatın; veriye bakıp uygun olup olmadığımızı açıkça söyleyeyim. Uygunsa 30 dakikalık görüşme ayarlarız.

Görüşme talebi bırak → Yazıları incele →