Metrik UX: Kebolehgunaan, Kejayaan Tugasan, Masa untuk Siap, NPS

Kebanyakan kerja UX tidak diukur. "Pengguna menyukai aliran baru" mendapat anggukan dan kemudian anda disingkirkan dari bilik. PM masuk dengan carta churn. Anda masuk dengan fail Figma. Teka siapa yang menang hujah pelan tindakan.

Jika anda pernah duduk dalam ulasan perniagaan suku tahunan dan menyaksikan skop anda mengecil sementara pengurus kejuruteraan mempertahankan pemfaktoran semula dengan nombor daya pengeluaran, anda sudah tahu maksud ini. Reka bentuk memerlukan nombor sendiri. Bukan papan pemuka yang tidak bermakna. Bukan "penglibatan naik 4%." Satu tindanan yang pendek dan boleh dipertahankan yang memberitahu Ketua Produk, dalam masa kurang daripada enam puluh saat, sama ada reka bentuk itu berfungsi.

Inilah tindanan yang saya gunakan, diagnostik yang mengesan mod kegagalan yang tidak ada yang bercakap tentangnya, dan slaid QBR yang dikemukakan tanpa suntingan.

Mengapa Ini Penting Sekarang

Design Lead diminta mempertahankan bilangan pekerja berbanding alat AI. "Kami menghantar 14 token reka bentuk" bukan pertahanan. "Kadar kejayaan tugasan bergerak dari 71% ke 88% pada aliran pendaftaran, dan tiket seseribu pengguna jatuh 22%" memang pertahanan.

Saya tidak berlebih-lebihan. Dalam dua kitaran prestasi terakhir yang saya perhatikan, setiap pasukan UX yang kehilangan bilangan pekerja mempunyai satu persamaan: mereka tidak dapat menghasilkan nombor yang penting kepada perniagaan. Pasukan yang berkembang mempunyai perbendaharaan kata bersama dengan produk dan garis asas yang mereka kemaskini setiap suku. Itulah keseluruhan perbezaannya.

Nombor tidak menggantikan kemahiran. Ia melindungi kemahiran.

Lima Metrik

Pilih lima ini. Jangan tambah yang keenam sehingga anda telah melaporkan lima ini selama dua suku berturut-turut. Lebih banyak metrik menjadikan slaid anda lebih lemah, bukan lebih kuat.

1. Kadar Kejayaan Tugasan

Takrifkan tugasan dengan sempit. Bukan "gunakan papan pemuka." Katakan "cipta projek baru, jemput seorang ahli pasukan, dan tugaskan tugasan pertama." Kemudian kira berapa ramai pengguna yang selesai tanpa bantuan, tanpa berundur, tanpa meninggalkan.

Sasaran: melebihi 85% untuk mana-mana aliran teras yang mendorong hasil atau pengekalan. Di bawah 70% pada aliran yang anda hantar kepada pelanggan berbayar adalah pepijat, bukan keutamaan reka bentuk.

Cara untuk menginstrumentkan: rakaman sesi (FullStory, LogRocket, Hotjar) untuk aliran trafik tinggi, ujian terselia dengan n=12 atau lebih untuk apa-apa yang baharu. Dua belas adalah tahap minimum di mana anda mula melihat masalah yang sama dua kali. Di bawah dua belas dan anda hanya meneka.

Kesilapan yang paling kerap saya lihat: pasukan mengukur kejayaan tugasan pada laluan gembira sahaja. Tambahkan dua kes tepi paling biasa (keadaan kosong dan pemulihan ralat) dan ukur semula. Nombor itu jatuh, dan kejatuhan itu adalah tempat kerja sebenar anda berada.

2. Masa untuk Siap

Gunakan median, bukan min. Seorang pelanggan perusahaan dengan aliran kerja khusus akan menarik min kepada nilai yang tidak bermakna. Median memberitahu anda apa yang pengguna biasa sebenarnya alami.

Bahagikan mengikut pengguna baharu berbanding pengguna yang kembali. Pengguna baharu pada aliran melebihi 90 saat untuk tindakan teras adalah tanda amaran. Pengguna yang kembali melebihi 30 saat untuk sesuatu yang mereka lakukan setiap hari juga merupakan tanda amaran. Itu adalah memori otot yang anda tidak biarkan mereka gunakan.

Contoh sebenar: reka bentuk semula halaman pengebilan menggerakkan median masa untuk siap dari 47 saat kepada 31 saat untuk pengguna yang kembali. Itu adalah pengurangan 34%. PM tidak peduli tentang reka bentuk semula. Mereka peduli bahawa tiket sokongan tentang "di mana butang muat turun invois" jatuh kepada sifar dalam suku yang sama. Hasil yang sama, bahasa berbeza. Gunakan kedua-duanya.

Apa yang masa untuk siap tidak memberitahu anda: sama ada pengguna menikmatinya, sama ada mereka kembali, atau sama ada aliran itu pun aliran yang betul. Ia adalah alat pengukur kelajuan, bukan semakan destinasi.

3. Kadar Ralat

Tiga perkara untuk dijejaki:

• Ralat borang: medan yang diserahkan salah, pengesahan dicetuskan, percubaan semula sebelum berjaya
• Klik jalan buntu: ketukan pada perkara yang tidak interaktif (label yang kelihatan seperti butang, ikon tanpa tindakan)
• Klik berang: tiga atau lebih klik pada elemen yang sama dalam masa kurang daripada dua saat

Setiap sesi adalah unit yang betul. "Ralat seseorang pengguna seminggu" menyembunyikan kebakaran pada peringkat aliran.

Peraturan kritikal: tetapkan garis asas sebelum reka bentuk semula. Jika anda menghantar reka bentuk semula dan melaporkan "kadar ralat adalah 1.2 sesesi," nombor itu tidak bermakna tanpa garis asas pra-reka bentuk semula. Saya pernah melihat pereka menghantar penambahbaikan 30% tetapi tidak dapat menuntutnya kerana mereka tidak pernah mengukur titik permulaan. Tetapkan garis asas pada minggu pertama. Sentiasa.

Klik berang adalah metrik yang tidak dihargai secukupnya. Ia adalah perkara paling hampir yang UX ada kepada pelanggan yang menjerit pada skrin. Mana-mana aliran dengan klik berang melebihi 0.5 sesesi sedang menyampaikan sesuatu yang khusus: pengguna menyangka sesuatu patut berfungsi, dan ia tidak berfungsi.

4. Skor SUS

Skala Kebolehgunaan Sistem. Sepuluh soalan, dinilai 0-100, dijalankan setiap suku.

Purata merentas semua perisian: 68. Di bawah 50 adalah kecemasan. Pengguna anda berjuang secara aktif. Melebihi 80 adalah baik secara tulen. Melebihi 85 adalah jarang dan mungkin bermakna sampel yang kecil dan terpilih sendiri.

Jangan jalankan SUS pada keseluruhan produk. Jalankan pada tiga aliran yang mendorong hasil atau pengekalan. Pilihnya bersama PM anda. Jika tidak, anda akan mengambil purata onboarding yang hebat dengan panel pentadbir yang sederhana dan melaporkan 71 yang tidak bermakna.

Sepuluh soalan (diringkaskan; gunakan kata-kata standard apabila anda menghantarnya):

1. Saya rasa saya akan menggunakan sistem ini dengan kerap.
2. Saya mendapati sistem ini terlalu kompleks tanpa sebab.
3. Saya rasa sistem ini mudah digunakan.
4. Saya perlukan sokongan seseorang yang teknikal untuk menggunakan sistem ini.
5. Pelbagai fungsi dalam sistem ini disepadukan dengan baik.
6. Terdapat terlalu banyak ketidakkonsistenan dalam sistem ini.
7. Saya membayangkan kebanyakan orang akan belajar menggunakan sistem ini dengan sangat cepat.
8. Saya mendapati sistem ini sangat menyusahkan untuk digunakan.
9. Saya berasa sangat yakin menggunakan sistem ini.
10. Saya perlu mempelajari banyak perkara sebelum saya boleh menggunakan sistem ini.

Skala lima mata, phrasing positif dan negatif berselang-seli. Kiraan matematiknya telah didokumentasikan dengan baik; jangan cipta semula.

Jalankan pada minggu yang sama setiap suku, pada aliran yang sama, dengan sekurang-kurangnya n=20 responden setiap aliran. Trend lebih penting daripada nombor mutlak.

5. Delta NPS Pasca-Pelancaran

Net Promoter Score adalah instrumen yang kasar. Secara tersendiri, ia adalah metrik yang tidak bermakna. Tersegmen, ia adalah salah satu isyarat terkuat yang boleh anda tunjukkan kepada Ketua Produk.

Langkah ini: dalam 30 hari selepas reka bentuk semula dihantar, bahagikan respons NPS mengikut pengguna yang sebenarnya melalui aliran yang direka bentuk semula berbanding pengguna yang tidak. Bandingkan dua kohort. Jika kohort aliran-direka bentuk-semula mendapat skor 8 mata NPS lebih tinggi, anda mempunyai tuntutan yang boleh dipertahankan. Jika mereka mendapat skor yang sama atau lebih rendah, anda mempunyai masalah yang patut disiasat.

Ini adalah satu-satunya nombor NPS yang akan saya letakkan pada slaid UX. NPS keseluruhan syarikat milik CEO. NPS pasca-pelancaran tersegmen kohort milik anda.

Awasi perangkap ini: jangan bandingkan dengan NPS keseluruhan syarikat suku sebelumnya. Anda mengukur aliran, bukan syarikat. Bandingkan kohort dengan kohort, tetingkap yang sama.

Diagnostik "Kejayaan Tugasan Tinggi tetapi Churn Tinggi"

Ini adalah yang tiada siapa amaran anda tentangnya.

Aliran berfungsi. SUS pada 76. Kadar kejayaan tugasan 91%. Masa untuk siap menurun. Anda hantar. Anda sambut. Tiga bulan kemudian, churn tidak bergerak. Kadangkala ia menjadi lebih buruk.

Apa yang berlaku?

Biasanya salah satu daripada tiga perkara:

Anda mengoptimumkan Jobs-to-be-Done yang salah. Pengguna menyelesaikan tugasan yang anda ukur, tetapi tugasan itu bukan apa yang mereka sebenarnya ingin capai. Contoh klasik: aliran import yang direka bentuk semula dengan kejayaan 94%, tetapi pengguna mengimport CSV kerana mereka tidak dapat menyediakan API. Kerja sebenar adalah "masukkan data saya dengan cepat." Anda mengoptimumkan penyelesaian sementara.

Langkah seterusnya rosak. Mereka selesai onboarding. Kemudian mereka mencapai keadaan kosong dan melantun. Atau mereka mencapai halangan penetapan harga yang tidak mereka jangkakan. Atau mereka diserahkan kepada wakil jualan yang mengambil masa empat hari untuk bertindak balas. Aliran yang anda ukur berjaya; perjalanan gagal.

Anda mengoptimumkan untuk pengguna pertama kali sambil memecahkan pengguna yang kembali. Kadar kejayaan tugasan pengguna baharu naik 22%. Kadar kejayaan tugasan pengguna yang kembali turun 8%. Pengguna yang kembali adalah yang membayar. Mereka pergi.

Cara untuk mengesannya sebelum QBR:

1. Bahagikan pengguna yang churn dari 30 hari lepas kepada kohort.
2. Tarik rakaman sesi untuk kohort itu, 7 hari sebelum churn.
3. Cari momen keraguan: jeda panjang pada skrin, kembali ke langkah sebelumnya, membuka artikel bantuan dalam tab baharu.
4. Kenal pasti skrin yang mereka ragu-ragu, walaupun metrik sesi menunjukkan mereka "berjaya."
5. Skrin itu adalah masalah sebenar anda. Bukan yang anda reka bentuk semula.

Lima rakaman pengguna yang churn akan mengajar anda lebih daripada lima puluh ujian laluan gembira. Pelaburannya adalah dua jam. Outputnya adalah senarai tiga hingga lima pembaikan yang menggerakkan pengekalan, bukan metrik yang tidak bermakna. Lakukan ini setiap bulan.

Slaid QBR

Satu slaid. Empat nombor. Satu catatan diagnostik. Jangan jadikannya cantik. Jadikannya mudah diimbas.

Susun atur (kiri ke kanan, atas ke bawah):

Di bawah jadual, satu baris:

Diagnostik: Penyiapan onboarding naik 17% tetapi pengekalan minggu ke-2 mendatar. Rakaman kohort menunjuk kepada keadaan papan pemuka kosong. Pembaikan diskopkan untuk sprint seterusnya.

Itu sahaja keseluruhan slaid. Tiada tangkapan skrin reka bentuk semula. Tiada bingkai Figma sebelum/selepas. Tiada petikan "pengguna teruja" yang ditarik keluar. Ketua Produk tidak akan membaca semua itu. Mereka akan membaca jadual, delta, dan diagnostik.

Jika mereka mahukan Figma, mereka akan meminta. Hampir tidak pernah mereka berbuat demikian.

Perangkap Metrik yang Tidak Bermakna

Perkara yang kelihatan seperti metrik UX tetapi bukan:

Minit penglibatan sahaja. Sesi yang lebih lama boleh bermakna kekeliruan. Pengguna yang menghabiskan 12 minit mencari butang eksport bukan terlibat. Mereka tersekat. Gabungkan dengan kejayaan tugasan atau jangan laporkan langsung.

Token reka bentuk yang dihantar. Ini adalah output, bukan hasil. Jurutera tidak melaporkan "baris kod yang ditulis" atas sebab tertentu. Jangan laporkan ini juga.

NPS tanpa segmentasi. NPS agregat milik CEO. Jika anda meletakkan NPS tidak tersegmen pada slaid UX, anda sama ada mengambil kredit untuk perkara yang tidak anda lakukan atau dipersalahkan untuk perkara yang tidak anda pecahkan.

CSAT selepas tiket sokongan. Mengukur ejen sokongan, bukan produk. Berguna untuk kepimpinan sokongan. Tidak berguna untuk anda.

Kadar lantunan sebagai metrik UX. Kadar lantunan adalah metrik pemasaran pada halaman pendaratan. Pada permukaan produk ia hampir sentiasa mengelirukan.

Bilangan ujian kebolehgunaan yang dijalankan. Aktiviti, bukan hasil. Nombor yang betul adalah "ujian yang dijalankan yang mengubah keputusan reka bentuk" dan itu adalah nombor yang sukar untuk dilaporkan, itulah sebab tiada siapa berbuat demikian. Cuba juga.

Senarai Semak Instrumentasi

Sebelum anda membuat komitmen untuk melaporkan mana-mana ini, pastikan anda sebenarnya boleh mengukurnya. Lalui senarai ini bersama PM dan seorang jurutera anda:

• Alat rakaman sesi digunakan dan PII diredaksi (FullStory, LogRocket, Hotjar, Heap)
• Penjejakan peristiwa pada semua pasangan mula/siap aliran teras (mula onboarding, siap onboarding, dan sebagainya)
• Definisi corong didokumentasikan dan dikongsi dengan analitik produk
• Infrastruktur tinjauan SUS (Typeform, modal dalam aplikasi, atau e-mel suku tahunan) dengan sekurang-kurangnya n=20 setiap aliran
• Tinjauan NPS tersegmen mengikut pendedahan ciri/aliran, bukan hanya tarikh penghantaran
• Pengukuran garis asas diambil sebelum mana-mana reka bentuk semula dihantar
• Papan pemuka bersama yang boleh dibuka PM tanpa meminta anda

Jika anda tidak dapat menanda semua lapan, baiki jurang sebelum anda membuat komitmen kepada metrik. Melaporkan nombor yang anda tidak boleh percayai adalah lebih buruk daripada tidak melaporkan langsung.

Mengukur Kejayaan Anda Sendiri

Anda akan tahu ini berfungsi apabila:

• Anda boleh menjawab "adakah reka bentuk berfungsi?" dalam masa kurang daripada 60 saat dengan nombor, bukan kata sifat.
• Design Lead anda memajukan slaid QBR anda kepada Ketua Produk tanpa suntingan.
• PM berhenti meminta "maklum balas pengguna" dan mula meminta "nombor kejayaan tugasan terkini."
• Seorang jurutera meminta garis asas sebelum mereka memulakan pemfaktoran semula kerana mereka telah melihat formatnya.
• Anda mengesan kes kejayaan-tinggi-churn-tinggi sebelum QBR, bukan selepasnya.

Matlamatnya bukan untuk menjadi penganalisis data. Ia adalah untuk berhenti menjadi orang dalam bilik yang tidak mempunyai nombor.

Lima metrik. Satu diagnostik. Satu slaid. Jalankan selama dua suku dan perbualan tentang UX dalam syarikat anda akan berubah secara senyap.

Ketahui Lebih Lanjut

• Kritik Reka Bentuk yang Tidak Berlarutan
• Ujian Kebolehgunaan dengan Belanjawan Terhad
• Bekerja dengan PM yang Tidak Faham Reka Bentuk
• Perihalan Jawatan Product Designer