Laboratuvar Olmadan Kullanılabilirlik Testi: Yeni Başlayanlar İçin Rehber

FabricLoop Ekibi  ·  Mayıs 2026  ·  4 dk okuma

Kullanılabilirlik testi, haksız yere pahalı ve yavaş olarak bilinir. İnsanlar "kullanıcı araştırması" duyunca tek yönlü bir ayna, elinde dosya tutan bir moderatör ve iki haftalık bir takvim hayal eder. Bu tür bir test gerçekten var ve işe de yarıyor — ama ürün ekiplerinin çoğu zaman ihtiyaç duyduğu yöntem bu değil.

Çoğu ekibin ihtiyaç duyduğu yöntem daha sade: beş kullanıcı, bir Figma prototipi ya da staging ortamı, bir görüntülü görüşme ve oturum başına 45 dakika. İyi yapıldığında, ciddi kullanılabilirlik sorunlarının büyük kısmını ürün yayına çıkmadan ortaya çıkarır. Düzenli yapıldığında — sprint başına bir kez bile olsa — ürün kalitesinde, lansman sonrası hiçbir analitiğin yakalayamayacağı bir birikimli iyileşme sağlar.

İşte sıfırdan nasıl yürüteceğiniz.

Dört adımlı test oturumu

Adım 1: Katılımcı bulma — kimi test ettiğiniz, kaç kişi olduğundan daha önemli

Çoğu kullanılabilirlik testi için doğru sayı beş katılımcıdır. Jakob Nielsen'in araştırması, beş kullanıcının kullanılabilirlik sorunlarının yaklaşık yüzde 85'ini ortaya çıkardığını, bundan sonrasında kazancın giderek azaldığını göstermiştir. Tasarım sürecinin farklı noktalarında beşer kullanıcıyla üç oturum yapmak, on beş kişiyle tek bir oturum yapmaktan daha değerlidir.

Katılımcı ölçütleri, sayıdan daha önemlidir. Hedef kullanıcınıza yakından benzeyen beş kişiyle yapılan bir test gerçek sorunları ortaya çıkarır. Uymayan on beş kişiyle yapılan test ise gürültü üretir. İki ya da üç eleme ölçütü belirleyin — rol, kullanım bağlamı, teknik rahatlık düzeyi — ve bunlara sadık kalın.

Çoğu ekip için en hızlı yol, iletişim izni vermiş mevcut kullanıcılara e-posta göndermektir. Makul bir teşvik sunun — 45 dakikalık bir oturum için £20'lık hediye kartı yeterlidir. Oturumları aynı hafta içine planlamaya çalışın; davetle test arasındaki süre uzadıkça gelmeme oranı artar.

Adım 2: Senaryo yazma — talimat değil, senaryo

En sık yapılan hata, görevleri talimat olarak yazmaktır: "Ayarlar'a tıklayın, sonra Bildirimler'e gidin ve tercihinizi şuna değiştirin..." Bu, kullanıcıya ne yapacağını söyler; yani arayüzün sezgisel olup olmadığını değil, kullanıcının yönergeleri takip edip edemediğini test edersiniz.

Bunun yerine görevleri senaryo olarak yazın: "Çok fazla bildirim aldığınızı ve yalnızca biri sizi doğrudan etiketlediğinde uyarı almak istediğinizi düşünün. Ne yapacağınızı bana gösterin." Bu, kullanıcıya gerçekçi bir hedef verir ve kafalarının nerede karıştığı dahil, arayüzde gerçekte nasıl gezindiklerini gözlemlemenizi sağlar.

Adım 3: Yürütme — işiniz izlemek, yardım etmek değil

Bir kullanılabilirlik testini yönetirken en zor kısım, yardım etme dürtüsüne karşı koymaktır. Kullanıcının kafası karıştığında tüm içgüdüleriniz araya girip nereye tıklaması gerektiğini göstermenizi söyler. Oysa kafa karışıklığı tam da veridir. Zorlanan bir kullanıcı, arayüzde bir şeylerin yanlış olduğunu söylüyordur — siz müdahale ettiğiniz anda bu sinyali kaybedersiniz.

Kullanıcılardan oturum boyunca sesli düşünmelerini isteyin: "İlerlerken neye baktığınızı ve ne düşündüğünüzü söylemeniz yeterli." Bu, zihinsel modelleri hakkında kesintisiz bir veri akışı sağlar. Yalnızca hataları değil, tereddütleri de not edin — doğru düğmeye tıklamadan önce üç saniye duraklayan bir kullanıcı, sonunda başarılı olsa bile bir tasarım sorununu ortaya koymuştur.

Adım 4: Sentez — alıntılar değil, örüntüler

Değerin çoğu sentez aşamasında yaratılır — ve çoğu ekibin köşe kestiği yer de burasıdır. Beş oturumdan çıkan ham notlar henüz bulgu değildir. Ekip olarak değerlendirme yaptığınızda, gözlemleri temalara göre gruplayıp önem dereceleri atadığınızda bulguya dönüşürler.

Değerlendirmeyi, gözlemler tazeyken oturumlarla aynı gün yapın. Sorunları üç kategoriye ayırın: kritik (kullanıcılar görevi tamamlayamadı), orta (görev tamamlandı ama ciddi zorluk ya da hatayla) ve düşük (tamamlanmayı engellemeyen sürtünme). Kritik sorunlar lansmandan önce giderilmelidir. Orta düzeydeki sorunlar bir sonraki sprintte önceliklendirilmelidir. Düşük düzeydekiler backlog'a girer.

Bulguları tek sayfada yazın: her biri en az iki katılımcıdan kanıtla desteklenen ilk üç kritik sorun ve her biri için önerilen bir tasarım değişikliği. Bundan fazla yer gerektiren her şey ayrı bir belgeye aittir.