👨🏿‍🎓 🌡️ 👩🏼‍🤝‍👨🏿 UX-research of RBS: pengalaman, kesalahan, dan penemuan kami ♥️ 🈳 👩🏿‍🚒

Hei. Saya Denis Elianovsky, Direktur Desain di JTC dan Lead di Opium Pro. Kami bekerja di segmen yang sangat sempit dari pasar TI terkait keuangan dan alur kerja. Anda tentu belum pernah mendengar tentang perusahaan ini dan hari ini Anda tidak akan tahu banyak tentang mereka, karena artikel ini tentang penelitian UX.

Saya telah merancang selama 12 tahun terakhir (8 di antaranya tepatnya merupakan desain antarmuka yang kompleks) dan saya ingin memberi tahu bagaimana kami melakukan pengujian kegunaan aplikasi RBS. Dan juga tentang kesalahan apa yang dibuat dan yang membuat kesimpulan dari ini. Dalam prosesnya, saya merekomendasikan beberapa buku. Semua gambar dapat diklik.

Apa itu RBS?Itu singkatan dari Layanan Perbankan Jarak Jauh. Aplikasi ini juga disebut bank online. Tentunya Anda semua sudah memiliki ini di ponsel Anda. Di sini kita adalah salah satu dari mereka yang merancang dan mengembangkan aplikasi semacam itu.

Anda mungkin akan menemukan sesuatu yang berguna dalam artikel jika Anda telah mendengar tentang penelitian UX dan ingin menguji aplikasi Anda, tetapi tidak tahu harus mulai dari mana. Jika Anda sudah memiliki pengalaman dalam ujian, maka itu akan membosankan dan tidak menarik, maafkan saya.

Siapa yang lebih nyaman menonton video, di sini adalah rekaman pidato

Apa tesnya?

Jika Anda meminta untuk menempatkan deskripsi penelitian UX menjadi 23 kata menggunakan tiga koma, satu tanda hubung dan satu tanda hubung, maka penelitian UX adalah tindakan cepat yang berguna yang dapat dilakukan pada tahap awal pengembangan, dan dengan demikian menghindari kesalahan yang akan keluar dalam produksi. Tetapi rilis aplikasi perbankan dalam produksi tidak hanya merupakan tekanan besar, tetapi juga pemborosan uang yang sangat besar. UX-research memungkinkan Anda untuk menguji aplikasi Anda pada pengguna nyata jauh sebelum Anda mulai membongkar KAMAZ dengan uang ke kantong pengembang dan pemasar.

Tentu saja, setiap desainer (setiap desainer yang baik) menguji aplikasi sebelum rilis. Tetapi biasanya ini dilakukan "di rumah." Artinya, ini diuji pada orang yang dekat dan sayang, dan sangat jarang itu entah bagaimana sistematis. Pada artikel ini saya ingin menyampaikan bahwa dalam pengujian desain aplikasi besar dan kompleks harus diatur dan diintegrasikan ke dalam proses desain itu sendiri.

Pertama, penelitian dapat bersifat kuantitatif dan kualitatif. Ketika kami berbicara tentang penelitian kuantitatif, yang kami maksudkan adalah cakupan audiens: kami berusaha untuk meningkatkan jumlah orang yang kami uji. Ketika kami berbicara tentang penelitian berkualitas, kami menguji beberapa orang, tetapi dengan masing-masing dari mereka kami melakukan wawancara yang lebih rinci dan menyelam lebih dalam ke setiap kasus tertentu.

Koordinat pesawat. Kanan - Kuantitatif. Kiri - Kualitas

Pesawat koordinat yang sama. Di atas adalah perilaku. Bawah - Sikap

Penelitian lebih lanjut dapat dibagi menjadi perilaku dan relasional. Ketika kami melakukan pengujian perilaku, kami memantau apa yang dilakukan seseorang dengan aplikasi kami. Dalam hubungan, penting bahwa orang tersebut berbicara tentang aplikasi kita.

Pada artikel ini, kami akan fokus pada tes Kegunaan. Mereka berhubungan dengan tes kualitas perilaku. Dalam hal ini, sejumlah kecil orang terlibat dalam pengujian dan pada dasarnya apa yang mereka lakukan dengan aplikasi dipelajari dengan cermat.

Pesawat koordinat yang sama. Tanda lingkaran kiri atas

Proses desain tercermin dengan baik dalam jadwal Damien Newman. Dan karena saya katakan di atas bahwa desain dan pengujian harus satu kesatuan, grafik mencerminkan proses pembuatan desain dan pengujiannya. Dua kesimpulan dapat ditarik dari grafik ini. 1) Desain dan pengujian adalah proses non-linear. 2) Dan ini juga merupakan proses berulang. Ini jelas pada pandangan pertama pada grafik, bukan? Apa yang saya maksud dengan nonlinier?

Awalnya, kami memiliki begitu banyak teori yang berbeda yang ingin kami uji melalui prototipe. Dan hanya menjelang akhir proses desain mereka entah bagaimana menetap. Dari waktu ke waktu, dari iterasi ke iterasi, sesi pengujian menjadi lebih mirip satu sama lain dan perubahan dalam desain menjadi semakin berkurang: mereka lebih dalam, lebih rumit, tetapi secara lahiriah lebih sulit untuk melihatnya.

Dengan menyebut proses berulang, maksud saya Anda tidak dapat mengujinya sekali dan berhenti di sana. Pengujian harus dilakukan secara teratur. Maka itu masuk akal. Apalagi mengingat bahwa desainnya juga berubah secara dramatis dalam prosesnya.

Bagaimana cara mempersiapkan studi UX?

Usability- . ? , . . , , ( ), User Story Map. User Story Map .
. , . , . , 10–15 , 20 ( : , , ). , 5–7 -. , . , «» «», -, .
. (5–7 ). , . -. , « » .

Saya akan segera memberikan jawaban untuk pertanyaan paling populer dari pelanggan kami, yang terdengar seperti ini: "Anda mungkin menguji semuanya sendiri untuk memastikan bahwa hasilnya baik?" Tidak. Kami tidak hanya tidak memasukkan hasil kami dalam tes, kami mencoba untuk tidak menyertakan orang dengan deformasi profesional dalam tes, yaitu mereka yang secara profesional terlibat dalam tes uang. Dan kami juga mengecualikan desainer, programmer, dan lainnya yang juga tunduk pada deformasi profesional ini.

Mari kita ulangi apa yang kita butuhkan untuk persiapan konsolidasi.

1. Hipotesis

Gambar di bawah ini menunjukkan beberapa opsi yang memungkinkan untuk memvisualisasikan proses ini. Layar paling kiri adalah bagaimana Anda bisa membuat Peta Cerita Pengguna dengan cara improvisasi. Untuk melakukan ini, cukup gunakan stiker kertas. Dengan menghubungkan mereka dengan string, kami menunjukkan asumsi tentang bagaimana pengguna akan berjalan di sekitar aplikasi. Opsi kedua adalah Peta Cerita Pengguna, yang dibuat di Miro. Bahkan, potongan kertas yang sama, hanya ditransfer ke formulir elektronik untuk kenyamanan. Dan layar ketiga adalah prototipe yang dapat diklik dalam Figma.

Alat khusus di atas ditunjukkan, tetapi sebenarnya tidak ada yang mengikat mereka, dan hipotesis dapat dibangun dalam apa yang nyaman bagi Anda. Misalnya, di tim kami ada penggemar yang melakukan semua pengujian pada selembar kertas. Mereka juga memiliki prototipe yang dapat diklik pada selembar kertas - dan ini juga dapat dimulai.

2. Membuat pertanyaan

Pertanyaan-pertanyaan terbuka. Hebat jika mereka akan dalam bentuk cerita. Artinya, jika kita berasumsi bahwa seseorang harus memblokir kartu untuk menyelesaikan masalahnya, kita tidak mengatakan "Blokir kartu" di dahi kita, kita menceritakan kepadanya sebuah cerita. Idealnya, sejarah harus membenamkan seseorang dalam dirinya sendiri dan memprovokasi dia untuk merespons dengan sejarah juga.

Contoh:

3. Mengumpulkan responden

Jadwal ini disusun oleh Jacob Nielsen pada 1990-an. Bahkan kemudian, studi UX dilakukan. Garis horizontal menunjukkan jumlah orang yang kami uji, dan garis vertikal menunjukkan jumlah kesalahan yang ditemukan. Perlu dicatat bahwa setelah sekitar orang ke-5 yang diuji, jadwal menjadi lebih lembut, tetapi apa artinya ini? Ini berarti bahwa setelah 5 orang efisiensi beralih pada setiap orang tes baru jatuh, dan dengan itu kita menemukan semakin sedikit kesalahan. Jacob Nielsen membuat kesimpulan seperti itu, dan kami sepenuhnya membagikan kesimpulan ini.

Lebih efisien untuk membuat sampel kecil, tetapi sering melakukannya.

Awalnya saya ingin menasihati buku Yakub, tetapi secara umum sudah tua. Ada sesuatu yang lebih baik. Penulis terus terlibat dalam penelitian UX, dan di sini adalah situs webnya, ada banyak artikel: nngroup.com

Proses pengujian

Sial, penting untuk merekam semua tes di video. Video adalah artefak tes yang paling penting. Jika Anda tidak memiliki video, maka kami dapat mengatakan bahwa Anda tidak menguji.

Yang pertama. Sebelum memulai tes, karena kami menguji aplikasi seluler, kami memberikan telepon kepada seseorang. Kami memintanya untuk santai dan pastikan untuk menyuarakan segala sesuatu yang terjadi. Penting bagi kita untuk memahami jalan pikiran subjek.

Kedua, dan kami menyebut aturan ini "5 mengapa?", dalam proses penyaluran naskah, Anda perlu memprovokasi seseorang untuk menjelaskan setiap halangan atau keraguannya dalam tindakannya. Di sini pertanyaan semacam itu sangat membantu: "Apa yang Anda harapkan untuk dilihat di layar ini?", "Mengapa Anda mengklik tombol ini?". Ini tidak selalu tepat mengapa, tetapi keinginan untuk mengajukan sebanyak mungkin pertanyaan dan masuk ke dalam kepala seseorang selalu membantu.

Dan yang ketiga. Berdasarkan hasil tes, kami bertanya, “Apakah Anda pikir Anda telah menyelesaikan tugas? ". Selain itu, tidak hanya responden yang menjawab pertanyaan ini, tetapi juga orang yang sedang menguji. Mengapa kita melakukan ini, saya akan katakan di bawah ini.

Sekarang kami lulus langsung ke tes kami.Tabel tersebut menunjukkan seperti apa hasil ringkasan dari penelitian ini. Ini adalah hasil nyata dari tes pertama kami. Di sebelah kiri adalah daftar pertanyaan dan cerita, diikuti oleh kolom untuk masing-masing responden. Jika biayanya 1, itu berarti bahwa subjek uji dan tester menganggap tugas selesai. Jika 0,5 - itu berarti seseorang sendiri percaya bahwa tugasnya belum selesai. Jika 0 - keduanya setuju bahwa tugas tidak selesai. Dari data ini, kita bisa memahami skenario mana yang kita miliki kuat, yang lemah. Dari data di tabel, kita dapat menyimpulkan bahwa, misalnya, kita berhasil mengunci kartu, semua orang diatasi. Dan dengan transfer uang - tidak terlalu baik, inilah yang harus kita kerjakan.

Kami menguji aplikasi RBS seluler kami untuk perorangan. Secara total, pada saat pembuatan laporan ini, dua iterasi tes lulus, di mana masing-masing 6 orang diuji. Hanya 7 wanita, 5 pria berusia 20 hingga 50 tahun. Awalnya, kami tidak mencoba membuat pilihan profesi yang sangat luas, tetapi ternyata cukup beragam: guru, dokter, pengelola restoran, dll. Karena permintaan klien kami, pada sesi kedua lebih banyak orang berusia 40+ dimasukkan dalam sampel. Dan di antara hadirin inilah sebagian besar kesalahan diidentifikasi. Paling sering mereka tersandung di suatu tempat, berhenti di suatu tempat, dan mereka harus mengajukan sebagian besar pertanyaan.

Hasil tes

Hasil tes dari sudut pandang "diatasi / gagal": Ternyata yang diuji diatasi dengan 93% dari tugas. Selain itu, mereka sendiri percaya bahwa mereka hanya mengelola 83%. Perbedaan 10% ini - saat-saat ketika seseorang berjalan sesuai dengan skenario yang diinginkan, penguji kami melihat bahwa ia mengatasi tugas tersebut, tetapi responden tidak yakin tentang hasilnya. Dan ini juga masalah yang perlu dikerjakan. Lagi pula, kami memahami bahwa pada saat-saat seperti itu aplikasi tidak memberikan umpan balik yang diinginkan kepada orang tersebut dan ini perlu diperbaiki. Rata-rata, satu sesi memakan waktu 12 menit. Hasil yang bagus, dengan mempertimbangkan fakta bahwa kami fokus pada 10-15 menit. Di bawah ini adalah desain aplikasi yang digunakan dalam iterasi pertama tes. Biarkan saya menjelaskan apa yang kami putuskan untuk mengubahnya sesuai dengan hasil tes.

Saya akan memberi tahu atas nama pengguna yang menyodokkan jari ke dalam aplikasi ini.

Misalkan saya perlu membayar untuk ponsel. Mungkin, harus ada tombol "bayar" di suatu tempat. Saya tidak menemukan tombol dan pergi untuk mencarinya di menu burger di sudut kiri atas.

Apa masalahnya? Ada dua tombol "bayar" di layar, tidak ada yang memperhatikannya. Ini dalam 3 kasus dari 6.

Masalah lain. Bagian analitik, yang kami temukan sangat berguna, sayangnya, pengguna tidak menemukannya. Dia hanya membingungkan orang.

Secara umum, jika Anda melihat secara global, maka layar ini kelebihan beban, sulit bagi pengguna untuk memilah-milah di kepala mereka apa dan di mana letaknya.

Layar kedua adalah layar pembayaran / transfer: Selama pengujian, kami menemukan bahwa orang-orang tertarik melihat pembayaran reguler mereka, dan mereka mencari mereka di layar pembayaran. Dalam versi pertama dari desain, mereka berada di tepi dan sebagian disembunyikan oleh gulir horizontal. Nah, pada prinsipnya, mereka berada di tab terpisah, yang juga membuatnya sulit untuk menemukan mereka. Layar ketiga adalah layar dengan produk bank:

Semua orang yang kami uji (ok, hampir semua) mencatat bahwa layar ini bermanfaat. Mereka tahu di mana memanggilnya, mereka sering menggunakannya. Di sini kami menciptakan masalah bagi diri kami dengan menempatkan panggilan ke layar ini di menu burger kiri atas. Dalam video, kami perhatikan bahwa ketika seseorang mencoba menekan tombol ini, banyak yang memotong telepon, dan ini tidak nyaman untuk semua orang.

Sekarang telepon telah menjadi besar, mereka mungkin rontok, dan kami memutuskan bahwa ini adalah masalah bagi kami, kami akan bekerja dengannya. Ngomong-ngomong, coba tebak mengapa penulis artikel berjalan dengan telepon rusak?

Gambar-gambar berikut menunjukkan desain iterasi kedua yang berubah secara signifikan.

Seperti yang Anda lihat, layar menjadi lebih mudah. Sekarang, ketika kami meminta pengguna untuk memberi tahu kami apa yang mereka lihat, mereka memberi tahu kami ini dengan cara yang sama seperti yang kami bayangkan. Bagian analitik telah dihapus di bawah tombol tambahan, sekarang tidak memuat ruang. Di layar pembayaran, pembayaran reguler dilakukan sedemikian rupa sehingga terlihat. Tetapi orang-orang masih terjebak di sini, yang menyiratkan bahwa kami pasti akan meningkatkan dan memfasilitasi itu. Layar ketiga adalah layar dengan daftar produk bank yang dimiliki seseorang. Dan di sini kami mengaksesnya dari bagian bawah ponsel alih-alih memanggilnya dari menu burger kiri atas.

Tiga ponsel baru yang sama. Layar ketiga disorot.

Sekarang objek ini terletak tepat di bawah jari pengguna, dan ia tidak perlu meraihnya, cukup geser ke atas atau klik untuk membuka daftar produk.

Beberapa pengamatan dan kesimpulan yang kami buat selama pengujian. Siapa yang tahu bahwa ada orang - orang kidal dan orang-orang di dunia yang terbiasa memegang telepon di tangan kiri mereka. Dan mereka memiliki karakteristik penggunaannya sendiri. Jika orang biasa menyadap telepon, maka lefthander tidak memotong untuk menekan tombol menu burger. Kami mencatat bahwa orang kidal hanya menggunakan perangkat secara berbeda, dan kami akan terus menguji dan mencari tahu apakah kami dapat meningkatkan pengalaman untuk mereka. Masih ada orang dengan penglihatan yang buruk.

Semua orang tahu tentang itu, dan semua orang lupa tentang itu (maksud saya desainer). Bagaimana saya bisa membantu orang dengan penglihatan rendah? Pertama, Anda dapat menambah objek dalam desain. Kedua, Anda dapat meningkatkan kontras dalam desain. Dan ada hal lain yang kurang jelas: Anda dapat memisahkan informasi, meningkatkan jarak antar blok, yang juga akan membantu orang membaca antarmuka dengan lebih baik.

Menurut perkiraan paling konservatif yang dapat ditemukan di Wikipedia, kami memiliki 10% orang kidal, dan 13% orang dengan penglihatan rendah. Menurut orang yang tidak sopan - orang kidal sekitar 15%, dan orang dengan penglihatan rendah - 30%.

Dan beberapa gadis memiliki kuku panjang.Gadis-gadis ini juga menggunakan telepon secara berbeda. Sulit bagi mereka untuk menekan sesuatu di sudut kanan bawah, karena alih-alih menekan dengan ujung jari mereka beristirahat dengan kuku, dan karena itu mereka juga harus entah bagaimana mencegatnya. Tidak ada statistik resmi di sini, tetapi saya dapat mengasumsikan bahwa dari waktu ke waktu hingga 50% populasi orang dewasa di planet ini mungkin berada dalam situasi ini.

Selain tes Usability yang disorot di atas, ada banyak cara berbeda untuk menguji UX. Diantara mereka:

Eyingracking
Tes A / B
Jajak pendapat online
Wawancara mendalam

Pada bidang koordinat pertama ada lingkaran dengan metode pengujian yang disebutkan di atas

Semakin lama kita menghabiskan pengujian, semakin jelas kita memahami bahwa pengujian UX sangat dekat dengan ilmu pengetahuan seperti psikologi kognitif. Dan terutama untuk konsep seperti "distorsi kognitif".

Bagi mereka yang ingin menggali ini, saya menyarankan buku Daniel Caniman "Berpikir, Cepat dan Lambat" (Berpikir perlahan, putuskan dengan cepat). Dia tidak akan memberi tahu Anda apa-apa tentang tes, tetapi itu akan memberikan landasan yang baik untuk refleksi, menunjukkan bagaimana orang yang sama dapat menjawab pertanyaan yang berbeda dengan cara yang sama.

Apakah artikel ini membantu Anda lebih dekat untuk mulai menguji antarmuka sendiri? Apa yang ternyata berguna (jika sesuatu masih ternyata), dan apa yang tidak pantas?

Terima kasih kepada semua orang yang membantu melakukan penelitian dan menyiapkan laporan.

Penelitian UX:
tim JTC - analisis bisnis, desain, penelitian UX
Denis Krasilnikov - desain
Anton Kazakov - penelitian UX
Ekaterina Kashkovskaya - penelitian UX
Dmitry Dobrodeyev - penelitian UX
Irina Ponomareva - pembuatan film dan pengeditan

Persiapan laporan:
tim JTC - pembuatan laporan
Maxim Blokhin - desain oleh
Irina Ponomareva - pembuatan film dan pengeditan
Nadezhda Molodtsova - pembuatan film
Tatyana Kitaeva - editing

UX-research of RBS: pengalaman, kesalahan, dan penemuan kami