Doğru zamanda değerli bilgiler: Kullanıcı testi için ideal tasarım aslına uygunluk düzeyini belirleme

Intercom'da ürün geliştirme ilkelerimizden biri büyük düşün, küçük başla, hızlı öğren.

Hızlı öğrenmenin yollarından biri, izlediğimiz ürün tasarımı yönünde güven oluşturmak için değerlendirici araştırma yapmaktır. Genellikle, ürün geliştirme sürecinde, herhangi bir kod yazılmadan çok önce, ürün konseptlerini kullanıcıların önüne çıkarmayı amaçlıyoruz.

Kullanıcı testine yönelik bu yaklaşım, önemli ve devam eden bir soruyu gündeme getiriyor: araştırma katılımcılarınıza sunmak için doğru tasarım uygunluğu düzeyi nedir? Onları test edenlerden doğru içgörüler elde etmek için bu kavramların nihai tasarıma ne kadar yakın olması gerekiyor? Bir yanda "ham ama erken" ile diğer yanda "cilalanmış ama geç" arasındaki doğru dengeyi nasıl buluyorsunuz? Hangi düzeyde tasarım soyutlaması tatlı noktaya çarpıyor?

“Katılımcılara ne gösterileceği konusunda şirket içinde konuşurken ' tasarım' terimini kullanmaktan kaçınmanın yararlı olduğunu gördük - ' araştırma teşviki' kullanmayı tercih ediyoruz”

kelimeler önemlidir

Her şeyden önce, tasarımın aslına uygunluğu hakkında konuşsak da, kullanıcı testi sırasında katılımcılara ne gösterileceği hakkında şirket içinde konuşurken "tasarım" terimini kullanmaktan kaçınmanın yararlı olduğunu gördük - "araştırma teşviki" kullanmayı tercih ediyoruz. “Araştırma uyarıcısı” veya “provokasyon eseri” gibi terimler kulağa biraz hantal gelse de, bir katılımcıya göstereceğiniz şeyin belirli tasarım özelliklerinden ziyade genel bir konsepte ilişkin içgörüler ortaya çıkarmak için bir araç olduğunu iletmeye yardımcı olur.

Sorunu tanımlayın

Araştırma teşvikini oluştururken mevcut en son, en parlak tasarım dosyalarını kullanmak cazip gelebilir, ancak bu, dikkate alınması gereken belirli maliyetlerle birlikte gelir. Katılımcılar, sağladığınız en yüksek aslına uygunluk düzeyine dikkat edeceklerdir - bir kavramın değeri olup olmadığıyla ilgileniyorsanız, katılımcıların bir CTA'da mikrokopi hakkındaki yorumlarını duymak, aradığınız geri bildirime gürültü katabilir.

Bunun yerine, öğrenmeye çalıştığımız sorunla başlamanın ve bunu, kullanıcı testi sırasında araştırma katılımcılarına gösterdiğimiz şeyin aslına uygunluğuyla eşleştirmenin yararlı olduğunu gördük.

Bu nedenle, doğru tasarım aslına uygunluğunu belirlemek için aşağıdaki sorunlardan hangisini çözmeye çalıştığınızı belirlemeniz gerekir:

• Test kavramları: Bu fikrin değeri var mı?
• Sistem tasarımını test etme: Kullanıcılar bu sistem hakkında 'yeterince iyi' bir anlayış oluşturabilir mi?
• Kullanılabilirliği test etme: İnsanlar bu ürünü kullanabilir mi?

Çözmeye çalıştığınız soruna karar verdikten sonra, bu, araştırma uyaranınız için hangi düzeyde tasarım uygunluğunun gerekli olduğunu belirlemenize yardımcı olacaktır.

Sorunu önceden netleştirmek aynı zamanda tasarım, ürün ve mühendislikte işlevler arası ortaklarınızla uyum oluşturmanıza yardımcı olur - daha da önemlisi bir araştırma teşviki oluşturmak işbirlikçi bir çabadır ve sahipliğin belirsiz olabileceği bir çabadır.

“İlk aşamalarda, onunla nasıl etkileşime girecekleriyle ilgilenmiyorsunuz. Onlar için değerli olup olmayacağıyla ilgileniyorsunuz”

Test kavramları: Bu fikrin değeri var mı?

Bu aşamada probleminiz “Bu fikrin bir değeri var mı?” sorusudur. Spesifik olarak, müşteriler bu fikrin mücadele ettikleri sorunları çözmelerine yardımcı olacağını düşünüyor mu? İlk aşamalarda, onunla nasıl etkileşime girecekleriyle ilgilenmiyorsunuz. Onlar için değerli olup olmayacağıyla ilgileniyorsunuz.

Testin kendisi sırasında, katılımcının çözmeye çalıştığınız sorunu gerçekten deneyimlediğini doğrulamak, onlara kavramı göstermek ve sorunun değerli bir şekilde çözmesini bekleyip beklemediklerini değerlendirmek isteyeceksiniz.

Test uyaranınızın bu noktada bir arayüz gibi görünmesi gerekmez. Aslında, olmaması muhtemelen daha iyidir – eğer kavramları bir arayüz olarak sunmayı seçerseniz, katılımcılarınızın onunla nasıl etkileşime gireceklerini, bunun geri kalanıyla nasıl bir ilişkisi olacağını düşünmeye başlayabileceğini unutmayın. ürününüz ve görsel tasarım hakkında ne düşündükleri. Bu tür bir geri bildirim vermek daha kolaydır, bu nedenle katılımcılar kavramın kendisi ve yaşadıkları sorunu nasıl ele alabileceği hakkında derinlemesine düşünmek yerine doğal olarak ona yöneleceklerdir. Araştırma uyaranınızın sadece test ettiğiniz fikri iletmesi gerekiyor, başka bir şey değil.

Hızlı metin açıklamaları, resimli taslaklar, açılış sayfası maketleri, Google Slaytlar'daki diyagramlar veya beyaz tahta tarzı karalamalar meşru seçeneklerdir. Gereksiz kopyaları bulanıklaştırarak ve bariz yer tutucu grafikleri kullanarak basit ve odaklanmış tutun.

Sistem tasarımını test etme: Kullanıcılar bu sistem hakkında 'yeterince iyi' bir anlayış oluşturabilir mi?

Bazen bir ürün ekibi, arayüzler veya akışlar yerine bütün bir sistemi oluşturmaya çalışıyor olabilir . Bu aşamada araştırma yaparken, sorunuz muhtemelen, ekibin şimdiye kadar tasarladıklarına dayanarak, kullanıcılarınızın ürünü engellemeden veya kafa karıştırmadan kullanmalarını sağlayacak işlevsel zihinsel modeller oluşturup oluşturamayacağıdır . Bunun en iyi kanıtı, kullanıcıların sisteminizde temsili görevleri nasıl yapacakları konusunda doğru tahminlerde bulunup bulunamayacaklarıdır.

Basitçe sistemin soyut diyagramlarını gösterip kullanıcılara sistemle nasıl etkileşimde bulunmayı umduklarını sorabilirsiniz, ancak bunun ekolojik geçerliliği pek yoktur; aslında daha çok kullanıcı arayüzüne benzeyen uyaranları göstermek, araştırmayı daha gerçekçi hissettiriyor. Yine de, bir katılımcıdan gerçekten bir prototip kullanmasını istemenin , dikkatlerinin etkileşim tasarımına yönlendirilmemesini neredeyse imkansız hale getirdiğini ve muhtemelen hala bunun için çözmüyorsunuz.

Onlara gerçekçi problemler verin ve ekranınızı paylaşırken ve onları üründe hareket ettiren belirli etkileşimlerle ilgilenirken, sahte arayüzlerinizi kullanarak bunlarla nasıl başa çıkmayı umdukları konusunda sizinle konuşmalarını isteyin. Bu, sizi ya tasarım yönüne güvenmeden önce tamamen etkileşimli prototipler oluşturmaktan ya da hala hantal olduğunu bildiğiniz etkileşimlerle sinir bozucu katılımcıları riske atmaktan kurtaracaktır.

Kullanılabilirliği test etme: İnsanlar bu ürünü kullanabilir mi?

Bu aşamada, bir kullanıcının ürününüzle gerçekçi bir destek düzeyiyle etkileşime girip giremeyeceğini bilmek isteyeceksiniz (örneğin, nihai üründe sağlayabileceğinizden daha fazla işe alım yok) ve sorunu temsil eden görevleri yerine getirip getiremeyeceğini bilmek isteyeceksiniz. çözüyoruz.

Kullanılabilirlik testinin birçok türü vardır ve hepsinde etkileşim tasarımı daha önemli hale gelir. Katılımcılarınızın gerçekleştirmesini ve test etmesini istediğiniz görevler ve bunları etkinleştirmek için gereken etkileşimler prototipte desteklendiğinden, kullanılabilirliği farklı seviyelerdeki prototiplerle test edebilirsiniz.

Özetle

Bu aşamalar arasındaki çizgiler bulanık ve durumunuza uygun doğru protokolü bulmak zor olabilir. Hem araştırma uyaranını hem de oturumdan oturuma sorduğunuz soruları değiştirmeye hazırlanın.

Son olarak, katılımcılarınıza araştırma uyaranları yerine araştırma oturumunu nasıl bulduklarını sormanın bir zararı yoktur. Karışıklık veya hayal kırıklığı, yapacak daha çok işiniz olduğuna dair bir işarettir. Ve takılırsanız, sorunla başlamayı unutmayın: kullanıcı test oturumundan tam olarak ne elde etmeye çalışıyorsunuz?

Ekibimizle çalışma hakkında daha fazla bilgi edinmek ister misiniz? Değerlerimiz, çalışma şeklimiz ve açık rollerimiz hakkında buradan bilgi edinin.