Riset Pengguna yang Menggerakkan Roadmap, Bukan Sekadar Mengonfirmasi Dugaan

PM sudah memutuskan. Dokumen roadmap sudah tiga sprint ke depan, tiket Jira sudah dibuat, dan engineering manager punya estimasi kasar. Kemudian organisasi desain berkata "sebaiknya kita bicara dengan pengguna dulu," dan proyek riset pun dijadwalkan.

Lima panggilan. Lima pelanggan yang dipilih CSM karena mereka "terlibat dan senang berdiskusi." Dokumen Notion dengan enam belas kutipan, empat di antaranya sedikit mendukung, tidak satu pun mengejutkan. PM membaca ringkasannya, berkata "ini mengonfirmasi apa yang kami pikirkan," dan mengirimkan fitur enam bulan kemudian. Adopsi terhenti di 11%. Retro pasca-peluncuran menyebutnya "masalah pesan."

Bukan masalah pesan. Itu masalah riset yang berlagak sebagai riset pengguna. Studi itu tidak gagal karena metodologinya salah. Ia gagal karena tidak ada yang mau membiarkannya mengubah keputusan. Itu bukan riset. Itu seremoni.

Jika Anda sudah berada dalam lingkaran ini dan sudah lelah, ini adalah playbook-nya. Ini mencakup kapan menggunakan jenis riset mana, cara menentukan ukuran studi dengan benar, cara menulis temuan yang bertahan dari PM yang skeptis, dan cara keluar dari jebakan "pengguna bilang mereka mau X" yang diam-diam merusak roadmap SMB demi siapa pun yang paling keras bersuara di QBR terakhir.

Riset Generatif vs Evaluatif: Pilih Alat yang Tepat Lebih Dulu

Cara tercepat untuk menyia-nyiakan anggaran riset adalah memilih kategori yang salah. Riset generatif menjawab "masalah apa yang kita pecahkan?" Riset evaluatif menjawab "apakah hal yang kita bangun memecahkannya?" Keduanya terlihat serupa dari luar (keduanya melibatkan pengguna, keduanya menghasilkan kutipan), tapi menjawab pertanyaan dalam arah berlawanan dan membutuhkan ukuran sampel, rekrutmen, dan dukungan pemangku kepentingan yang berbeda.

Sebagian besar tim B2B SaaS langsung menggunakan evaluatif ketika pertanyaan sebenarnya adalah generatif. Seseorang berkata "kita perlu menguji dashboard baru," dan pengujian kegunaan dijadwalkan sebelum ada yang bertanya apakah dashboard itu hal yang tepat untuk dibangun sama sekali. Pada saat uji dilakukan, jawaban yang bisa diberikannya sempit: apakah pengguna menemukan tombolnya. Pertanyaan yang penting (apakah dashboard ini seharusnya ada?) kini tidak lagi bisa ditanyakan karena prototipe sudah dibuat.

Gunakan tabel ini sebagai pemaksa. Sebelum Anda membuat spesifikasi studi, tulis keputusan yang akan segera dibuat tim. Jika keputusannya adalah "haruskah kita membangun ini?", Anda butuh generatif. Jika itu "haruskah kita mengirimkan versi yang kita bangun?", Anda butuh evaluatif. Jika itu "haruskah kita mengiterasi versi yang sudah dikirimkan?", Anda butuh berkelanjutan. Sebagian besar permintaan "kita butuh riset pengguna" sebenarnya adalah salah satu dari tiga ini, dan pemintanya biasanya tidak tahu yang mana.

Uji Kegunaan 5 Pengguna: Aturan Nielsen yang Sebenarnya, Bukan Mitos-nya

Makalah Jakob Nielsen tahun 1993 menemukan bahwa 5 pengguna sudah cukup untuk menemukan sekitar 85% masalah kegunaan dalam sebuah studi. Angka itu dipadatkan menjadi "selalu uji dengan 5" dan telah dikutip oleh orang-orang yang belum membaca makalahnya selama tiga puluh tahun. Aturan 5 pengguna berlaku dalam kondisi tertentu, dan kondisi tersebut lebih sempit dari yang diasumsikan kebanyakan tim produk.

Aturan ini berlaku ketika Anda memiliki satu segmen pengguna, melakukan satu tugas, pada satu antarmuka. Pengguna baru yang mendaftar. Admin yang mengonfigurasi satu pengaturan. Pengguna akhir yang mengisi satu laporan pengeluaran. Dalam cakupan itu, matematikanya berlaku: pada pengguna ke-5 Anda sudah melihat sebagian besar masalah, dan pada pengguna ke-8 Anda melihat pengulangan.

Aturan ini rusak ketika salah satu kondisi itu rusak:

• Beberapa persona. Jika produk B2B Anda memiliki admin, pengguna akhir, dan IT, Anda butuh 5 dari masing-masing. Itu 15 sesi, bukan 5. Admin bingung dengan hal-hal yang tidak pernah dilihat pengguna akhir.
• Masalah konseptual, bukan interaksional. Aturan 5 pengguna menangkap "saya tidak bisa menemukan tombolnya." Ia melewatkan "saya tidak mengerti mengapa fitur ini ada." Kesalahpahaman konseptual muncul pada tingkat rendah per pengguna tapi lebih penting; Anda butuh 12-15 untuk mendeteksinya dengan andal.
• Alur bercabang. Alur pendaftaran linear bisa diuji dengan 5. Alur kerja dengan 6 cabang kondisional membutuhkan cakupan sampel pada setiap cabang. Anda bisa menjalankan 5 pengguna dan melihat 4 dari mereka tidak pernah menekan cabang tempat bug berada.
• Perbandingan lintas segmen. Jika pertanyaannya adalah "apakah ini berhasil untuk SMB dan enterprise?", Anda butuh studi yang ukurannya sesuai untuk perbandingan tingkat segmen, yaitu minimal 8-12 per segmen.

Ketika pemangku kepentingan berkata "ayo cukup 5 saja," tanyakan persona mana, tugas mana, dan keputusan apa yang akan diinformasikan hasilnya. Jika keputusannya adalah "kirimkan atau tidak di seluruh basis pengguna kami," 5 tidak cukup. Jika keputusannya adalah "apakah alur pendaftaran ini rusak untuk pengguna SMB baru secara khusus," 5 mungkin sudah cukup.

Pengujian Unmoderated: Maze, UserTesting, Lyssna, dan Apa yang Mereka Sembunyikan

Platform unmoderated telah mengubah kecepatan designer dalam menjalankan studi evaluatif. Maze, UserTesting, dan Lyssna memungkinkan Anda mengirimkan prototipe ke 50 penguji dan mendapatkan hasil pada hari Jumat. Kecepatannya nyata. Begitu pula konsekuensinya.

Pengujian unmoderated unggul dalam tiga hal: kecepatan (turnaround 24-72 jam), jangkauan (Anda bisa merekrut panel yang tidak pernah Anda dapatkan dalam panggilan moderasi), dan perbandingan kuantitatif (A/B test dua desain dalam skala besar). Untuk tugas yang jelas dan konteks rendah yang ditujukan kepada audiens luas, ini sulit dikalahkan.

Ia kalah dalam tiga hal, dan produk B2B menghadapi ketiganya:

1. Alur kerja yang kompleks. Studi moderasi memungkinkan Anda mengamati pengguna berpikir keras, bertanya "mengapa Anda mengklik itu?", dan menyelidiki ketika mereka terhenti. Unmoderated, Anda mendapatkan video seseorang mengklik hal yang salah dalam keheningan dan melanjutkan. Anda tahu bahwa mereka gagal. Anda tidak tahu mengapa.
2. Antarmuka yang penuh jargon. Produk B2B penuh dengan istilah yang baru dipahami pengguna dalam konteksnya. Penguji unmoderated dari panel akan menebak, gagal, dan menilai uji sebagai "mudah" karena mereka tidak tahu apa yang tidak mereka ketahui. Uji menghasilkan data yang terlihat bersih dan celah pemahaman yang tidak terlihat.
3. Pertanyaan "mengapa". Apa pun yang membutuhkan pemahaman tentang niat, motivasi, atau pertimbangan trade-off membutuhkan moderator. Alat unmoderated telah meningkatkan prompt tindak lanjut, tapi pertanyaan tindak lanjut yang direkam mendapat jawaban yang sudah disiapkan. Moderator langsung mendapat jawaban yang sebenarnya.

Tingkat penyelesaian yang realistis mendukung ini. Untuk tugas yang ditujukan kepada konsumen, uji B2C unmoderated berjalan 80-95% penyelesaian. Untuk alur kerja B2B SaaS, harapkan 60-75%. Kesenjangan itu penting saat menentukan ukuran: studi yang membutuhkan n=20 sesi valid pada alur kerja B2B membutuhkan 28-32 mulai untuk mencapainya. Rencanakan untuk dropout.

Jebakan yang sering dialami tim: mereka memilih unmoderated karena cepat, lalu membuat keputusan yang membutuhkan kedalaman moderasi. Maze memberi tahu Anda tingkat klik-tayang. Ia tidak memberi tahu Anda bahwa 4 dari 12 pengguna SMB tidak tahu apa arti "tenant" di panel pengaturan IT Anda dan hanya menebak jawaban yang benar.

Jebakan "Riset Menunjukkan Pengguna Mau X"

Di sinilah sebagian besar riset B2B mati. Bias seleksi, bias kekinian, dan bias konfirmasi bertumpuk, dan studi dengan delapan peserta menjadi roadmap yang dibangun untuk audiens yang tidak Anda miliki.

Bias seleksi berasal dari siapa yang menjawab panggilan. Customer success memilih pelanggan yang terlibat karena mereka menjawab email. Pelanggan yang terlibat lebih cenderung enterprise, lebih cenderung admin, dan lebih cenderung menginginkan fitur yang membuat alur kerja mereka yang sudah ada lebih kuat. Sampel 8 dari mereka dan Anda akan mendengar pesan yang seragam: lebih banyak izin, lebih banyak peran, lebih banyak kontrol enterprise-grade. Jika bisnis Anda adalah 70% SMB berdasarkan ARR, Anda baru saja menjalankan studi yang ditujukan untuk 30% yang sebenarnya tidak butuh bantuan.

Bias kekinian berasal dari pelanggan terakhir yang bersuara keras. QBR terjadi minggu lalu, VP mendengar dari akun senilai $400K, dan "pengguna mau SSO" masuk ke dokumen perencanaan sebagai kutipan tanpa n yang menyertainya. Pada saat riset direkrut, pertanyaan yang diajukan bukan "apakah pengguna mau SSO?" melainkan "seberapa buruk pengguna menginginkan SSO?", dan rekrutmen menyaring pengguna yang akan merasa SSO berharga.

Bias konfirmasi ada dalam pertanyaan itu sendiri. "Apakah akan berguna jika Anda bisa mengekspor laporan dalam jumlah besar?" mendapat jawaban ya dari hampir semua orang. "Bagaimana Anda saat ini menangani pelaporan?" memberi tahu Anda apakah ekspor massal adalah hambatan nyata atau sekadar fitur menarik yang terkubur di bawah sepuluh hal yang benar-benar mereka perjuangkan setiap hari.

Contoh nyata, dianonimkan: studi terhadap 8 admin dari 3 akun enterprise menghasilkan headline "pengguna mau SSO." Roadmap bergeser ke satu kuartal pekerjaan SSO dan SCIM. Enam bulan kemudian, churn SMB naik karena tim yang mengelola activation ditarik ke proyek SSO. Delapan admin itu senang. 1.400 akun SMB yang tidak pernah melewati minggu ke-2 activation tidak pernah diwawancarai. Studi itu tidak salah tentang 8 admin. Ia salah karena diperlakukan sebagai studi tentang "pengguna."

Pertahanannya bersifat prosedural. Sebelum merekrut, tulis: studi ini tentang segmen mana, berapa proporsi pendapatan yang diwakili segmen itu, dan keputusan apa yang secara sah bisa diinformasikan studi ini? Jika jawaban atas pertanyaan ketiga adalah "hanya keputusan tentang segmen ini," taruh itu di slide pembuka readout. Pemangku kepentingan akan melakukan generalisasi berlebihan kecuali Anda memperjelas cakupannya.

Cara Menulis Temuan yang Mengubah Keputusan

Sebagian besar temuan riset mati pada slide tempat mereka ditulis. "Pengguna kebingungan dengan tombol ekspor" kalah dalam setiap argumen karena tidak ada n, tidak ada segmen, tidak ada spesifisitas, dan tidak ada rekomendasi. Bisa benar tapi tetap diabaikan.

Temuan yang bertahan dari PM yang skeptis memiliki lima bagian:

1. Observasi: apa yang terjadi, secara perilaku
2. Bukti: n, segmen, tugas, jenis studi
3. Inferensi: apa yang kemungkinan besar ini berarti
4. Rekomendasi: apa yang harus dilakukan
5. Tingkat kepercayaan: seberapa yakin Anda

Bandingkan:

Buruk: Pengguna kebingungan dengan tombol ekspor.

versus:

Baik: 6 dari 8 admin (n=8, tier enterprise, pengujian kegunaan moderasi, tugas ekspor laporan mingguan) meninggalkan alur ekspor pada langkah pemilihan format. Tiga mengucapkan secara keras bahwa mereka tidak tahu apa yang dimaksud dengan "delimited"; dua mengklik format yang salah dan tidak menyadarinya. Inferensi: pemilih format adalah hambatan pemahaman, bukan hambatan penemuan. Rekomendasi: default ke CSV dengan disclosure "lebih banyak format," kirimkan di belakang flag dan ukur delta abandonment. Kepercayaan: sedang. Sampel kecil dan hanya enterprise; tindak lanjut unmoderated selama 2 minggu di SMB akan mengonfirmasi.

Yang kedua menang karena memberi tahu PM persis apa yang diketahui, apa yang disimpulkan, dan tindakan apa yang mengikutinya. PM yang skeptis bisa menyerang salah satu dari lima bagian, tapi mereka harus menyerang bagian yang spesifik. Mereka tidak bisa begitu saja berkata "sampel kecil" dan pergi, karena rekomendasi sudah memperhitungkannya dengan rencana tindak lanjut.

Pola kedua yang membantu: tuliskan temuan dengan keputusan yang mereka pengaruhi, bukan metodologinya. "Kita perlu mengubah default ekspor" mengena. "Kami menjalankan studi moderasi dengan 8 admin" membuat audiens tertidur sebelum rekomendasi tiba.

Mempresentasikan Riset kepada PM yang Skeptis

Deck riset 23 slide yang diberikan kepada PM saat standup tidak akan mengubah roadmap. Ia akan diakui, disimpan, dan diabaikan. PM adalah pengambil keputusan di bawah tekanan waktu. Riset harus bertemu mereka di mana mereka berada.

Lima hal yang benar-benar berhasil:

Mulai dengan keputusannya. Buka dengan "studi ini menginformasikan apakah kita mengirimkan alur ekspor baru apa adanya, mengirimkan dengan satu perubahan, atau membangun ulang." Kemudian metodologi, kemudian temuan. PM sekarang membaca untuk membuat keputusan, bukan untuk mengevaluasi riset.

Antisipasi penolakan lebih dahulu. Sebelum presentasi, tulis tiga keberatan yang Anda perkirakan ("sampel kecil," "itu bukan ICP kita," "kita sudah memutuskan"). Tangani masing-masing dalam deck sebelum diangkat. Mengatakan "n=8 kecil untuk klaim lintas segmen, itulah mengapa studi ini hanya berbicara tentang admin enterprise yang melakukan tugas ekspor" melumpuhkan serangan sampel-kecil sebelum mendarat.

Bawa klip mentahnya, bukan ringkasannya. Video 45 detik seorang admin menatap dropdown format dan berkata "saya tidak tahu apa artinya satu pun dari ini" bernilai lima belas slide kutipan. PM lebih mempercayai mata mereka sendiri daripada sintesis Anda. Alat seperti Dovetail dan UserTesting membuat pengambilan klip menjadi cepat.

Kaitkan dengan metrik yang sudah dipedulikan PM. Jika PM memiliki activation, bingkai temuan seputar dampak activation. Jika mereka memiliki retention, bingkai seputar retention. "Gesekan ekspor ini menyentuh activation minggu ke-2 untuk admin baru" mengalahkan "gesekan ekspor ini adalah masalah UX" setiap saat.

Sebutkan biaya mengabaikannya. "Jika kita mengirimkan apa adanya, kami memperkirakan sekitar 30-40% admin baru akan meninggalkan tugas ekspor di bulan pertama, berdasarkan tingkat abandonment sesi moderasi" memberi PM sesuatu untuk ditimbang terhadap tanggal pengiriman.

Aturan praktis: jika temuan riset tidak bisa muat dalam satu slide dengan keputusan, bukti, rekomendasi, dan satu kutipan, itu belum menjadi temuan. Itu masih entri buku catatan. Terus kerjakan sebelum dibawa ke ruangan.

Apa yang Harus Dilakukan Minggu Ini

Pilih satu keputusan roadmap yang akan datang. Tulis apa yang akan diputuskan, siapa yang memutuskan, dan apa yang harus benar agar keputusan berubah. Kemudian tanyakan: apakah tim memiliki bukti untuk hal yang harus benar itu? Jika tidak, itulah studinya. Jika ya, riset sudah selesai dan langkah selanjutnya adalah memunculkannya.

Riset yang menggerakkan roadmap adalah riset yang ditujukan pada keputusan spesifik, berukuran untuk klaim yang perlu didukung, dan disajikan dalam bentuk yang bisa ditindaklanjuti oleh PM yang sibuk. Selebihnya adalah workshop. Workshop itu baik-baik saja. Hanya jangan samakan dengan studi.

Pelajari Lebih Lanjut

• Kritik Desain yang Meningkatkan Pekerjaan, Bukan Suasana Hati Designer
• Bekerja dengan PM yang Menganggap Desain Sebagai Dekorasi
• Kecepatan Pengiriman untuk Designer
• Template Job Description Product Designer