Kullanılabilirlik Testi
Tasarımı yapan ekip, ürünü artık kullanıcı gibi göremez. Her düğmenin ne işe yaradığını bildiği için takılmaz. Kullanılabilirlik testi bu körlüğü kırmanın en hızlı yoludur: birkaç oturumda ekibin aylardır görmediği sorunlar görünür olur.
Kullanılabilirlik testi, temsilî kullanıcılardan bir ürün ya da prototip üzerinde gerçekçi görevleri yapmalarını isteyip onları gözlemleyerek tasarımdaki sorunları bulma yöntemidir. Kullanıcının ne söylediğinden çok ne yaptığına bakar; sonuç, önem derecesine göre sıralanmış bulgular ve düzeltme önerileridir.
Testleri uzaktan ve moderasyonlu yaparız: katılımcı kendi cihazında görevleri yaparken düşüncelerini sesli anlatır, biz yönlendirmeden gözlemleriz. Ekibinizi oturumları canlı izlemeye davet ederiz; bulguları aynı gün ortak bir tabloda toplarız. Sonuç, her sorun için kanıt, önem derecesi ve öneri içeren bir rapordur.
[01]Kimler için?
- Yayına çıkmadan önce prototipini doğrulamak isteyen ekipler
- Kayıt, ödeme ya da kurulum adımında kullanıcı kaybeden ürünler
- Yeniden tasarım sonrası eskisinden daha iyi olup olmadığını görmek isteyenler
- Tasarım tartışmalarını görüş yerine gözleme dayandırmak isteyen ekipler
[02]Kimler için değil?
- Bir kampanya sayfasında hangi başlığın daha çok dönüşüm getirdiğini ölçmek istiyorsanız bu bir A/B testi işidir; kullanılabilirlik testi nedenini anlamaya odaklanır.
- Uygulamanın kodlanmasını arıyorsanız: biz tasarlar, geliştirici ekibinize eksiksiz devreder ve yayın öncesi tasarım kontrolünü yaparız; kodlamayı sizin ekibiniz ya da iş ortağınız üstlenir.
[03]Ne teslim edilir?
| Teslimat | İçerik | Sıklık |
|---|---|---|
| Test planı | Hedefler, görev senaryoları, başarı ölçütleri, katılımcı profili | Başlangıç |
| Pilot oturum | Görevlerin anlaşılırlığını ve süresini denemek için | Saha öncesi |
| Moderasyonlu oturumlar | Uzaktan, sesli düşünme; ekibiniz canlı izleyebilir | Saha |
| Ölçümler | Görev başarısı, hata ve yardım isteği; istenirse kısa memnuniyet anketi | Saha |
| Bulgu raporu | Önem derecesi, kanıt, etkilenen görev ve öneri; kısa video kesitleri (izinli) | Teslim |
| Önceliklendirme oturumu | Ekibinizle hangi bulgunun ne zaman düzeltileceğine karar | Teslim |
[04]İlk 90 gün
- 1. aşama
Hedef ve görevler
Hangi akışın test edileceği ve başarının nasıl tanımlanacağı netleşir.
- 2. aşama
Katılımcı ve pilot
Katılımcılar davet edilir, bir pilot oturumla görevler düzeltilir.
- 3. aşama
Oturumlar
Moderasyonlu oturumlar yapılır, gözlemler aynı gün işlenir.
- 4. aşama
Rapor ve karar
Bulgular önem derecesine göre sıralanır ve ekibinizle karara bağlanır.
[05]Neyle ölçülür?
- Görev başarı oranı ve görev başına hata sayısı
- Kritik sorunların düzeltme sonrası testte tekrar edip etmediği
- İstenirse SUS gibi standart bir memnuniyet ölçeği
[06]Sık yapılan hatalar
Yönlendiren görev yazmak
"Ayarlar menüsünden bildirimleri kapatın" görevi cevabı söyler. "Bildirim almak istemiyorsunuz, ne yaparsınız?" gerçek davranışı gösterir.
Tek büyük test yapmak
Az katılımcıyla sık test etmek, bir kerede çok katılımcıyla test etmekten genellikle daha çok sorunu düzeltmeye yarar.
Katılımcıya yardım etmek
Takılan kullanıcıya ipucu vermek doğal bir refleks ama bulguyu yok eder. Moderatör sorar, cevaplamaz.
[07]Karşılaştırma
| Tür | Güçlü yanı | Sınırı |
|---|---|---|
| Moderasyonlu (uzaktan) | Neden takıldığını sorabilirsiniz | Oturum başına daha fazla emek |
| Moderasyonsuz | Hızlı, çok katılımcıya ulaşır | Takılmanın nedenini anlamak zor |
| Prototip testi | Kod yazılmadan önce sorun bulur | Gerçek veri ve hız hissi eksik |
| Yayındaki üründe test | Gerçek koşullar | Düzeltme maliyeti daha yüksek |
[08]Fiyatı ne belirler?
Sabit paket fiyatı yayınlamıyoruz; çünkü iki “mobil uygulama” ekran sayısı, kullanıcı rolleri, araştırma ihtiyacı ve mevcut tasarım sistemi açısından çok farklı iş yükü olabilir. Görüşmeden sonra kapsamı, yöntemi, takvimi ve fiyatı yazılı iletiriz. Dış katılımcı paneli gibi üçüncü taraf maliyetler ayrıca yazılır.
- Katılımcı ve oturum sayısı
- Test edilecek akış sayısı
- Prototipin bizde mi sizde mi hazırlanacağı
- Cihaz ve platform çeşitliliği
- Tekrar test turu
[09]Sık sorulanlar
Sorun bulmaya yönelik nitel testlerde her kullanıcı grubu için az sayıda katılımcıyla başlayıp düzeltme sonrası tekrar test etmek verimlidir. Oranları istatistiksel güvenle ölçmek istiyorsanız çok daha fazla katılımcı gerekir; hedefinize göre birlikte belirleriz.
İkisi de olur. Tıklanabilir bir prototiple test, kod yazılmadan sorunları yakalar ve en ucuz düzeltmeyi sağlar. Yayındaki üründe test ise gerçek veriyle davranışı gösterir.
Evet, öneriyoruz. Oturumu canlı izleyen geliştirici ve ürün yöneticileri, bulgulara rapordan çok daha hızlı ikna olur. İzleyiciler katılımcıya görünmez ve oturuma müdahale etmez.
Tasarım düzeltmelerini yapıp geliştirici ekibinize devredebiliriz; kodlamayı sizin ekibiniz yapar. Kritik sorunlar düzeltildikten sonra kısa bir tekrar testi öneririz.
Ürününüzü birlikte inceleyelim
Görüşmede ürününüzü, kullanıcılarınızı, takıldıkları yerleri ve ekibinizin yapısını konuşur; yazılı bir kapsam, yöntem ve takvim önerisi çıkarırız. Bağlayıcı değildir.