Bir Tasarım Kullanılabilirlik Testi Başarısız Olduğunda Nasıl Biliyorsunuz?
Yanlış işten öğrendiğim kullanışlı bir teknik…
Yıllar önce, kariyer öğrenme konusunda eğitici bir tasarımcı olarak, çevrimiçi öğrenim için kurslar yaratan tuhaf bir yama geçirdim. Kötü bir uyum oldu ve ben mutlu bir şekilde ilerledim, ama bu işin bir kısmı bana daha iyi bir UX tasarımcısı yaptı: öğrenme hedefleri.
Öğrenme hedefleri, öğrencinin eğitimin sonunda öğrenmesini istediğin şeydir. Bir test varsa, test soruları bu hedeflere dayanmalıdır - aksi halde, testin amacı nedir?
Aynı yaklaşım, bir tasarımın kullanılabilirlik testini geçip geçmediğini veya başarısız olduğunu anlamak için kullanışlı bir yöntemdir. Sadece şunu hatırlayın: test edilmekte olan tasarım, katılımcılar değil.
Test katılımcısının, tasarımın başarılı olduğundan emin olmanız için neler yapması veya söylemesi gerekiyor? Belirli bir proje için üç saat sürecek mi? Bir izleyiciye bu izlenen zamana dayalı bir fatura oluşturulsun mu? Faturayı gönder? Bu senin test kriterin.
Elbette kullanılabilirlik testi, kullanıcıların görevleri nasıl tamamladıklarını gözlemlemekle ilgilidir, ancak tam olarak ne yapacaksınız? Bu kriterlerin güzelliği, sizi “zaman izlemenin nasıl çalıştığını anla” gibi belirsiz test hedeflerinden uzaklaştırmalarıdır. Bunu anladıklarını nasıl anlayacaksınız? Onları tarif etmelerini sağla. Ve bunu doğru bir şekilde tanımladıktan sonra, tasarımın yönünün başarılı olduğunu söyleyebilirsin.
Başarı ölçütleri size iki kez yardımcı olur: tasarımınızın gerçekten başarılı olup olmadığını netleştirir ve bu sonuçları paylaşmayı kolaylaştırır.
Fiiller büyülü
Öğrenme hedefleri hakkında bana ders veren kitap, George Piskurich'in Hızlı Öğretim Tasarımı , başarı kriterlerinize başlamak için kullanışlı bir davranış listesi sunar.
Örneğin, anlama hedefleri “tanımlamak” veya “göstermek” olabilir. Yine, “anlaman” hiç de iyi değil - onlara (yani, tarif etmenin) söyleyebilmelerine ya da anladığınızı kanıtlayan bir şeye ihtiyacınız var.
Ve sonra, daha yüksek bir zorluk derecesinde, bir katılımcı “açıklayabilir” veya “organize edebilir”; daha yüksek bir seviyede, “yaratabilirler” veya “değerlendirebilirler”.
Başarı ölçütlerinize başlamak için seçtiğiniz fiil hangisi olursa olsun, bir kullanıcının bir iş başarısı teşkil edip etmediğini veya yapıp yapmadığını gözlemleyebilirsiniz.
“Bu oturumun sonunda…”
Dolayısıyla, bir sonraki kullanılabilirlik testinizi planlarken ve görevler üzerinde çalışıyorsanız, “Bir kullanıcı bu tasarımla ne yapmalı (veya hakkında) yapmalı?” Diye sorarak başlayın.
Sonra böyle bir şey yazabilirsiniz:
Seansın sonunda, katılımcı şunları yapabilmelidir:
- Belli bir proje için üç saatlik süreyi;
- izlenen zamana bağlı olarak bir müşteriye fatura oluşturmak;
- izleme süresi ve günlüğe kaydetme süresi arasındaki farkı tanımlar.
Artık üç tane başarı kriteriniz var ve bunlara dayanarak, katılımcılara vermeniz gereken görevler konusunda da oldukça net bir fikre sahipsiniz.
Bir uyarı: başarı kriterleri görevlerle tamamen aynı değildir. Görevler daha fazla içeriğe sahiptir; Katılımcıya okunmak üzere yazılmıştır ve özellikle prototipinizde bir şey bulmak için onları yönlendiriyorsanız, görevle ilgili bazı bağlamları içerebilir. Örneğin:
Başarı ölçütleri: Bir izleyiciye bu izlenen zamana dayalı bir fatura oluşturun
Görev: “Artık Atlas projesinde üç saat izlediniz, bana zamanınız için Acme Ürünlerini nasıl faturalandıracağınızı gösterin.”
Çok benzer, belli ki, ama başarı kriterleri sizin ve ekibiniz içindir; Görev, kullanılabilirlik oturumu bağlamında katılımcı içindir .
Yukarıdaki başarı ölçütlerinden birinin, bir görevi tamamlamaktan ziyade bir şeyi açıklamakla ilgili olduğunu fark edeceksiniz. Bir göreve bir takip sorusu olabilir. Bunlar tasarımınızın zihinsel modelinin kullanıcılara açık olup olmadığını doğrulamak için kullanışlıdır. Kullanıcıların bir göreve doğru yollarını bulduklarını gördüm, ancak daha sonra bana nasıl tasarlandığını anlatan uygulamanın zihinsel bir modelini anlatın. Bu, bir katılımcı için görev başarısıdır, ancak daha önemlisi, bu katılımcının zihinsel modelini eşleştirmenin altında yatan bir problem vardır.
Böylece, başarı kriterlerinize başlayın, ardından görevlerinizi ve takip sorularınızı kriterlerinize göre yazın.
Paydaşlar başarı kriterlerini sever
Paydaşlar sizin süreçlerinizi önemsememekle birlikte, sonuçları gerçekten önemsiyorlar. Ve sonuçların sunumu belirsiz ise, haklı olarak tahriş olacaklar.
“Kullanıcı birkaç saat izlemeyi başardı, ancak izleme süresinin müşteriye karşı giriş yapmakla aynı olmadığını anlayamadığından emin değildik…” Peki, neden emin değilsiniz? Bunu anlamak senin işin değil mi? Zamanlarını harcıyorsunuz ve UX sorunlarının nasıl düzeltileceği konusunda net bir yön vermiyorsunuz - ki bu da sizin işiniz değil mi?
Başarı ölçütleri size iki kez yardımcı olur: tasarımınızın gerçekten başarılı olup olmadığını netleştirir ve bu sonuçları paylaşmayı kolaylaştırır.
Basit bir tablodaki başarı ölçütlerini takip etme ve sonuçları renk kodlaması ile elde ettik. Öyle:
Vikimızda renk kodlu bir tablo (yeşil = başarı, kırmızı = başarısızlık) tablosu hazırlıyoruz. En üst sırada, katılımcıları listeliyoruz; sol sütunda başarı kriterlerimizi sıralıyoruz. Çirkin, ama hızlı ve kullanışlı.
Bu taraması kolaydır, problemlerin nerede olduğunu açıkça gösterir ve sonuçları gerçek katılımcıların deneyimlerine dayanır. Ayrıca, sonuçların bir mermi noktası özetini ve hemen altındaki kullanılabilirlik sorunları ve önerilerinin bir listesini de listeliyoruz. Bu problemleri sıfırlayacağız ve çözdüklerine inanana kadar yineliyoruz. Süreciniz biraz farklı olabilir - örneğin bir müşteriye bir rapor teslim eden bir danışman olabilirsiniz - örneğin faydalar aynıdır.