Ödeme sürecindeki kayıpları görev ve verilerle araştırmak
Somut bir örnek, ödeme sürecini değiştirmeden önce mobil görev gözlemini, dönüşüm hunisini ve ödeme olaylarını bir araya getiriyor.
Başlanan ve tamamlanan ödeme süreçleri arasındaki fark, araştırmaya nereden başlanabileceğini gösterir. Somut bir değişiklik için gözlenen akışa ve ilgili teknik olaylara da ihtiyaç vardır. Küçük bir soruyla başlayın: Akıllı telefondaki belirli bir satın alma görevi nerede aksıyor?
Önce neyin sayıldığını belirlemek
Zaman aralığını, cihaz türünü ve huninin adımlarını tanımlayın. Aynı kurallarla sayılan oturumları karşılaştırın; sipariş ile oturum farklı sayım birimleridir. Shopify belgeleri ayrıca açık ve kapalı hunileri ayırır. Karşılaştırma, girişlerin ve adım sıralarının aynı biçimde ele alınmasıyla anlamlı olur. Ölçüm sistemi değiştiğinde, davranışın değiştiğini düşünmeden önce tanımları da kontrol edin.
Somut bir araştırma örneği
Kurgusal bir çizim malzemesi mağazası şu görevi incelemek istiyor: çizim dosyası seçmek, misafir olarak teslimat adresi girmek, gönderim yöntemini seçmek ve ödemeye ilerlemek. Tablodaki bütün sayılar ve gözlemler kurgusaldır; farklı bulguların nasıl bir araya getirilebileceğini gösterir.
Kaynak | Kurgusal bulgu | Çıkarım sınırı |
|---|---|---|
Kapalı mobil huni | 100 oturum ödeme sürecine ulaşır; 60 oturum aynı gözlem süresinde süreci tamamlar. | Fark görünür, nedeni henüz bilinmez. |
Geçersiz posta kodundan sonra hata metni ekranın görünür alanı dışında kalır. | Bu akışta somut bir engel vardır. | |
Ödeme kontrolü | Bu görevle eşleştirilmiş bir ödeme isteği bulunmaz. | Bu durum bankanın ödemeyi reddettiğini kanıtlamaz. |
Önce ödeme kayıtlarının incelenen işlemi eksiksiz yansıtıp yansıtmadığını kontrol edin. Eksik kayıt, eşleştirmedeki bir boşluktan da kaynaklanabilir. Formun ödeme isteği iletilmeden önce durduğu anlaşılırsa ek bir ödeme yöntemi bu form hatasını gidermiş olmaz.
Görevi gerçek cihazda gözlemek
Görevin uygun bir test ortamında yapılmasını sağlayın. Cihazı, tarayıcıyı, klavyenin durumunu ve son anlaşılır adımı kaydedin. Kişi hangi alanın hatalı olduğunu anlayabiliyor mu? Önceden girilen bilgiler korunuyor mu? Adres düzeltilip seçilen gönderim yöntemiyle devam edilebiliyor mu?
Ödeme kontrolü bu gözlemi tamamlar. Örneğin Shopify, banka kararından, ödeme hizmetinden veya mağaza ayarından kaynaklanan hataları açıklıyor. Ekrandaki genel bir mesaj, bunlardan hangisinin yaşandığını tek başına göstermez. Tamamlanmayan bütün alışverişleri ödeme hatası saymak yerine mevcut olayları ilgili test işlemiyle eşleştirin.
Bulgudan kontrol edilebilir bir değişiklik çıkarmak
Örnekte sonraki tasarım şöyle: ilgili adres alanına ulaşılabiliyor, hata o alanda anlaşılır metinle açıklanıyor ve diğer bilgiler korunuyor. W3C, otomatik algılanan giriş hatasında hatalı alanın belirtilmesini ve hatanın metinle anlatılmasını açıklıyor. Önerilen değişiklik, henüz eksiksiz erişilebilirlik denetimi anlamına gelmez.
Uygulamadan sonra aynı görevi tekrarlayın; ardından aynı tanımlı hunideki gelişimi inceleyin. Ürün teklifinde veya ziyaretçi kaynaklarında yapılan başka değişiklikleri de kaydedin. Başarılı bir görev denemesi bu akışın kullanılabilirliğini gösterir; genel bir ciro etkisini tek başına kanıtlamaz.
Kaynaklar
Devamını okuyun
Tüm yazılar
ASES ile E-ticaret
Online mağazalar, pazar yerleri ve B2B portalları