PRODI BISNIS DIGITAL · FEB UNDIP

Teknologi Web & Mobile

Pertemuan 13: Prototipe Interaktif & Uji Usabilitas

Dari mockup diam ke prototipe yang bisa "dirasakan" — lalu buktikan lewat pengguna asli, bukan asumsi tim.

RPS minggu 14 · 2x50 menit

Selamat datang di pertemuan ke-13, Anda sudah melewati materi keamanan minggu lalu dan sekarang masuk ke tahap yang sangat praktis: menguji apakah produk digital yang dirancang benar-benar bisa dipakai orang. Bayangkan Anda tim produk di Tokopedia yang baru punya ide fitur checkout baru — sebelum insinyur menghabiskan berbulan-bulan coding, tim akan membuat prototipe interaktif dulu dan mengujinya ke calon pengguna. Hari ini Anda akan belajar bedanya mockup statis dengan prototipe interaktif, cara merancang skenario uji usabilitas, dan cara membaca hasilnya secara kuantitatif memakai metrik seperti tingkat keberhasilan tugas dan System Usability Scale. Ini penting karena sebagai calon manajer produk digital, keputusan Anda soal fitur harus berbasis bukti dari pengguna nyata, bukan sekadar opini tim internal atau atasan.

Tujuan Pembelajaran

Setelah pertemuan ini, Anda mampu:

TUJUAN 1

Bedakan tingkat fidelitas prototipe

Menjelaskan perbedaan low-fidelity, mid-fidelity, dan high-fidelity prototype beserta kapan masing-masing dipakai dalam siklus pengembangan produk.

TUJUAN 2

Rancang skenario uji usabilitas

Menyusun task scenario dan protokol uji usabilitas yang valid untuk menguji satu alur fitur digital, lengkap dengan metrik keberhasilan.

TUJUAN 3

Hitung metrik usabilitas

Menghitung Success Rate dan skor System Usability Scale (SUS) dari data hasil pengujian pengguna secara manual dari nol.

TUJUAN 4

Terjemahkan temuan jadi keputusan

Mengubah temuan uji usabilitas menjadi rekomendasi perbaikan produk yang actionable bagi tim desain dan teknologi.

Empat tujuan ini berurutan seperti alur kerja nyata di industri: Anda mulai dari memahami apa itu prototipe dan tingkat kematangannya, lalu belajar merancang eksperimen pengujian yang adil dan terstruktur, kemudian menghitung angka-angka yang membuktikan produk itu mudah atau sulit dipakai, dan terakhir menerjemahkan angka tadi menjadi keputusan bisnis. Sebagai contoh, jika Anda bekerja di startup fintech seperti Flip atau Jenius, tim UX researcher akan melalui keempat tahap ini setiap kali merilis fitur baru sebelum fitur itu benar-benar diluncurkan ke jutaan pengguna. Perhatikan bahwa tujuan ketiga bersifat kuantitatif — ini bagian yang akan kita latih dengan hitungan langkah demi langkah nanti, jadi siapkan kalkulator Anda. Di akhir sesi, Anda diharapkan bisa membaca laporan hasil uji usabilitas layaknya seorang product manager, bukan hanya sebagai pengguna aplikasi.

BAGIAN 1 DARI 3

Mengapa Prototipe & Uji Usabilitas Penting?

Produk digital yang gagal bukan karena teknologinya buruk, tapi karena tidak pernah diuji ke pengguna sungguhan sebelum diluncurkan.

Sebelum masuk ke definisi teknis, mari kita bicara soal risiko bisnis dahulu supaya Anda paham kenapa topik ini masuk mata kuliah bisnis digital, bukan hanya mata kuliah desain. Banyak startup di Indonesia menghabiskan dana investor untuk membangun aplikasi penuh selama enam bulan, lalu setelah diluncurkan ternyata pengguna bingung cara memakainya dan aplikasi itu di-uninstall dalam hitungan menit — ini kerugian yang bisa dicegah dengan pengujian dini. Blok pertama ini akan membangun argumen mengapa perusahaan sekelas Gojek dan Bank Jago rela menghabiskan waktu untuk prototipe murah sebelum menyentuh baris kode produksi. Anda akan melihat bagaimana biaya memperbaiki kesalahan desain melonjak drastis semakin lambat kesalahan itu ditemukan. Simak baik-baik karena konsep ini akan menjadi dasar argumentasi Anda ketika suatu saat harus meyakinkan atasan untuk mengalokasikan waktu dan anggaran bagi riset pengguna.

Kasus Pembuka: Kenapa Fitur Bagus Bisa Gagal Total?

Sebuah e-commerce lokal meluncurkan fitur "checkout satu klik" tanpa uji pengguna. Hasilnya setelah 2 minggu:

KELUHAN CS

+340%

tiket bantuan checkout

TRANSAKSI GAGAL

1 dari 4

pengguna batal beli

BIAYA PERBAIKAN

~15x

lebih mahal vs uji di awal

Angka ilustratif untuk menggambarkan pola nyata di industri — bukan data satu perusahaan spesifik. Polanya konsisten: kesalahan desain yang ditemukan setelah rilis jauh lebih mahal diperbaiki daripada saat masih berupa prototipe kertas.

Kasus ini adalah komposit dari pola yang berulang di banyak studi UX dan pengalaman industri, jadi anggap ini ilustrasi realistis bukan laporan resmi satu perusahaan. Bayangkan Anda sebagai product manager di perusahaan seperti Blibli atau Bukalapak yang tim engineering-nya sudah terlanjur membangun fitur checkout satu klik penuh, lalu ternyata tombolnya membingungkan karena pengguna mengira itu tombol "lihat detail" bukan tombol "bayar sekarang". Kalau ini ditemukan lewat prototipe kertas di minggu pertama, biayanya hanya waktu diskusi tim selama satu jam; kalau ditemukan setelah aplikasi live, biayanya termasuk jam kerja developer untuk revisi, waktu QA ulang, dan yang paling mahal adalah kepercayaan pengguna yang sudah kadung kecewa. Prinsip ini dikenal sebagai hukum peningkatan biaya perbaikan seiring tahap pengembangan — semakin telat ditemukan, semakin mahal. Inilah alasan mengapa uji usabilitas idealnya dilakukan berulang kali sejak tahap paling awal, bukan sekali saja menjelang peluncuran.

Definisi: Prototipe & Uji Usabilitas

PROTOTIPE (PROTOTYPE)

Representasi awal produk yang bisa "dicoba" sebelum dibangun penuh dalam kode. Fungsinya untuk mengumpulkan umpan balik cepat dan murah.

UJI USABILITAS (USABILITY TESTING)

Metode riset di mana pengguna asli mencoba menyelesaikan tugas nyata memakai prototipe, sambil diamati dan diukur tingkat keberhasilannya.

Kata kunci: prototipe menjawab pertanyaan "apakah ide ini bisa dibangun & masuk akal?", sedangkan uji usabilitas menjawab "apakah manusia sungguhan bisa memakainya?" Keduanya berbeda tapi saling melengkapi.

Mahasiswa sering mengira prototipe dan produk jadi itu sama, padahal bedanya besar — prototipe boleh "berpura-pura" bekerja, misalnya tombol yang diklik hanya berpindah gambar statis tanpa logika pemrograman sungguhan di baliknya. Contohnya aplikasi seperti Figma memungkinkan desainer membuat rangkaian layar yang bisa diklik dan berpindah seolah aplikasi asli, padahal di baliknya tidak ada satu baris kode fungsional pun. Uji usabilitas kemudian adalah kegiatan mengundang lima sampai delapan calon pengguna, memberi mereka tugas seperti "coba cari dan beli sepatu ukuran 42 di aplikasi ini", lalu mengamati di mana mereka bingung, ragu, atau salah klik. Ingat istilah ini baik-baik karena keduanya akan terus dipakai sepanjang materi hari ini — prototipe adalah alatnya, uji usabilitas adalah cara memakai alat itu untuk belajar sesuatu tentang penggunanya.

Tiga Tingkat Fidelitas Prototipe

Aturan praktis: makin awal tahap ide, makin rendah fidelitas yang dipakai — jangan buang waktu membuat tampilan cantik sebelum alurnya sendiri terbukti masuk akal.

Bayangkan tiga tahap ini seperti membangun rumah: low-fidelity itu sketsa denah di atas kertas yang Anda gambar bersama arsitek dalam sepuluh menit, mid-fidelity itu blueprint teknis yang menunjukkan ukuran ruangan tapi belum ada pilihan cat, dan high-fidelity itu rumah contoh yang sudah dicat dan diberi furnitur sehingga calon pembeli bisa "merasakan" tinggal di sana. Di dunia digital, tim di Traveloka misalnya akan mulai dengan sketsa kertas untuk fitur baru pencarian tiket, lalu naik ke wireframe abu-abu di Figma untuk menguji alur logika, dan baru di tahap akhir membuat tampilan penuh warna lengkap dengan animasi sebelum diserahkan ke developer. Kesalahan umum pemula bisnis digital adalah langsung loncat ke high-fidelity karena terlihat lebih "profesional", padahal itu memboroskan waktu jika ternyata alur dasarnya masih harus diubah total. Ingat aturan sederhana ini: makin banyak ketidakpastian tentang apakah ide itu benar, makin rendah fidelitas yang seharusnya Anda pakai dulu.

Alat Prototyping yang Umum Dipakai Industri

DESAIN & KLIK-ANTAR-LAYAR

Figma

standar industri saat ini

SKETSA CEPAT

Kertas

+ pena, tanpa software

INTERAKSI KOMPLEKS

ProtoPie

animasi & sensor lanjutan

Alat hanyalah sarana — keputusan bisnis yang benar tetap datang dari kualitas skenario pengujian, bukan dari kecanggihan software prototyping-nya.

Sebagai mahasiswa bisnis digital, Anda tidak dituntut mahir mengoperasikan software ini secara teknis, tapi Anda perlu tahu perannya dalam pengambilan keputusan produk sehingga bisa berkomunikasi efektif dengan tim desain dan teknologi. Figma saat ini menjadi standar de facto di hampir semua startup Indonesia dari Gojek sampai perusahaan rintisan kecil karena memungkinkan kolaborasi real-time dan mudah dibuat interaktif tanpa coding. Sketsa kertas tetap relevan justru karena kecepatannya — dalam rapat lima menit, tim bisa menggambar tiga alternatif alur di atas kertas dan langsung mendiskusikan mana yang paling masuk akal tanpa menunggu software terbuka. ProtoPie dan sejenisnya dipakai ketika interaksi yang diuji cukup rumit, misalnya animasi drag-and-drop atau respons terhadap sensor gerak di aplikasi kebugaran. Yang harus Anda ingat sebagai calon manajer produk bukan cara memakai tool-nya, melainkan kapan tim Anda butuh tingkat kecanggihan tool yang mana.

BAGIAN 2 DARI 3

Merancang Uji Usabilitas

Sebuah pengujian yang baik dimulai dari pertanyaan yang jelas dan skenario tugas yang realistis, bukan sekadar "coba pakai lalu kasih pendapat".

Lima Komponen Protokol Uji Usabilitas

1–2: SIAPA & APA

Peserta (participant): representatif dari target pengguna asli, bukan tim internal
Task scenario: instruksi tugas nyata, ditulis sebagai cerita, bukan perintah teknis

3–5: BAGAIMANA DIUKUR

Metrik keberhasilan: selesai/tidak, waktu, jumlah kesalahan
Metode observasi: think-aloud, rekam layar, catat ekspresi
Kuesioner pasca-tugas: mengukur persepsi kemudahan (mis. SUS)

Kelima komponen ini adalah kerangka minimal yang harus ada di setiap rencana uji usabilitas profesional, dan hilangnya salah satu komponen membuat hasil pengujian sulit ditafsirkan. Peserta harus representatif — kalau Anda menguji aplikasi belanja untuk ibu rumah tangga usia 40 tahun, jangan menguji ke sesama mahasiswa kampus karena hasilnya bisa menyesatkan tim produk. Task scenario ditulis sebagai cerita realistis, misalnya "Anda ingin membeli tiket kereta ke Yogyakarta untuk keberangkatan akhir pekan depan, silakan cari dan pesan tiket tersebut" — bukan instruksi teknis seperti "klik tombol cari lalu isi tanggal" karena itu membocorkan jawabannya. Metrik keberhasilan harus disepakati sebelum sesi dimulai, misalnya berapa lama waktu wajar untuk menyelesaikan tugas dan berapa banyak kesalahan yang masih dianggap wajar. Metode think-aloud artinya peserta diminta bicara apa yang mereka pikirkan sambil mencoba aplikasi, ini sangat berguna untuk menangkap kebingungan yang tidak terlihat dari luar.

Task Scenario yang Baik vs Buruk

CONTOH BURUK — MEMBOCORKAN JAWABAN

"Klik ikon keranjang di kanan atas, lalu tekan tombol checkout."

Peserta hanya mengikuti perintah, bukan memakai penalaran sendiri — datanya tidak mencerminkan pengalaman pengguna asli.

CONTOH BAIK — BERBASIS TUJUAN

"Anda ingin membeli sepatu lari ukuran 42 warna hitam. Silakan selesaikan pembeliannya sampai pesanan berhasil dibuat."

Peserta harus menemukan jalannya sendiri — di sinilah letak masalah usabilitas terungkap.

Jebakan umum pemula: menulis skenario yang menyebut nama tombol atau menu — ini disebut leading task dan merusak validitas hasil pengujian.

Perbandingan ini sering menjadi titik lemah mahasiswa saat pertama kali membuat rencana pengujian, jadi mari kita bedah lebih dalam. Ketika instruksi menyebut nama tombol secara eksplisit seperti "klik ikon keranjang", peserta uji tidak lagi menunjukkan apakah mereka bisa menemukan ikon itu sendiri — Anda hanya menguji apakah mereka bisa mengikuti perintah, yang tentu saja hampir selalu berhasil dan tidak informatif. Sebaliknya, skenario berbasis tujuan seperti mencari sepatu ukuran tertentu memaksa peserta menjelajah aplikasi dengan caranya sendiri, sehingga jika mereka tersesat mencari filter ukuran, itu adalah temuan usabilitas yang berharga bagi tim desain. Contoh nyata, tim di aplikasi seperti Zalora Indonesia pasti menguji fitur filter produk dengan skenario semacam ini, bukan dengan menyebutkan letak tombol filter. Istilah "leading task" atau tugas yang menuntun ini penting Anda ingat karena akan sering muncul dalam diskusi riset pengguna profesional, mirip dengan konsep leading question dalam wawancara yang bisa membiaskan jawaban responden.

Berapa Banyak Peserta yang Dibutuhkan?

5 peserta ≈ menemukan ∼85% masalah usabilitas utama

Prinsip dari riset klasik Jakob Nielsen: menambah peserta setelah 5 orang memberi temuan baru yang makin sedikit per peserta tambahan — sementara biaya terus naik linear.

1 PESERTA

~31%

masalah ditemukan

5 PESERTA

~85%

masalah ditemukan

Untuk tim kecil/UMKM digital dengan anggaran terbatas: 5 peserta per putaran jauh lebih efisien daripada menunggu bisa menguji 30 orang sekaligus.

Angka lima peserta ini bukan mitos di dunia UX, melainkan berasal dari riset yang dipopulerkan Jakob Nielsen, salah satu tokoh paling berpengaruh dalam bidang usability engineering, dan angkanya tetap dipakai luas oleh industri hingga sekarang sebagai pedoman praktis, bukan hukum matematis mutlak. Logikanya begini, karena kebanyakan masalah usabilitas bersifat umum, peserta kedua dan ketiga biasanya akan menabrak masalah yang sama dengan peserta pertama, sehingga informasi baru yang didapat semakin berkurang meski Anda menambah jumlah peserta. Ini sangat relevan bagi tim rintisan atau UMKM digital di Indonesia yang tidak punya anggaran riset besar seperti perusahaan multinasional — dengan lima orang peserta yang representatif dan skenario tugas yang baik, tim kecil tetap bisa menangkap sebagian besar masalah krusial sebelum meluncurkan produk. Strategi yang lebih baik daripada menguji tiga puluh orang sekaligus adalah menguji lima orang, memperbaiki masalah yang ditemukan, lalu menguji lagi lima orang baru di putaran berikutnya — ini disebut pengujian iteratif dan jauh lebih efisien secara biaya dan waktu.

BAGIAN 3 DARI 3

Mengukur Usabilitas & Mengambil Keputusan

"Mudah dipakai" bukan sekadar perasaan — ada metrik yang bisa dihitung dari nol, lalu diterjemahkan menjadi rekomendasi perbaikan konkret bagi tim produk.

Blok terakhir ini adalah inti kuantitatif sekaligus penutup praktis dari pertemuan hari ini, jadi siapkan diri Anda untuk dua latihan hitung dari nol yang akan menguji pemahaman Anda secara langkah demi langkah, sebelum kita bahas cara menerjemahkan hasilnya menjadi keputusan. Sejauh ini kita sudah bicara soal merancang pengujian secara kualitatif, tapi sebagai calon pengambil keputusan bisnis, Anda perlu angka konkret untuk membandingkan misalnya apakah desain versi A lebih mudah dipakai daripada versi B, atau apakah skor usabilitas aplikasi Anda membaik dari kuartal lalu. Dua metrik yang akan kita hitung adalah Success Rate atau tingkat keberhasilan tugas, dan System Usability Scale atau SUS, sebuah kuesioner baku sepuluh pertanyaan yang hasilnya bisa dikonversi menjadi satu skor tunggal dari nol sampai seratus. Setelah angka-angka itu didapat, kita akan belajar memprioritaskan temuan berdasarkan tingkat keparahan dan menulis rekomendasi yang benar-benar bisa dikerjakan tim teknis, sebelum ditutup dengan latihan kelompok dan pratinjau minggu depan.

Hitung dari Nol #1: Success Rate

Skenario: 12 peserta diuji mencoba menyelesaikan tugas "cari & beli sepatu ukuran 42". 9 peserta berhasil menyelesaikan tanpa bantuan.

Langkah	Perhitungan	Nilai
1. Jumlah peserta berhasil	diberikan dari data pengujian	9 orang
2. Jumlah total peserta	diberikan dari data pengujian	12 orang
3. Rasio keberhasilan	9 ÷ 12	0,75
4. Ubah ke persen	0,75 × 100	75%

SUCCESS RATE

75%

dari 12 peserta uji

Mari kita hitung bersama, ambil kalkulator atau catatan Anda dan ikuti setiap langkah karena ini akan sering muncul dalam laporan riset pengguna di dunia kerja. Kita mulai dari data mentah, dua belas peserta mencoba tugas mencari dan membeli sepatu ukuran 42, dan dari dua belas orang itu, sembilan berhasil menyelesaikan tugasnya sendiri tanpa dibantu fasilitator. Langkah perhitungannya sederhana, bagi jumlah yang berhasil dengan jumlah total peserta, sembilan dibagi dua belas menghasilkan 0,75, lalu kalikan dengan seratus untuk mengubahnya menjadi persentase yang lebih mudah dibaca, hasilnya 75 persen. Angka 75 persen ini artinya tiga dari empat pengguna bisa menyelesaikan tugas sendiri, sementara satu dari empat mengalami kesulitan — sebagai product manager, angka di bawah 70-80 persen biasanya jadi sinyal bahwa ada masalah desain yang perlu diperbaiki sebelum fitur dirilis ke publik, misalnya seperti yang mungkin terjadi pada fitur checkout di aplikasi belanja lokal yang belum matang uji cobanya.

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

SUS terdiri dari 10 pernyataan berskala 1–5. Contoh 2 pernyataan (skor 1 peserta):

Langkah	Perhitungan	Nilai
1. Pernyataan ganjil (positif): skor mentah − 1	Item 1 diberi skor 4 → 4 − 1	3
2. Pernyataan genap (negatif): 5 − skor mentah	Item 2 diberi skor 2 → 5 − 2	3
3. Jumlahkan seluruh 10 item yang sudah dikonversi	contoh total 10 item	27
4. Kalikan total dengan 2,5	27 × 2,5	67,5

SKOR SUS

67,5

skala 0–100 · "di atas rata-rata"

Skor SUS ini sedikit lebih rumit daripada Success Rate karena melibatkan pembalikan skala, jadi mari kita pelan-pelan. Kuesioner SUS berisi sepuluh pernyataan yang berselang-seling nada positif dan negatif, misalnya pernyataan ganjil biasanya berbunyi positif seperti "Saya pikir akan sering menggunakan aplikasi ini" sedangkan pernyataan genap berbunyi negatif seperti "Saya merasa aplikasi ini terlalu rumit". Untuk pernyataan positif atau nomor ganjil, kita kurangi skor mentahnya dengan 1; untuk pernyataan negatif atau nomor genap, kita kurangi angka 5 dengan skor mentahnya — pembalikan ini penting supaya semua item searah, dengan angka yang lebih tinggi selalu berarti lebih baik. Setelah semua sepuluh item dikonversi dengan cara ini, jumlahkan semuanya, lalu kalikan dengan 2,5 untuk mendapatkan skor akhir dalam skala 0 sampai 100, dalam contoh kita hasilnya 67,5. Sebagai patokan kasar yang umum dipakai industri, skor SUS di atas 68 dianggap di atas rata-rata, jadi 67,5 ini nyaris pas di ambang tersebut dan mengindikasikan produk sudah cukup baik namun masih ada ruang perbaikan.

Coba Sendiri: Hitung Skor SUS Produk Anda

Masukkan skor 10 pernyataan SUS dari seorang responden, lalu amati bagaimana skor akhirnya dihitung dalam skala 0-100.

Membaca Skor SUS: Skala Interpretasi

Rentang Skor SUS	Interpretasi	Tindakan Tim Produk
< 51	Buruk (poor)	Revisi besar diperlukan sebelum lanjut
51 – 67	Di bawah rata-rata (ok)	Perbaikan bertarget di titik masalah
68 – 80	Di atas rata-rata (good)	Layak lanjut, tetap iterasi kecil
> 80	Sangat baik (excellent)	Siap skala lebih luas

Angka batas ini merupakan konvensi umum dari penelitian usabilitas industri (Bangor, Kortum & Miller) — gunakan sebagai panduan, bukan hukum mutlak; selalu bandingkan dengan skor produk sejenis sebagai konteks.

Tabel ini memberi Anda konteks untuk menafsirkan angka SUS yang baru saja kita hitung, karena angka 67,5 saja tidak berarti apa-apa tanpa skala pembanding semacam ini. Skor di bawah 51 biasanya jadi alarm merah bagi tim produk, artinya ada masalah usabilitas serius yang membuat sebagian besar pengguna kesulitan, dan tim harus mundur untuk merombak desainnya, bukan sekadar tambal sulam kecil. Skor di rentang 51 sampai 67 dianggap masih di bawah rata-rata pasar, artinya produk bisa dipakai tapi tim perlu mencari titik-titik gesekan spesifik dan memperbaikinya secara bertarget. Untuk konteks nyata, banyak aplikasi mapan seperti aplikasi mobile banking BCA atau Mandiri secara berkala mengukur skor SUS mereka dan menargetkan di atas 80 karena basis penggunanya sangat besar dan sensitif terhadap kerumitan. Ingat, angka-angka batas ini adalah konvensi hasil riset dari Bangor, Kortum, dan Miller yang banyak dipakai industri, bukan rumus fisika yang kaku — selalu bandingkan skor Anda dengan skor kompetitor sejenis untuk konteks yang lebih adil.

Memprioritaskan Temuan: Matriks Tingkat Keparahan

Tidak semua temuan uji usabilitas punya bobot yang sama, dan tim yang efektif selalu memprioritaskan mana yang harus dikerjakan lebih dulu memakai kerangka tingkat keparahan seperti ini. Masalah kritis berarti peserta benar-benar gagal menyelesaikan tugas inti sama sekali, misalnya tidak bisa menemukan tombol bayar di aplikasi e-commerce sehingga transaksi batal — ini harus diperbaiki sebelum produk dirilis apapun risikonya terhadap jadwal. Masalah mayor berarti peserta akhirnya berhasil tapi dengan perjuangan besar, banyak jeda ragu-ragu atau harus mencoba beberapa kali, ini biasanya masuk prioritas tinggi untuk sprint pengembangan berikutnya. Masalah minor sedikit mengganggu kelancaran namun tugas tetap selesai tanpa banyak kesulitan, sementara masalah kosmetik hanya soal selera visual seperti warna tombol yang kurang disukai peserta tapi tidak mengganggu fungsi sama sekali. Kerangka semacam ini membantu tim seperti di perusahaan ride-hailing atau e-commerce menentukan mana yang masuk sprint minggu ini versus mana yang bisa ditunda ke backlog jangka panjang.

Menulis Rekomendasi yang Actionable

REKOMENDASI LEMAH

"Halaman checkout membingungkan, tolong diperbaiki supaya lebih mudah dipakai."

Tidak jelas bagian mana, tidak jelas apa yang harus diubah tim teknis.

REKOMENDASI KUAT

"6 dari 9 peserta salah mengira tombol 'Lanjutkan' sebagai navigasi, bukan pembayaran. Ganti label jadi 'Bayar Sekarang' + tambah ringkasan harga di atas tombol."

Spesifik: bukti data, lokasi pasti, solusi konkret.

Perbedaan antara rekomendasi lemah dan kuat ini sering menentukan apakah temuan riset Anda benar-benar dikerjakan tim engineering atau hanya dibaca sekilas lalu diabaikan karena terlalu kabur. Rekomendasi lemah seperti "halaman checkout membingungkan" tidak memberi developer petunjuk apapun tentang harus mulai dari mana, sehingga sering berakhir di tumpukan backlog yang tidak pernah dikerjakan. Rekomendasi kuat menyertakan tiga elemen penting: bukti kuantitatif dari data pengujian seperti "6 dari 9 peserta", lokasi spesifik masalahnya yaitu label tombol "Lanjutkan", dan solusi konkret yang bisa langsung dieksekusi tim desain yaitu mengganti label dan menambah ringkasan harga. Bayangkan Anda menjadi UX researcher magang di perusahaan seperti Traveloka atau Tiket.com, laporan dengan format rekomendasi kuat semacam ini jauh lebih mudah diyakinkan ke product manager dan tim engineering karena mereka bisa langsung memasukkannya ke dalam rencana sprint pengembangan. Latihlah diri Anda menulis temuan selalu dengan pola: bukti data, lokasi tepat, solusi konkret — ini adalah keterampilan yang sangat dihargai di industri produk digital.

Latihan Kelompok: Rancang Skenario Uji

Bentuk kelompok 3–4 orang. Pilih satu aplikasi yang sering Anda pakai (mis. Shopee, Gojek, myBCA, Tokopedia).

TUGAS KELOMPOK (15 MENIT)

Pilih 1 fitur/alur untuk diuji (mis. "ubah alamat pengiriman")
Tulis 1 task scenario berbasis tujuan (bukan leading task)
Tentukan metrik keberhasilan yang akan diukur
Tentukan berapa peserta yang idealnya dibutuhkan

PRESENTASI SINGKAT

2 kelompok akan diminta membacakan task scenario mereka ke kelas — kelas lain menilai apakah skenarionya sudah "berbasis tujuan" atau masih "leading task".

Sekarang giliran Anda mempraktikkan langsung apa yang sudah dipelajari, jadi silakan berkumpul dengan tiga atau empat teman terdekat Anda dan pilih satu aplikasi yang biasa dipakai sehari-hari. Tugas kelompok ini meniru persis apa yang dilakukan tim riset produk sungguhan sebelum sesi pengujian dimulai — Anda harus memilih satu alur spesifik, misalnya mengubah alamat pengiriman di Shopee atau top-up saldo di aplikasi myBCA, lalu menulis skenario tugas yang berbasis tujuan tanpa membocorkan nama tombol atau menu. Ingat pelajaran tadi soal leading task, jadi pastikan skenario kelompok Anda mengharuskan peserta uji mencari jalannya sendiri, bukan sekadar mengikuti instruksi klik demi klik. Saya akan berkeliling membantu kelompok yang kesulitan, dan setelah lima belas menit, dua kelompok akan dipilih secara acak untuk membacakan hasil kerja mereka, lalu kelas akan menilai bersama apakah skenario itu sudah cukup baik atau masih perlu diperbaiki.

Kesalahan Umum yang Harus Dihindari

Kesalahan	Dampak	Cara Menghindari
Menguji ke tim internal sendiri	Bias — tim sudah tahu cara pakainya	Rekrut peserta dari luar tim/organisasi
Skenario menyebut nama tombol/menu	Data tidak mencerminkan kesulitan asli	Tulis skenario berbasis tujuan/goal
Mengarahkan peserta saat macet	Menutupi masalah usabilitas nyata	Biarkan peserta mencoba sendiri, catat saja
Hanya laporkan skor, tanpa konteks	Tim tidak tahu apa yang harus diperbaiki	Sertakan bukti kualitatif + rekomendasi konkret

Tabel ringkasan ini mengumpulkan jebakan-jebakan yang paling sering terjadi bahkan pada tim profesional, jadi jadikan ini semacam daftar periksa sebelum Anda melakukan uji usabilitas di dunia kerja nanti. Menguji ke tim internal sendiri, misalnya meminta rekan sesama developer mencoba aplikasi, hasilnya nyaris selalu bias karena mereka sudah tahu logika di balik desainnya sehingga tidak akan mengalami kebingungan seperti pengguna awam. Mengarahkan peserta saat mereka terlihat macet, misalnya dengan berkata "coba lihat ke pojok kanan atas", adalah godaan yang sangat manusiawi karena fasilitator ingin membantu, padahal justru tindakan ini menutupi masalah usabilitas yang seharusnya terungkap. Bayangkan seorang product manager di startup logistik yang buru-buru ingin melihat hasil positif, lalu tanpa sadar membantu peserta uji menemukan tombol yang mereka cari — data yang dihasilkan menjadi tidak valid dan bisa menyesatkan keputusan bisnis berikutnya. Selalu ingat, ketidaknyamanan melihat peserta kesulitan justru adalah momen paling berharga dalam sesi pengujian, karena di situlah masalah nyata terungkap.

Rangkuman & Tugas Menuju Pertemuan 14

Tahap	Output	Pertanyaan Kunci
1. Pilih fidelitas prototipe	Sketsa kertas / mid / high-fidelity	Seberapa matang idenya saat ini?
2. Rancang task scenario	Skenario berbasis tujuan	Apakah ini leading atau goal-based?
3. Jalankan sesi (5 peserta)	Data klik + rekaman think-aloud	Di mana peserta ragu/tersesat?
4. Hitung Success Rate & SUS	Angka 0–100%	Seberapa baik dibanding standar?
5. Prioritaskan & rekomendasikan	Daftar temuan bersev + solusi	Apa yang harus dikerjakan tim dulu?

Pertemuan 14: presentasi proyek akhir — wajib sertakan bukti Success Rate dari minimal 3 peserta uji nyata terhadap prototipe kelompok Anda.

Tabel rangkuman ini menyatukan seluruh perjalanan materi hari ini menjadi satu alur kerja yang runtut, dari ide mentah sampai keputusan produk yang siap dieksekusi tim, dan sekaligus menjadi jembatan menuju tugas akhir semester Anda. Perhatikan bagaimana setiap tahap menghasilkan output konkret yang menjadi bahan untuk tahap berikutnya — Anda tidak bisa menghitung Success Rate tanpa dulu menjalankan sesi pengujian, dan Anda tidak bisa menjalankan sesi pengujian tanpa dulu merancang task scenario yang baik. Pertemuan berikutnya adalah puncak semester, presentasi dan evaluasi proyek akhir kelompok, dan setiap kelompok diwajibkan menjalankan minimal satu sesi uji usabilitas mini terhadap prototipe mereka sebelum pertemuan itu, dengan minimal tiga peserta uji yang bukan anggota kelompok sendiri, lalu menghitung Success Rate seperti yang baru saja kita latih bersama. Bayangkan diri Anda sebagai konsultan produk digital yang dipanggil sebuah UMKM fashion online untuk membantu meningkatkan konversi penjualan mereka — alur lima tahap plus bukti pengujian ini persis yang akan Anda tawarkan sebagai metodologi kerja kepada klien, dan saya menantikan bukti nyata bahwa produk kelompok Anda benar-benar sudah diuji ke pengguna sungguhan.

📖 Baca juga: Sensitivity Scenario Analysis — penjelasan mendalam dan contoh numerik.