Program Studi Bisnis Digital • FEB UNDIP

Desain UI & UX

Pertemuan 12 — Perencanaan Usability Testing: Metrik Usability dan Skenario Tes

Merancang rencana pengujian yang bisa membuktikan apakah desain kita benar-benar mudah dipakai — bukan sekadar terlihat bagus.

RPS MINGGU 13 • 2×50 MENIT

Bagian 1 dari 4

Mengapa Usability Testing?

Menutup kesenjangan antara "menurut desainer bagus" dan "menurut pengguna bisa dipakai".

Apa Itu Usability Testing?

Usability testing (uji kebergunaan) adalah metode evaluasi yang mengamati pengguna asli saat mencoba menyelesaikan tugas nyata pada produk digital, untuk menemukan masalah sebelum produk dirilis.

Yang Diamati

Apakah tugas berhasil diselesaikan
Berapa lama waktu yang dibutuhkan
Di mana pengguna bingung / tersesat
Reaksi verbal & ekspresi (think-aloud)

Bukan Usability Testing

Survei kepuasan tanpa tugas nyata
Demo produk ke calon investor
A/B testing otomatis di produksi
Wawancara riset kebutuhan (tahap awal)

Istilah "think-aloud", berpikir keras, artinya kita meminta partisipan mengucapkan apa yang mereka pikirkan sambil mencoba aplikasi, misalnya "saya cari tombol bayar tapi tidak lihat, saya klik ini dulu deh". Perbedaan penting dengan survei kepuasan adalah usability testing mengamati PERILAKU nyata saat mengerjakan tugas, bukan hanya menanyakan pendapat setelahnya — orang sering bilang "sudah bagus kok" padahal tadi kesulitan selama tiga menit mencari tombol. Contoh konkret, Bank BCA menguji aplikasi BCA Mobile dengan meminta pengguna melakukan transfer antar bank sungguhan sambil diamati dan direkam, bukan sekadar bertanya "menurut Anda aplikasi ini mudah tidak". Ingat, usability testing dilakukan pada PROTOTIPE atau produk yang sudah bisa diklik-klik, bukan pada sketsa kasar yang belum interaktif.

Lima Komponen Usability (Nielsen)

Jakob Nielsen — pakar UX terkemuka — merumuskan lima dimensi yang menentukan apakah sebuah produk benar-benar "usable" (mudah dipakai).

Learnability

Mudah Dipelajari

Seberapa cepat pengguna baru menyelesaikan tugas dasar saat pertama kali mencoba.

Efficiency

Efisien

Seberapa cepat pengguna yang sudah paham menyelesaikan tugas.

Memorability

Mudah Diingat

Setelah lama tidak pakai, apakah pengguna cepat mahir lagi?

Errors

Kesalahan

Berapa banyak kesalahan dan apakah pengguna bisa pulih sendiri dari kesalahan itu.

Satisfaction

Kepuasan

Apakah pengalaman memakainya terasa menyenangkan, bukan menyiksa.

Posisi Usability Testing dalam Alur Desain

Usability testing dilakukan setelah prototipe interaktif siap, dan hasilnya menjadi bahan iterasi sebelum desain difinalkan.

Ingat: menguji terlalu awal (sketsa kasar) menyulitkan pengguna berpikir seperti pengguna asli; menguji terlalu telat (setelah rilis) berarti biaya perbaikan sudah membengkak.

Perhatikan diagram ini karena menjawab pertanyaan yang sering ditanyakan mahasiswa: kapan sebenarnya kita menguji desain? Jawabannya, kita butuh prototipe yang sudah bisa diklik-klik secara interaktif — bukan sekadar gambar statis — supaya partisipan bisa benar-benar "mencoba" seperti memakai aplikasi sungguhan, ini kita bahas di pertemuan sebelumnya soal prototyping. Untuk proyek akhir kelas ini, Anda akan menguji prototipe Figma yang sudah dibuat interaktif pada pertemuan 11, lalu hasil temuannya dipakai untuk revisi di pertemuan 14 sebelum presentasi akhir. Sebagai analogi, ini seperti chef yang mencicipi masakan sebelum disajikan ke tamu restoran — kalau baru dicicipi setelah tamu komplain, reputasi sudah telanjur rusak. Semakin dini masalah usability ditemukan, semakin murah biaya memperbaikinya dibanding menemukannya setelah aplikasi diluncurkan ke publik.

Bagian 2 dari 4

Metrik Usability

Mengubah pengamatan menjadi angka yang bisa dibandingkan dan dilaporkan.

Dua Jenis Metrik Usability

Metrik Kuantitatif

Task success rate — persentase tugas berhasil
Time on task — waktu menyelesaikan tugas
Error rate — jumlah kesalahan per tugas
Jumlah klik hingga tujuan tercapai

Metrik Kualitatif

SUS (System Usability Scale) — skor kepuasan
Komentar think-aloud saat mengerjakan tugas
Ekspresi frustrasi / kebingungan yang diamati
Wawancara singkat pasca-tugas

Kombinasi keduanya paling kuat: angka menunjukkan seberapa besar masalahnya, komentar menunjukkan apa masalahnya.

Metrik kuantitatif memberi angka pasti — misalnya 6 dari 10 partisipan berhasil menyelesaikan tugas checkout — sementara metrik kualitatif memberi konteks KENAPA angka itu terjadi, misalnya komentar "saya kira tombol keranjang itu untuk wishlist". Perhatikan bahwa keduanya saling melengkapi: kalau Anda hanya punya angka tanpa komentar, Anda tahu ADA masalah tapi tidak tahu SOLUSINYA; kalau hanya punya komentar tanpa angka, sulit meyakinkan tim bahwa masalah itu signifikan dan layak diprioritaskan. Contohnya tim UX Traveloka biasanya melaporkan kombinasi keduanya ke product manager: "80% pengguna gagal menemukan filter harga, karena tombolnya tersembunyi di scroll bawah layar". Pada slide berikutnya kita akan menghitung dari nol dua metrik yang paling sering dipakai di industri: task success rate dan skor SUS.

Hitung dari Nol #1 — Task Success Rate

Kasus: 25 partisipan diuji mencoba fitur "checkout" pada prototipe aplikasi UMKM lokal. 22 partisipan berhasil menyelesaikan tanpa bantuan.

Langkah	Perhitungan	Nilai
1. Jumlah partisipan berhasil	Diberikan dari data pengamatan	22 orang
2. Jumlah total partisipan	Diberikan dari data pengamatan	25 orang
3. Task Success Rate	22 ÷ 25 × 100	88%

Task Success Rate

88%

22 dari 25 partisipan berhasil

Coba Sendiri: Hitung Task Success Rate Pengujian Anda

Ubah jumlah partisipan yang berhasil dan total partisipan, lalu amati bagaimana persentase keberhasilan berubah.

Time on Task & Error Rate

Time on Task = Waktu selesai − Waktu mulai

Error Rate = Jumlah kesalahan ÷ Jumlah percobaan

Contoh: partisipan mulai tugas pukul 10:02:00 dan selesai pukul 10:04:30 → time on task = 2 menit 30 detik. Dari 10 partisipan yang mencoba fitur "hapus item keranjang", tercatat total 4 kesalahan klik (salah menekan tombol lain) → error rate = 4 ÷ 10 = 0,4 kesalahan/partisipan.

Waktu yang lebih lama bukan selalu buruk — untuk tugas yang butuh kehati-hatian (mis. transfer dana besar), waktu sedikit lebih lama bisa berarti pengguna membaca konfirmasi dengan cermat, bukan bingung.

Time on task dihitung sesederhana selisih waktu selesai dikurangi waktu mulai — pada contoh ini partisipan butuh 2 menit 30 detik untuk menyelesaikan tugasnya, angka ini kita catat memakai stopwatch atau fitur rekam layar saat sesi pengujian berlangsung. Error rate dihitung dengan membagi total kesalahan dengan jumlah percobaan atau partisipan, dalam contoh ini 4 kesalahan dibagi 10 partisipan sama dengan 0,4 kesalahan per orang, artinya rata-rata tidak sampai satu kesalahan per partisipan yang tergolong wajar. Penting untuk diingat, durasi yang lebih lama tidak otomatis berarti desain buruk — misalnya saat menguji fitur transfer dana besar di aplikasi Livin' by Mandiri, pengguna yang membaca layar konfirmasi dengan teliti sebelum menekan "kirim" itu justru perilaku yang kita HARAPKAN, bukan tanda kebingungan. Oleh karena itu metrik waktu selalu perlu dibaca berdampingan dengan komentar think-aloud dan konteks jenis tugasnya.

Hitung dari Nol #2 — Skor System Usability Scale (SUS)

SUS = 10 pertanyaan skala 1–5 (ganjil = pernyataan positif, genap = pernyataan negatif). Contoh 1 partisipan, skor mentah pertanyaan 1–10: 4,2,5,1,4,2,5,2,4,1.

Langkah	Perhitungan	Nilai
1. Jumlah item ganjil (positif) − 1	(4−1)+(5−1)+(4−1)+(5−1)+(4−1)	17
2. 5 − item genap (negatif)	(5−2)+(5−1)+(5−2)+(5−2)+(5−1)	15
3. Jumlah total (skala 0–40)	17 + 15	32
4. Skor SUS akhir (skala 0–100)	32 × 2,5	80

Skor SUS

dari skala 0–100

SUS memakai formula baku yang sedikit rumit tapi mekanis: untuk pertanyaan bernomor ganjil yang berupa pernyataan positif seperti "saya rasa akan sering memakai sistem ini", kita kurangi skor mentahnya dengan 1; untuk pertanyaan genap yang negatif seperti "sistem ini terlalu rumit", kita hitung 5 dikurangi skor mentahnya, supaya arah skalanya konsisten. Setelah dijumlahkan semua sepuluh item, kita dapat total dalam rentang 0 sampai 40, lalu kita kalikan 2,5 untuk mengonversinya ke skala 0 sampai 100 yang lebih mudah dibaca dan dibandingkan, hasilnya di contoh ini adalah 80. Rumus lengkap dengan sepuluh pertanyaan asli akan ada di lembar kerja praktikum minggu depan, hari ini fokus dulu pada LOGIKA perhitungannya. Skor 80 ini tergolong sangat baik — pada slide berikutnya kita akan bahas cara membaca dan menafsirkan angka SUS ini secara industri.

Menafsirkan Skor SUS

Skor SUS tunggal tidak berarti apa-apa tanpa tolok ukur. Berikut kurva adjektif Bangor, Kortum & Miller yang umum dipakai industri:

Skor 80 dari contoh sebelumnya masuk kategori "sangat baik" — di atas rata-rata industri ~68.

Angka SUS tunggal seperti 80 tidak ada artinya kalau berdiri sendiri, kita perlu membandingkannya dengan tolok ukur, dan yang paling umum dipakai adalah skala adjektif dari penelitian Bangor, Kortum, dan Miller yang membagi skor menjadi buruk, cukup, baik, dan sangat baik. Rata-rata industri untuk skor SUS berbagai macam aplikasi adalah sekitar 68 — jadi kalau aplikasi Anda dapat skor di bawah itu, ada pekerjaan rumah yang harus diperbaiki sebelum dianggap kompetitif. Sebagai gambaran, aplikasi dengan pengalaman sangat mulus seperti Google Search sering mendapat skor SUS di atas 85, sementara aplikasi pemerintah yang rumit terkadang hanya mendapat skor di kisaran 50-an. Untuk proyek akhir kelas ini, targetkan skor SUS minimal 68 dari partisipan uji Anda — kalau di bawah itu, catat komentar think-aloud mereka sebagai bahan revisi di pertemuan 14.

Coba Sendiri: Hitung Skor SUS Anda Sendiri

Isi 10 skor mentah 1–5, lalu amati skor SUS akhir terhitung otomatis dan kategorinya menurut kurva Bangor.

Bagian 3 dari 4

Merancang Skenario Tes

Metrik hanya berguna kalau tugas yang diuji dirancang dengan benar.

Anatomi Skenario Tugas yang Baik

Ciri Skenario Baik

Berbasis konteks/cerita, bukan instruksi mekanis
Realistis — mewakili tujuan pengguna asli
Punya kondisi akhir yang jelas (tahu kapan "berhasil")
Tidak menuntun jawaban / lokasi tombol

4 Elemen Wajib

1Konteks singkat (situasi pengguna)
2Tujuan yang harus dicapai
3Data pendukung (nama, jumlah, dsb.)
4Kriteria selesai (untuk moderator)

Skenario tugas yang baik selalu dibungkus dalam konteks cerita, bukan perintah kaku seperti "klik tombol beli sekarang" karena itu justru menuntun partisipan langsung ke jawaban dan membuat data pengujian tidak valid. Perhatikan empat elemen wajib: konteks memberi partisipan alasan kenapa mereka melakukan tugas ini, tujuan menjelaskan apa yang harus dicapai tanpa menyebutkan caranya, data pendukung memberi detail konkret seperti nomor pesanan atau nominal supaya partisipan tidak perlu mengarang, dan kriteria selesai adalah catatan RAHASIA untuk moderator supaya tahu kapan menghentikan pengamatan. Bayangkan Anda menguji aplikasi Shopee: skenario yang baik berbunyi "Anda baru menerima pesanan sepatu yang ternyata salah ukuran, silakan lakukan apa yang perlu Anda lakukan" — bukan "silakan klik menu pengembalian barang di halaman pesanan saya". Kita akan bandingkan langsung contoh buruk dan baik pada slide berikutnya.

Walkthrough: Skenario Buruk → Baik

Studi kasus: menguji fitur "ubah alamat pengiriman" pada aplikasi marketplace lokal.

Walkthrough 1 — Revisi Skenario

Tahap	Isi Skenario
Draf awal (buruk)	"Klik ikon profil, lalu buka menu Alamat, lalu tekan Edit."
Masalah	Menyebutkan lokasi & urutan klik → menuntun, bukan menguji navigasi asli
Revisi (baik)	"Anda baru pindah rumah ke Jl. Diponegoro No. 5. Perbarui alamat pengiriman akun Anda."

Mari kita telusuri bersama satu contoh nyata langkah demi langkah: draf pertama yang sering dibuat pemula berbunyi "klik ikon profil, lalu buka menu alamat, lalu tekan edit" — ini terlihat jelas dan sopan, tapi sebetulnya adalah instruksi navigasi, bukan skenario uji. Masalahnya, kalau kita memberi tahu partisipan persis di mana harus klik, kita tidak lagi menguji apakah MEREKA bisa menemukan menu itu sendiri — hasil pengujian jadi bias karena partisipan seperti dituntun tangan. Revisinya adalah skenario berbasis cerita: "Anda baru pindah rumah ke Jalan Diponegoro nomor 5, perbarui alamat pengiriman akun Anda" — di sini partisipan harus mencari sendiri di mana menu pengaturan alamat berada, persis seperti pengguna asli aplikasi Bukalapak atau Blibli yang pindah rumah. Perhatikan polanya: skenario baik selalu menyembunyikan CARA, hanya menyatakan TUJUAN dan KONTEKS.

Berapa Banyak Partisipan yang Dibutuhkan?

Aturan 5 Pengguna (Nielsen): 5 partisipan ≈ menemukan ~85% masalah usability

Uji Formatif (Iteratif)

5–8

per putaran pengujian

Cocok untuk menemukan masalah besar cepat, lalu revisi, lalu uji lagi.

Uji Sumatif (Perbandingan)

20–30+

untuk hasil statistik valid

Dibutuhkan saat membandingkan dua desain secara kuantitatif (mis. skor SUS A vs B).

Menambah partisipan setelah 5 orang memberi hasil yang menurun (diminishing returns) untuk uji formatif — lebih efektif uji 5 orang, revisi, lalu uji 5 orang lagi.

Ini adalah salah satu temuan paling terkenal dalam dunia UX dari riset Jakob Nielsen dan Tom Landauer, yang menunjukkan bahwa menguji dengan 5 partisipan saja sudah cukup menemukan sekitar 85 persen masalah usability yang ada — menambah partisipan ke-6, ke-7, dan seterusnya memberi tambahan temuan yang semakin sedikit karena masalah yang sama mulai berulang. Untuk proyek kelompok Anda yang sifatnya formatif atau iteratif, artinya menguji ke 5 orang, memperbaiki desain berdasarkan temuan itu, lalu menguji lagi ke 5 orang baru jauh lebih efektif daripada menguji sekaligus ke 20 orang di awal. Namun kalau tujuannya membandingkan dua alternatif desain secara statistik — misalnya desain checkout versi A vs versi B mana yang skor SUS-nya lebih tinggi secara signifikan — Anda butuh sampel jauh lebih besar, biasanya di atas 20 partisipan, supaya perbedaannya bukan kebetulan. Sebagai gambaran skala industri, perusahaan sebesar Gojek biasa menguji fitur baru dengan 8 hingga 12 partisipan per putaran sebelum dirilis ke sebagian kecil pengguna (beta).

Menyusun Rencana Pengujian (Test Plan)

Isi Test Plan

Tujuan pengujian & pertanyaan riset
Profil partisipan (kriteria rekrutmen)
Daftar skenario tugas (3–5 tugas)
Metrik yang dicatat per tugas
Skrip moderator (pembuka, penutup)

Protokol Think-Aloud

Minta partisipan bicara terus-menerus
Moderator tidak membantu kecuali macet total
Gunakan pertanyaan netral: "Apa yang Anda pikirkan sekarang?"
Hindari pertanyaan menuntun: "Sudah lihat tombol biru itu?"

Test plan adalah dokumen rencana lengkap sebelum pengujian dimulai — bayangkan ini seperti proposal penelitian mini yang menjelaskan apa yang ingin dibuktikan, siapa yang akan diuji, tugas apa saja yang diberikan, dan bagaimana hasilnya akan diukur. Protokol think-aloud punya aturan penting: moderator harus menahan diri untuk tidak membantu partisipan meskipun terlihat kesulitan, karena tujuannya justru mengamati DI MANA mereka kesulitan — kecuali partisipan benar-benar macet total dan sesi tidak bisa dilanjutkan. Gunakan pertanyaan netral seperti "apa yang sedang Anda pikirkan sekarang" alih-alih pertanyaan menuntun seperti "sudah lihat tombol biru di pojok kanan itu", karena pertanyaan menuntun sama saja memberi jawaban dan merusak validitas data. Untuk proyek akhir Anda, test plan ini wajib dikumpulkan sebelum sesi pengujian dimulai di pertemuan 13, sehingga dosen bisa memberi masukan sebelum Anda merekrut partisipan sungguhan.

Latihan Kelompok — Susun 3 Skenario Tugas

Instruksi (20 menit, kerja kelompok proyek akhir):

Ambil prototipe Figma proyek akhir kelompok Anda (dari Pertemuan 11).
Tulis 3 skenario tugas berbasis cerita mengikuti 4 elemen wajib (konteks, tujuan, data, kriteria selesai).
Tandai untuk setiap skenario: metrik apa yang akan dicatat (success rate, time on task, atau keduanya).
Tukar draf dengan kelompok lain — cek apakah ada kalimat yang menuntun jawaban.

Hasil latihan ini menjadi cikal-bakal test plan yang akan dipakai untuk pelaksanaan usability testing di Pertemuan 13.

Sekarang saatnya latihan langsung, silakan berkumpul dengan kelompok proyek akhir Anda masing-masing dan buka kembali prototipe Figma yang sudah dibuat interaktif pada pertemuan sebelumnya. Tuliskan tiga skenario tugas dengan mengikuti empat elemen wajib yang sudah kita bahas: konteks cerita, tujuan yang jelas, data pendukung konkret, dan kriteria selesai untuk moderator — hindari menyebutkan nama tombol atau lokasi menu secara eksplisit. Setelah selesai menulis, saya minta Anda bertukar draf dengan kelompok lain di sebelah Anda untuk saling mengecek apakah ada kalimat yang secara tidak sengaja menuntun jawaban, karena kita sendiri sering tidak sadar sudah menuntun karena terlalu dekat dengan desain kita sendiri. Ingat, latihan hari ini adalah fondasi test plan yang akan benar-benar Anda pakai untuk merekrut dan menguji partisipan sungguhan minggu depan, jadi kerjakan dengan serius seolah ini akan dipakai untuk klien nyata.

Bagian 4 dari 4

Kesalahan Umum & Rangkuman

Menghindari jebakan klasik sebelum turun ke lapangan minggu depan.

Kesalahan Umum dalam Usability Testing

Kesalahan Perancangan

Skenario menyebut nama tombol/menu langsung
Menguji terlalu banyak tugas (>5) → partisipan lelah
Tidak menentukan kriteria "berhasil" sebelumnya

Kesalahan Pelaksanaan

Moderator membantu saat partisipan kesulitan
Merekrut partisipan yang bukan target pengguna
Tidak mencatat metrik secara konsisten antar-sesi

Kesalahan paling sering pada perancangan adalah skenario yang secara tidak sengaja menyebut nama tombol atau menu, yang membuat hasil pengujian bias karena partisipan tinggal mengikuti instruksi bukan benar-benar mencari sendiri. Kesalahan lain adalah menguji terlalu banyak tugas sekaligus dalam satu sesi — idealnya 3 sampai 5 tugas per sesi 30-45 menit — karena partisipan yang lelah akan memberi data yang tidak representatif pada tugas-tugas terakhir. Pada sisi pelaksanaan, kesalahan paling fatal adalah moderator yang secara refleks membantu partisipan yang terlihat kebingungan, misalnya tanpa sadar berkata "coba klik yang di kanan atas itu" — ini menghancurkan validitas seluruh data yang dikumpulkan. Contoh nyata, tim UX pemula sering merekrut teman sekelas sendiri sebagai partisipan uji aplikasi UMKM padahal target pengguna sebenarnya adalah ibu-ibu pedagang pasar berusia 40-an yang kurang terbiasa dengan aplikasi — data yang dihasilkan jadi tidak mewakili pengguna asli sama sekali.

Rangkuman & Menuju Pertemuan 13

Cheat Sheet Hari Ini

Konsep	Inti
Task Success Rate	Berhasil ÷ Total × 100
Time on Task	Selesai − Mulai
SUS	Total (0–40) × 2,5 → skala 0–100
Skenario baik	Konteks + tujuan, bukan cara
Jumlah partisipan	5 formatif · 20+ sumatif

Tugas Sebelum Pertemuan 13

Test Plan Siap

Kelompok mengumpulkan test plan lengkap (skenario + metrik + skrip moderator) dari latihan hari ini, siap dipakai untuk pelaksanaan pengujian sungguhan minggu depan.

Mari kita rangkum: hari ini Anda telah belajar mengukur usability lewat metrik kuantitatif seperti task success rate, time on task, dan error rate, serta metrik kualitatif berupa skor SUS yang dihitung dari sepuluh pertanyaan berskala. Anda juga belajar merancang skenario tugas yang baik dengan empat elemen wajib — konteks, tujuan, data pendukung, kriteria selesai — dan menghindari kesalahan umum seperti menuntun jawaban atau merekrut partisipan yang salah target. Minggu depan di Pertemuan 13, kita akan benar-benar melaksanakan usability testing menggunakan test plan yang kelompok Anda susun hari ini, lengkap dengan protokol think-aloud dan pencatatan metrik secara langsung. Pastikan sebelum pertemuan berikutnya, kelompok Anda sudah punya test plan lengkap dan sudah menghubungi minimal 5 calon partisipan yang sesuai profil target pengguna — selamat mengerjakan, dan sampai jumpa di sesi pengujian sungguhan minggu depan.