UX Analizi mi, Kullanıcı Araştırması mı, Kullanılabilirlik Testi mi?

Bir dijital üründe işler beklendiği gibi gitmediğinde sorun çoğu zaman benzer cümlelerle tarif edilir: Kullanıcılar kayıt işlemini tamamlamıyor. Yeni özellik yeterince kullanılmıyor. Destek ekibine aynı sorular geliyor. Mobil uygulama yenilendiği hâlde beklenen iyileşme görülmüyor.

Bu noktada ürün ekibinin önüne birkaç seçenek çıkar: UX analizi yaptırmak, kullanıcı araştırması başlatmak veya kullanılabilirlik testi planlamak. Birbirine yakın görünen bu çalışmalar farklı sorulara yanıt verir. Yanlış kapsamla başlamak ise ekibin eline kapsamlı bir rapor geçmesine rağmen asıl belirsizliğin devam etmesine neden olabilir.

UX analizi, mevcut deneyimdeki olası sorunları sistematik biçimde değerlendirmeye yardımcı olur. Kullanıcı araştırması, insanların ihtiyaçlarını, davranışlarını ve kullanım koşullarını anlamaya yönelik geniş bir çalışma alanıdır. Kullanılabilirlik testi ise kullanıcıların belirli görevleri bir arayüz üzerinde nasıl gerçekleştirdiğini gözlemleyen bir araştırma yöntemidir.

Dolayısıyla bunlar birbirinden tamamen bağımsız üç hizmet kutusu değildir. Kullanılabilirlik testi, kullanıcı araştırmasının içinde yer alır. UX analizi veya UX denetimi olarak sunulan bir çalışmanın kapsamı da mevcut verilerin incelenmesini, uzman değerlendirmesini ve ayrıca planlanmış araştırma çalışmalarını içerebilir. Karar verirken hizmetin adından önce hangi soruya cevap aradığınıza bakmanız gerekir.

UX analizi nedir, hangi sorulara cevap verir?

UX analizi; bir dijital ürünün kullanıcı akışlarını, bilgi yapısını, arayüz davranışlarını ve mevcut deneyim verilerini belirli hedefler doğrultusunda değerlendirme çalışmasıdır. Piyasada UX denetimi veya UX audit ifadeleriyle de karşılaşabilirsiniz. Bu isimlerin her sağlayıcıda aynı kapsamı ifade ettiğini varsaymamak gerekir.

Örneğin bir mobil uygulamada para transferi deneyimi incelenirken yalnızca ekranların görsel düzeni değerlendirilmez. Kullanıcının alıcıyı nasıl seçtiği, işlem ücretini ne zaman gördüğü, transfer durumunu nasıl anladığı ve bir hata olduğunda ne yapabildiği de ele alınır. Analizin birimi tek bir ekran olabileceği gibi, kullanıcının hedefini tamamladığı bütün akış da olabilir.

Uzman değerlendirmesinde kullanılabilirlik ilkeleri yol gösterir. Nielsen Norman Group’un yayımladığı 10 kullanılabilirlik ilkesi, sistem durumunun görünürlüğü, tutarlılık, hata önleme ve kullanıcının kontrolü gibi başlıklarda ortak bir değerlendirme zemini sunar. Bu ilkeler, bulguların kişisel beğeniden ayrılmasına yardımcı olur.

Ancak uzman değerlendirmesinin sınırı açıktır: Bir sorunun olası etkisini gerekçelendirmek, gerçek kullanıcıların bu sorunla hangi sıklıkta karşılaştığını ölçmekle aynı şey değildir. Bir uzmanın “Bu işlem durumu belirsiz” tespiti değerlidir. “Müşteriler bu nedenle ürünü terk ediyor” iddiası ise ek kanıt gerektirir.

Nitelikli bir UX analizi çıktısı bu ayrımı korumalıdır. Her bulgunun hangi akışta ortaya çıktığı, hangi kanıta dayandığı, kullanıcı açısından ne tür bir risk taşıdığı ve nasıl ele alınabileceği anlaşılmalıdır. Doğrudan düzeltilebilecek sorunlarla kullanıcı araştırması gerektiren varsayımlar ayrı görünmelidir.

Kullanıcı araştırması nedir, ne zaman gerekir?

Kullanıcı araştırması, ürün kararlarına temel oluşturmak için insanların ihtiyaçları, davranışları, beklentileri ve kullanım koşulları hakkında sistematik bilgi toplamayı amaçlar. Bir özelliğin nasıl tasarlanacağından önce, neden gerekli olduğunu veya kimin için değer yarattığını anlamaya da yardımcı olur.

Bir B2B SaaS ürününde raporlama özelliğinin az kullanıldığını düşünün. Arayüzün karmaşık olması olası açıklamalardan biridir. Fakat raporu hazırlayan kişiyle onaylayan kişi farklı olabilir; ihtiyaç duyulan veri başka bir sistemde bulunabilir veya raporun çıktısı müşterinin gerçek iş akışına uymayabilir. Bu durumda yalnızca raporlama ekranını sadeleştirmek problemi çözmeyebilir.

Araştırma sorusuna göre kullanıcı görüşmeleri, bağlamsal gözlem, günlük çalışmaları, anketler veya kullanılabilirlik testleri seçilebilir. Nielsen Norman Group’un UX Research Cheat Sheet rehberi de araştırmanın tasarım sürecinin farklı aşamalarında kullanılabileceğini gösterir. Araştırmayı yalnızca projenin başında yapılan bir keşif faaliyeti olarak sınırlandırmak gerekmez.

Burada kritik ayrım, insanların söyledikleri ile yaptıkları arasında kurulur. Bir görüşmede kişinin önceki deneyimlerini, hedeflerini ve gerekçelerini öğrenebilirsiniz. Bir arayüzü bağımsız kullanıp kullanamadığını anlamak için ise davranışını gözlemlemeniz gerekir. “Bu özelliği kullanır mıydınız?” sorusuna verilen olumlu yanıt, gelecekteki kullanımın kanıtı değildir.

Araştırmanın değeri, toplanan alıntı veya hazırlanan persona sayısıyla ölçülmemelidir. Çalışma sonunda ekibin hangi varsayımı değiştirdiği, hangi kullanıcı grubuna öncelik verdiği ve hangi ürün kararını daha güçlü gerekçelerle alabildiği görünür olmalıdır.

Kullanılabilirlik testi nedir, neyi ortaya çıkarır?

Kullanılabilirlik testi, hedef kullanıcı profiline uygun katılımcıların gerçekçi görevleri bir ürün veya prototip üzerinde gerçekleştirirken gözlemlenmesidir. Amaç, görev sırasında karşılaşılan güçlükleri ve bunların ortaya çıktığı koşulları anlamaktır. Nielsen Norman Group’un kullanılabilirlik testi rehberi yöntemin temelinde katılımcı, görev ve gözlem ilişkisini açıklar.

Bir rezervasyon uygulamasında “Tarih seçme alanını beğendiniz mi?” diye sormak yerine, katılımcıya belirli bir gün ve kişi sayısı için uygun rezervasyon oluşturma görevi verilebilir. Böylece kişinin uygunluğu nasıl kontrol ettiği, koşulları nerede aradığı ve işlem sonunda neyi anladığı gözlemlenir.

Testin çıktısı yalnızca başarı veya başarısızlık değildir. Kararsız kalınan noktalar, yanlış seçimler, geri dönüşler, yardım ihtiyacı ve görev sonunda oluşan beklentiler de önemlidir. Özellikle finansal işlemlerde kullanıcı son ekrana ulaşsa bile ücretin veya işlemin gerçekleşme zamanının yanlış anlaşılması önemli bir bulgu olabilir.

Bununla birlikte test sonucu bütün ürün başarısını açıklamaz. Bir akışın kolay kullanılması, özelliğin pazarda talep göreceğini veya müşterilerin bunun için ödeme yapacağını tek başına göstermez. Küçük bir nitel çalışmada görülen sorunların tüm kullanıcı kitlesindeki yaygınlığını da doğrudan hesaplayamazsınız.

Kullanılabilirlik testi planlanırken hangi kullanıcı gruplarının, görevlerin ve cihaz koşullarının kapsandığı açık olmalıdır. Sadece deneyimli müşterilerle yapılan çalışma ilk kez gelenlerin sorunlarını kaçırabilir. Sadece mobilde yapılan bir test, masaüstündeki karmaşık operasyon görevlerini temsil etmeyebilir.

UX analizi, kullanıcı araştırması ve test arasındaki farklar

Aşağıdaki tabloda UX analizi, uzman değerlendirmesi ve mevcut veri incelemesi ağırlıklı bir kapsamı ifade eder. Bir teklifin içine kullanıcı testleri de eklenmişse bu ek kapsam ayrıca belirtilmelidir.

Bu tablo bir üstünlük sıralaması değildir. Doğru yöntem, ekibin çözmeye çalıştığı belirsizliğe göre değişir. Hatta aynı ürün kararında iki veya üç yaklaşımın birlikte kullanılması gerekebilir.

Hangi durumda nereden başlamalısınız?

Canlı ürününüzde sorunlar var, ancak öncelikler net değilse

Ürün büyüdükçe farklı dönemlerde tasarlanan akışlar arasında tutarsızlıklar oluşabilir. Destek talepleri artar, ekip farklı sorunlara işaret eder ve herkes kendi alanını öncelikli görür. Mevcut analitik ve destek kayıtlarıyla birlikte yapılan odaklı bir UX analizi, araştırılması ve düzeltilmesi gereken alanları görünür hâle getirebilir.

Burada bütün ürünü aynı derinlikte incelemek şart değildir. İlk çalışma kayıt, ödeme veya kritik operasyon akışı gibi sınırlandırılmış bir kapsamla başlayabilir. Çıktı, açık sorunlar için tasarım görevleri ve belirsiz kalan konular için araştırma soruları üretmelidir.

Yeni bir özellik planlıyor, ihtiyacı yeterince anlamıyorsanız

Bir özelliği test etmek için önce bir çözüm üretmek mümkündür. Ancak asıl belirsizlik insanların o çözüme ihtiyaç duyup duymadığıysa, erken aşamada kullanıcı araştırması daha anlamlı bir başlangıç olabilir.

Örneğin kurumsal bir platforma yeni bir onay ekranı eklenmesi istenebilir. Araştırma, asıl sorunun onay ekranından çok rollerin belirsizliği veya eksik bilgiyle açılan talepler olduğunu ortaya çıkarabilir. Böyle bir durumda tasarım kapsamı değişir. Ekip, yanlış probleme ayrılacak geliştirme eforunu henüz çözüm kesinleşmeden yeniden değerlendirebilir.

Prototipiniz hazır, kullanıcıların anlayıp anlamadığını görmek istiyorsanız

Bu durumda kullanılabilirlik testi doğrudan cevap üretebilir. Görevler, tasarımın kritik varsayımlarını sınayacak şekilde hazırlanır. Katılımcıya hangi butona basacağı söylenmez; ulaşması gereken amaç ve gerekli bağlam verilir.

Prototipin sınırlarını da test yorumuna dahil etmek gerekir. Çalışmayan arama, sınırlı veri veya eksik hata durumları kullanıcı davranışını etkileyebilir. Bu kısıtlar, tasarım problemiyle karıştırılmadan raporlanmalıdır. Test sonrası yapılan değişikliklerin aynı sorunu çözüp çözmediği gerektiğinde yeni bir turla değerlendirilir.

Dönüşüm düşüyor, nedenini bildiğinizi düşünüyorsanız

Analitik veride düşüş görmek, nedeni kesinleştirmez. Aynı ekranı terk eden kişiler fiyatı yüksek bulmuş, teknik hatayla karşılaşmış veya yalnızca bilgi almak için gelmiş olabilir. Öncelikle ölçümün doğru çalıştığını ve karşılaştırılan trafik gruplarının anlamlı olduğunu kontrol etmek gerekir.

Ardından soruya göre yöntem seçilir. Akıştaki zorluğu anlamak için test, karar bağlamını öğrenmek için görüşme, teknik hata için ilgili log ve performans incelemesi gerekebilir. UX çalışması diğer disiplinlerin bulgularıyla birlikte değerlendirildiğinde daha doğru bir açıklama üretir.

Bir fintech akışında üç yaklaşım nasıl birlikte çalışır?

Aşağıdaki senaryo yöntemi açıklamak için kurgulanmıştır; bir VOYA müşteri projesinin sonucu değildir.

Bir dijital cüzdanın ilk para yükleme işleminde kullanıcı kaybı yaşadığını düşünelim. Ekip, kart bilgisi formunun uzun olduğunu varsayıyor ve alan sayısını azaltmak istiyor. UX analizi sırasında işlem ücreti bilgisinin geç gösterildiği, yükleme durumunun belirsiz kaldığı ve hata mesajlarının sonraki adımı açıklamadığı görülüyor.

Bu inceleme, olası sorunları tanımlar. Ancak kullanıcıların neden vazgeçtiğini tek başına kesinleştirmez. İlgili kullanıcılarla yapılacak görüşmeler, para yüklemeden önce hangi koşulları öğrenmek istediklerini ve önceki deneyimlerinin beklentilerini nasıl etkilediğini araştırabilir. Görüşmelerde anlatılanların da hatırlama sınırları ve kişisel yorumlar içerdiği dikkate alınır.

Sonraki testte katılımcıdan, belirlenen bir alışveriş için cüzdanında yeterli bakiye oluşturması istenir. Araştırmacı, kişinin ücreti nerede aradığını, işlem sonucunu nasıl yorumladığını ve başarısız işlemde hangi adımı attığını gözlemler. Böylece form uzunluğu varsayımı, başka açıklamalarla birlikte değerlendirilir.

Çözüm; alanları azaltmak, ücret bilgisini daha erken göstermek, işlem durumunu açıklamak veya hata sonrası toparlanmayı iyileştirmek olabilir. Seçim, bulgulara bağlıdır. Yeni tasarımın test edilmesi ve yayımlandıktan sonra uygun ürün göstergelerinin izlenmesi, kararın devamını oluşturur. Önceden belirlenmiş bir tasarımı haklı çıkarmak için araştırma yapılmamalıdır.

B2B SaaS ürünlerinde kullanıcıyı doğru tanımlamak

Kurumsal ürünlerde satın alan, sistemi yöneten ve günlük işleri yapan kişi çoğu zaman farklıdır. Araştırma kapsamını yalnızca satın alma kararını verenlerle sınırlamak, gerçek kullanım sorunlarını görünmez bırakabilir. Buna karşılık yalnızca son kullanıcılarla görüşmek de yetkilendirme veya yönetim gereksinimlerinin eksik anlaşılmasına yol açabilir.

Bir operasyon platformundaki görev, tek bir kullanıcının ekranında başlayıp bitmeyebilir. Talebi açan, kontrol eden ve onaylayan roller arasında bilgi aktarımı gerekir. Tek ekranın kullanılabilir olması, bu aktarımın sorunsuz olduğu anlamına gelmez. UX analizi rol geçişlerini görünür kılabilir; kullanıcı araştırması işin gerçek koşullarını açıklayabilir; test ise seçilen görevlerin tasarlanan akışta nasıl ilerlediğini gösterebilir.

Bu nedenle katılımcı planı hazırlanırken unvandan çok sorumluluk, deneyim seviyesi, kullanım sıklığı ve görev bağımlılıkları dikkate alınmalıdır. Erişilebilirlik ihtiyaçları ve kullanılan yardımcı teknolojiler de ürünün hedef kitlesine uygun biçimde kapsama alınmalıdır.

Araştırma çıktısı ürün kararına nasıl dönüşür?

Bir raporda çok sayıda sorun bulunması, çalışmanın uygulanabilir olduğu anlamına gelmez. Ekibin hangi sorunu neden önce ele alacağını ve iyileşmeyi nasıl değerlendireceğini bilmesi gerekir. Bunun için bulgu, yorum ve çözüm önerisi birbirinden ayrılmalıdır.

Örneğin “Kullanıcılar onay ekranına güvenmiyor” geniş bir yorumdur. “Katılımcı, işlem sonrası tutarın hesabından düşüp düşmediğini anlamak için ana sayfaya döndü” ise belirli bir gözlemdir. Bu gözlemden türetilen hipotez, işlem durumunun yeterince açık olmadığı olabilir. Hipotez ile gözlemin aynı cümlede kesin bilgi gibi sunulmaması önemlidir.

Önceliklendirmede kullanıcı üzerindeki etki, sorunla karşılaşılan bağlam, kanıtın gücü ve çözüm bağımlılıkları birlikte değerlendirilir. Uygulama maliyeti önemlidir; ancak kolay düzeltilebilen görsel sorunların kritik görev hatalarını sürekli geride bırakmasına izin verilmemelidir.

UX araştırması veya test hizmeti alırken kapsamı nasıl yazmalısınız?

İyi bir brief, yalnızca “Uygulamamız için kullanıcı testi istiyoruz” demekle sınırlı kalmaz. Karar verilmesi gereken konuyu, hangi kullanıcı grubunun etkilendiğini, eldeki verileri ve çalışma sonunda beklenen kararı açıklar. Örneğin “Yeni müşterilerin ilk işlemi bağımsız tamamlayıp tamamlayamadığını ve işlem sonucunu doğru anlayıp anlamadığını değerlendirmek istiyoruz” daha uygulanabilir bir başlangıçtır.

Teklifte incelenecek akışlar, katılımcı kriterleri, araştırma yöntemi, analiz kapsamı ve teslimatların kullanım şekli bulunmalıdır. Katılımcı bulma süreci, teşvikler, oturum sayısı, sentez çalışması, ekip çalıştayları ve tekrar testinin dahil olup olmadığı bütçeyi etkiler. Yalnızca görüşme sayısına bakarak teklif karşılaştırmak yeterli değildir.

Katılımcı sayısı da araştırma sorusundan bağımsız belirlenmemelidir. Erken bir nitel test ile segmentler arasında başarı oranı karşılaştırmayı amaçlayan nicel çalışma aynı örneklem planına ihtiyaç duymaz. Teklif, seçilen kapsamın hangi soruları yanıtlayabileceğini ve hangi genellemeleri desteklemeyeceğini açıkça söylemelidir.

Finansal veya kurumsal ürünlerde araştırma ortamı ayrıca planlanmalıdır. Gerçek para hareketi gerektirmeyen senaryolar, uygun test hesapları ve gereksiz kişisel veri toplamayan oturum düzeni tercih edilebilir. Araştırmanın amacı için gereken bilgi ile kurumun hassas verilerini birbirinden ayırmak, çalışmanın uygulanabilirliğini de artırır.

Sık sorulan sorular

UX analizi ile kullanılabilirlik testi aynı şey mi?

Hayır. UX analizi uzman incelemesi ve mevcut veriler üzerinden olası sorunları değerlendirebilir. Kullanılabilirlik testi ise gerçek katılımcıların görev sırasındaki davranışını gözlemler. Bir UX analizi paketinde test bulunabilir; bu nedenle kapsamın açıkça yazılması gerekir.

Kullanıcı araştırması için ürünün hazır olması gerekir mi?

Hayır. İhtiyaçları ve mevcut çalışma biçimlerini anlamaya yönelik araştırmalar ürün tasarlanmadan önce yapılabilir. Belirli bir arayüzün kullanılabilirliğini değerlendirmek için ise ilgili görevleri destekleyen bir ürün veya prototip gerekir.

Analitik ve oturum kayıtları kullanıcı testinin yerine geçer mi?

Analitik ve oturum kayıtları davranış örüntülerini ve incelenecek noktaları bulmaya yardımcı olur. Ancak kişinin amacı, beklentisi veya kararının nedeni her zaman bu verilerde görünmez. Test ve görüşmeler, soruya bağlı olarak bu eksik bağlamı araştırabilir.

AI veya sentetik persona gerçek kullanıcı testinin yerine kullanılabilir mi?

AI, araştırma sorularını taslak hâline getirmek veya olası senaryoları düşünmek için yardımcı olabilir. Sentetik personanın ürettiği cevaplar gerçek bir kişinin ürünü kullanırken gösterdiği davranışın kanıtı değildir. İnsan katılımcılarla doğrulanmamış çıktılar, gerçek kullanıcı bulgusu olarak sunulmamalıdır.

Önce UX analizi mi, kullanıcı araştırması mı yapılmalı?

Sabit bir sıra yoktur. Mevcut üründeki sorunları toparlamak için analizle, ihtiyacın kendisini anlamak için keşif araştırmasıyla, hazır bir çözümün kullanımını değerlendirmek için testle başlanabilir. Kararı belirleyen unsur, ürünün aşaması kadar mevcut bilginin yeterliliğidir.

VOYA ile doğru sorudan başlayın

VOYA’da UX çalışmalarını ürünün hedefleri ve alınması gereken kararlar etrafında ele alıyoruz. Fintech, SaaS ve karmaşık dijital ürünlerde araştırma ile tasarım arasındaki bağlantı, bulguların hangi akışa ve hangi iyileştirmeye dönüşeceğinin netleşmesiyle güçlenir.

Mevcut ürününüzde sorunlar birikmişse odaklı bir analizle başlayabiliriz. Yeni bir yön belirliyorsanız kullanıcıların ihtiyaçlarını araştırabilir, bir çözüm hazırladıysanız kritik görevleri test edebiliriz. Bu çalışmaların UI/UX tasarım sürecine bağlanması, öğrenilenlerin ürün içinde karşılık bulmasını sağlar.

Başlangıç için bütün ürününüzü yeniden tasarlama kararı almanız gerekmez. Önce kullanıcıların zorlandığı bir akışı, bu akışla ilgili bildiklerinizi ve henüz yanıtlayamadığınız soruları birlikte değerlendirebiliriz. VOYA’nın hizmetlerini inceleyerek ürününüz için uygun çalışma kapsamını konuşabiliriz.

Kaynaklar

• Nielsen Norman Group — 10 Usability Heuristics for User Interface Design
• Nielsen Norman Group — UX Research Cheat Sheet
• Nielsen Norman Group — Usability (User) Testing 101