UX Metrics: Kegunaan, Keberhasilan Tugas, Waktu Penyelesaian, NPS

Sebagian besar pekerjaan UX tidak diukur. "Pengguna menyukai alur baru" membuatmu diangguk-angguk keluar dari ruangan. PM masuk dengan grafik churn. Kamu masuk dengan file Figma. Tebak siapa yang memenangkan argumen roadmap.

Jika kamu pernah duduk dalam quarterly business review dan melihat scope-mu menyusut sementara engineering manager mempertahankan refactor dengan angka throughput, kamu sudah tahu ini tentang apa. Desain membutuhkan angkanya sendiri. Bukan dashboard kosmetik. Bukan "engagement naik 4%." Stack singkat yang bisa dipertahankan yang memberi tahu Head of Product, dalam waktu kurang dari enam puluh detik, apakah desain bekerja.

Ini adalah stack yang aku gunakan, diagnosis yang menangkap mode kegagalan yang tidak ada yang bicarakan, dan slide QBR yang diteruskan tanpa diedit.

Mengapa Ini Penting Sekarang

Design Lead sedang diminta mempertahankan headcount dari alat AI. "Kita mengirimkan 14 design token" bukan pembelaan. "Tingkat keberhasilan tugas bergerak dari 71% ke 88% pada alur pendaftaran, dan tiket per seribu pengguna turun 22%" adalah pembelaan.

Aku tidak berlebihan. Dalam dua siklus kinerja terakhir yang aku saksikan, setiap tim UX yang kehilangan headcount punya satu kesamaan: mereka tidak bisa menghasilkan angka yang penting bagi bisnis. Tim yang berkembang punya kosakata bersama dengan product dan baseline yang mereka perbarui setiap kuartal. Itulah seluruh perbedaannya.

Angka tidak menggantikan craft. Angka melindunginya.

Lima Metric

Pilih lima ini. Jangan tambahkan yang keenam sampai kamu sudah melaporkan kelima ini selama dua kuartal berturut-turut. Lebih banyak metric membuat slide-mu lebih lemah, bukan lebih kuat.

1. Tingkat Keberhasilan Tugas

Definisikan tugasnya secara sempit. Bukan "gunakan dashboard." Katakan "buat proyek baru, undang satu rekan tim, dan tetapkan tugas pertama." Lalu hitung berapa banyak pengguna yang menyelesaikan tanpa bantuan, tanpa mundur, tanpa meninggalkan.

Target: di atas 85% untuk alur inti mana pun yang mendorong pendapatan atau retensi. Di bawah 70% pada alur yang kamu kirimkan kepada pelanggan berbayar adalah bug, bukan preferensi desain.

Cara mengukur: session replay (FullStory, LogRocket, Hotjar) untuk alur bertraffic tinggi, tes termoderasi dengan n=12 atau lebih untuk apa pun yang baru. Dua belas adalah batas bawah di mana kamu mulai melihat masalah yang sama dua kali. Di bawah dua belas dan kamu hanya menebak.

Kesalahan yang paling sering aku lihat: tim mengukur keberhasilan tugas hanya pada jalur bahagia. Tambahkan dua kasus tepi yang paling umum (kondisi kosong dan pemulihan kesalahan) dan ukur ulang. Angkanya turun, dan penurunan itu adalah tempat pekerjaan nyatamu berada.

2. Waktu Penyelesaian

Gunakan median, bukan rata-rata. Satu pelanggan enterprise dengan alur kerja khusus akan menarik rata-rata ke angka yang tidak masuk akal. Median memberi tahu kamu apa yang benar-benar dialami pengguna tipikal.

Segmentasikan berdasarkan pengguna baru vs. pengguna lama. Pengguna baru pada alur dengan waktu lebih dari 90 detik untuk tindakan inti adalah tanda bahaya. Pengguna lama dengan lebih dari 30 detik untuk sesuatu yang mereka lakukan setiap hari juga tanda bahaya. Itu adalah memori otot yang tidak kamu biarkan mereka gunakan.

Contoh nyata: redesain halaman billing memindahkan median waktu penyelesaian dari 47 detik ke 31 detik untuk pengguna lama. Itu adalah penurunan 34%. PM tidak peduli dengan redesain itu. Mereka peduli bahwa tiket support tentang "di mana tombol unduh invoice" turun ke nol di kuartal yang sama. Hasil yang sama, bahasa yang berbeda. Gunakan keduanya.

Apa yang tidak diberitahu waktu penyelesaian: apakah pengguna menikmatinya, apakah mereka kembali, atau apakah alurnya bahkan merupakan alur yang tepat. Ini speedometer, bukan pemeriksaan tujuan.

3. Tingkat Kesalahan

Tiga hal yang perlu dilacak:

• Kesalahan formulir: field yang diisi salah, validasi terpicu, percobaan ulang sebelum berhasil
• Klik tanpa hasil: ketukan pada elemen yang tidak interaktif (label yang terlihat seperti tombol, ikon tanpa aksi)
• Rage-click: tiga klik atau lebih pada elemen yang sama dalam waktu kurang dari dua detik

Per sesi adalah unit yang tepat. "Kesalahan per pengguna per minggu" menyembunyikan kebakaran di level alur.

Aturan kritis: ukur baseline sebelum redesain. Jika kamu mengirimkan redesain dan melaporkan "tingkat kesalahan adalah 1,2 per sesi," angka itu tidak berarti tanpa baseline pra-redesain. Aku pernah melihat desainer mengirimkan peningkatan 30% dan tidak bisa mengklaimnya karena mereka tidak pernah mengukur titik awal. Tetapkan baseline di minggu pertama. Selalu.

Rage-click sangat diremehkan. Itu adalah pendekatan paling dekat yang UX miliki dengan pelanggan yang berteriak pada layar. Alur mana pun dengan rage-click di atas 0,5 per sesi mengomunikasikan sesuatu yang spesifik: pengguna pikir sesuatu seharusnya berfungsi, dan ternyata tidak.

4. Skor SUS

System Usability Scale. Sepuluh pertanyaan, skor 0-100, dijalankan setiap kuartal.

Rata-rata untuk semua perangkat lunak: 68. Di bawah 50 adalah keadaan darurat. Pengguna kamu benar-benar kesulitan. Di atas 80 adalah bagus. Di atas 85 adalah jarang dan mungkin berarti sampel yang kecil dan bias.

Jangan jalankan SUS pada seluruh produk. Jalankan pada tiga alur yang mendorong pendapatan atau retensi. Pilih bersama PM-mu. Kalau tidak, kamu akan merata-ratakan onboarding yang hebat dengan panel admin yang biasa-biasa saja dan melaporkan angka 71 yang tidak bermakna.

Sepuluh pertanyaan (diparafrase; gunakan kata-kata standar ketika kamu mengirimkannya):

1. Saya pikir saya akan sering menggunakan sistem ini.
2. Saya merasa sistem ini terlalu rumit.
3. Saya pikir sistem ini mudah digunakan.
4. Saya membutuhkan bantuan orang teknis untuk menggunakan sistem ini.
5. Berbagai fungsi dalam sistem ini terintegrasi dengan baik.
6. Ada terlalu banyak inkonsistensi dalam sistem ini.
7. Saya membayangkan kebanyakan orang akan belajar menggunakan sistem ini dengan cepat.
8. Saya merasa sistem ini sangat sulit digunakan.
9. Saya merasa sangat percaya diri menggunakan sistem ini.
10. Saya perlu belajar banyak hal sebelum bisa mulai menggunakan sistem ini.

Skala lima poin, pernyataan positif dan negatif bergantian. Matematikanya sudah terdokumentasi dengan baik; jangan ciptakan ulang.

Jalankan pada minggu yang sama setiap kuartal, pada alur yang sama, dengan setidaknya n=20 responden per alur. Tren lebih penting dari angka absolutnya.

5. Delta NPS Pasca-Peluncuran

Net Promoter Score adalah instrumen tumpul. Sendiri, ia adalah metric kosmetik. Tersegmentasi, ia adalah salah satu sinyal terkuat yang bisa kamu tunjukkan ke Head of Product.

Caranya: dalam 30 hari setelah redesain dikirimkan, segmentasikan respons NPS berdasarkan pengguna yang benar-benar mengakses alur yang didesain ulang vs. pengguna yang tidak. Bandingkan dua kohort. Jika kohort alur-yang-didesain-ulang mendapat skor +8 poin NPS lebih tinggi, kamu punya klaim yang bisa dipertahankan. Jika mereka mendapat skor yang sama atau lebih rendah, kamu punya masalah yang layak diselidiki.

Ini satu-satunya angka NPS yang pernah aku masukkan ke slide UX. NPS perusahaan secara keseluruhan adalah milik CEO. NPS pasca-peluncuran tersegmentasi kohort adalah milikmu.

Waspadai jebakannya: jangan bandingkan dengan NPS perusahaan penuh kuartal sebelumnya. Kamu mengukur alur, bukan perusahaan. Bandingkan kohort dengan kohort, jendela waktu yang sama.

Diagnosis "Keberhasilan Tugas Tinggi tapi Churn Tinggi"

Inilah yang tidak ada yang peringatkan padamu.

Alurnya berfungsi. SUS ada di 76. Keberhasilan tugas 91%. Waktu penyelesaian turun. Kamu mengirimkan. Kamu merayakan. Tiga bulan kemudian, churn tidak bergerak. Kadang malah memburuk.

Apa yang terjadi?

Biasanya salah satu dari tiga hal:

Kamu mengoptimalkan jobs-to-be-done yang salah. Pengguna menyelesaikan tugas yang kamu ukur, tapi tugasnya bukan apa yang sebenarnya ingin mereka capai. Contoh klasik: alur import yang didesain ulang dengan keberhasilan 94%, tapi pengguna mengimpor CSV karena mereka tidak bisa membuat API berfungsi. Pekerjaan sebenarnya adalah "masukkan data saya dengan cepat." Kamu mengoptimalkan solusi alternatifnya.

Langkah berikutnya rusak. Mereka menyelesaikan onboarding. Lalu mereka menghadapi kondisi kosong dan pergi. Atau mereka menghadapi dinding pricing yang tidak mereka duga. Atau mereka diserahkan ke sales rep yang butuh empat hari untuk merespons. Alur yang kamu ukur berhasil; perjalanannya gagal.

Kamu mengoptimalkan untuk pengguna pertama kali sambil merusak pengguna yang kembali. Keberhasilan tugas pengguna baru naik 22%. Keberhasilan tugas pengguna lama turun 8%. Pengguna lama adalah yang membayar. Mereka pergi.

Cara mendeteksi sebelum QBR:

1. Kelompokkan pengguna yang churn dalam 30 hari terakhir.
2. Tarik rekaman sesi untuk kohort tersebut, 7 hari sebelum churn.
3. Cari momen ragu-ragu: jeda panjang pada layar, kembali ke langkah sebelumnya, membuka artikel bantuan di tab baru.
4. Identifikasi layar tempat mereka ragu-ragu, meski metric sesi menunjukkan mereka "berhasil."
5. Layar itulah masalah nyatamu. Bukan yang kamu desain ulang.

Lima rekaman sesi pengguna yang churn akan mengajarkanmu lebih banyak dari lima puluh tes jalur bahagia. Investasinya dua jam. Hasilnya adalah daftar tiga hingga lima perbaikan yang menggerakkan retensi, bukan metric kosmetik. Lakukan ini setiap bulan.

Slide QBR

Satu slide. Empat angka. Satu catatan diagnosis. Jangan buat cantik. Buat mudah dipindai.

Tata letak (kiri ke kanan, atas ke bawah):

Di bawah tabel, satu baris:

Diagnosis: Penyelesaian onboarding naik 17% tapi retensi minggu ke-2 tidak bergerak. Rekaman sesi kohort menunjuk ke kondisi dashboard kosong. Perbaikan dijadwalkan untuk sprint berikutnya.

Itu seluruh slide-nya. Tidak ada screenshot dari redesain. Tidak ada frame Figma sebelum/sesudah. Tidak ada kutipan "pengguna sangat senang". Head of Product tidak akan membaca itu semua. Mereka akan membaca tabel, perubahan, dan diagnosa.

Jika mereka ingin Figma-nya, mereka akan meminta. Hampir tidak pernah.

Jebakan Metric Kosmetik

Hal-hal yang terlihat seperti UX metric tapi bukan:

Menit engagement sendiri. Sesi yang lebih lama bisa berarti kebingungan. Pengguna yang menghabiskan 12 menit mencari tombol ekspor bukan pengguna yang terlibat. Mereka terjebak. Padukan dengan keberhasilan tugas atau jangan laporkan sama sekali.

Design token yang dikirimkan. Ini adalah output, bukan outcome. Engineer tidak melaporkan "baris kode yang ditulis" karena alasan tertentu. Jangan laporkan ini juga.

NPS tanpa segmentasi. NPS keseluruhan adalah milik CEO. Jika kamu memasukkan NPS yang tidak tersegmentasi ke slide UX, kamu mengambil kredit untuk hal yang tidak kamu lakukan atau menerima kesalahan untuk hal yang tidak kamu rusak.

CSAT setelah tiket support. Mengukur agen support, bukan produk. Berguna untuk kepemimpinan support. Tidak berguna untukmu.

Bounce rate sebagai UX metric. Bounce rate adalah metric marketing di halaman landing. Pada permukaan produk, hampir selalu menyesatkan.

Jumlah pengujian kegunaan yang dijalankan. Aktivitas, bukan outcome. Angka yang tepat adalah "tes yang dijalankan yang mengubah keputusan desain" dan itu adalah angka yang sulit dilaporkan, itulah mengapa tidak ada yang melakukannya. Coba saja.

Daftar Periksa Instrumentasi

Sebelum kamu berkomitmen untuk melaporkan salah satu dari ini, pastikan kamu benar-benar bisa mengukurnya. Tinjau daftar ini bersama PM dan satu engineer:

• Alat session replay dipasang dan PII-scrubbed (FullStory, LogRocket, Hotjar, Heap)
• Pelacakan event pada semua pasangan mulai/selesai alur inti (mulai onboarding, selesai onboarding, dll.)
• Definisi funnel didokumentasikan dan dibagikan dengan product analytics
• Infrastruktur survei SUS (Typeform, modal dalam aplikasi, atau email triwulanan) dengan setidaknya n=20 per alur
• Survei NPS tersegmentasi berdasarkan eksposur fitur/alur, bukan hanya tanggal pengiriman
• Pengukuran baseline diambil sebelum redesain apa pun dikirimkan
• Dashboard bersama yang bisa dibuka PM tanpa memintamu

Jika kamu tidak bisa mencentang semua delapan, perbaiki kesenjangan sebelum berkomitmen pada metric. Melaporkan angka yang tidak bisa kamu percaya lebih buruk dari tidak melaporkan sama sekali.

Mengukur Kesuksesanmu Sendiri

Kamu akan tahu ini berhasil ketika:

• Kamu bisa menjawab "apakah desain bekerja?" dalam waktu kurang dari 60 detik dengan angka, bukan kata sifat.
• Design Lead-mu meneruskan slide QBR-mu ke Head of Product tanpa editan.
• PM berhenti meminta "umpan balik pengguna" dan mulai meminta "angka keberhasilan tugas terbaru."
• Seorang engineer meminta baseline sebelum memulai refactor karena mereka sudah terbiasa dengan format ini.
• Kamu menangkap kasus high-success-high-churn sebelum QBR, bukan sesudahnya.

Tujuannya bukan menjadi analis data. Tujuannya adalah berhenti menjadi orang di ruangan tanpa angka.

Lima metric. Satu diagnosis. Satu slide. Jalankan selama dua kuartal dan percakapan tentang UX di perusahaanmu akan berubah secara diam-diam.

Pelajari Lebih Lanjut

• Design Critique yang Tidak Melenceng
• Pengujian Kegunaan dengan Anggaran Terbatas
• Bekerja dengan PM yang Tidak Memahami Desain
• Job Description Product Designer