Program Studi Bisnis Digital • FEB UNDIP

Desain UI & UX

Pertemuan 13 — Pelaksanaan dan Analisis Usability Testing: Think Aloud Protocol

Dari test plan di atas kertas menjadi sesi pengujian sungguhan — memandu partisipan berpikir keras, mencatat temuan, lalu mengubahnya menjadi rekomendasi perbaikan desain.

RPS MINGGU 14 • 2×50 MENIT

Bagian 1 dari 3

Melaksanakan Sesi Think-Aloud

Memandu partisipan berpikir keras tanpa mengarahkan jawabannya.

Apa Itu Think-Aloud Protocol?

Think-aloud protocol (protokol berpikir keras) adalah teknik meminta partisipan mengucapkan pikirannya secara verbal saat mencoba menyelesaikan tugas — apa yang dilihat, dicari, diharapkan, dan dirasakan bingung.

Asal Teknik

Dikembangkan psikolog Ericsson & Simon (1980-an)
Awalnya untuk meneliti proses berpikir manusia
Diadopsi UX untuk mengungkap proses mencari & memutuskan

Kenapa Efektif

Mengungkap alasan di balik klik, bukan cuma hasilnya
Menemukan kebingungan sebelum jadi kesalahan fatal
Data langsung dari kata-kata partisipan, bukan tebakan tim

Bayangkan Anda menonton rekaman layar seseorang mencoba aplikasi tanpa suara — Anda hanya tahu dia klik sini lalu sana, tapi tidak tahu KENAPA, apakah dia bingung, ragu, atau memang yakin. Protokol think-aloud menutup celah itu dengan meminta partisipan bersuara terus-menerus, misalnya "saya cari tombol bayar, tapi saya lihat dulu menu ini karena kelihatannya paling besar". Teknik ini aslinya dikembangkan oleh psikolog Ericsson dan Simon untuk meneliti proses berpikir manusia dalam memecahkan soal matematika, lalu diadopsi dunia UX karena sama-sama ingin mengungkap proses kognitif di balik sebuah tindakan. Contoh nyata, saat Traveloka menguji fitur pemilihan kursi pesawat baru, mereka menemukan partisipan mengucapkan "saya kira ini kursi gratis" pada ikon yang sebenarnya berbayar — temuan yang tidak akan pernah muncul kalau partisipan diam saja.

Tiga Peran dalam Satu Sesi Pengujian

Sesi usability testing yang rapi membagi tugas ke beberapa orang — jangan satu orang merangkap semuanya kalau tim memungkinkan.

Moderator

Pemandu Sesi

Membacakan tugas, mengajak partisipan berbicara, menjaga sesi tetap netral.

Note-taker

Pencatat

Mencatat waktu, kesalahan, dan kutipan verbatim (kata-kata persis) partisipan.

Observer

Pengamat

Anggota tim/klien yang menyimak dari belakang layar tanpa ikut bicara.

Kalau kelompok Anda beranggotakan tiga sampai lima orang, bagilah peran ini dengan jelas sebelum sesi dimulai, supaya satu orang tidak kewalahan menjalankan sesi sambil mencatat sekaligus. Moderator adalah satu-satunya yang berbicara langsung dengan partisipan — perannya seperti pramugari yang tenang dan netral, tidak menghakimi apa pun yang dilakukan partisipan. Note-taker duduk di sisi lain mencatat kutipan verbatim, artinya kata-kata persis yang diucapkan partisipan tanpa diparafrase, karena kalimat asli sering mengandung nuansa penting yang hilang kalau ditulis ulang dengan kata sendiri. Observer, biasanya anggota tim desain atau bahkan klien seperti pemilik UMKM yang produknya sedang diuji, cukup menyimak dari kursi belakang atau layar terpisah tanpa ikut berkomentar supaya tidak mengganggu konsentrasi partisipan.

Checklist Sebelum Sesi Dimulai

Persiapan Teknis

Prototipe sudah diuji-coba sendiri (tidak error)
Perekam layar & suara aktif dan teruji
Skenario tugas & skrip moderator dicetak/disiapkan
Ruang tenang, minim gangguan

Persiapan Etik

Formulir persetujuan (informed consent) ditandatangani
Partisipan tahu ia boleh berhenti kapan saja
Jelaskan: yang diuji adalah desain, bukan partisipan
Data direkam hanya untuk keperluan riset kelas

Slide ini adalah daftar periksa, jadi silakan Anda catat atau foto sebagai panduan langsung sebelum kelompok Anda menjalankan sesi pengujian minggu ini. Dari sisi teknis, hal paling memalukan yang bisa terjadi adalah moderator baru sadar prototipe error di tengah sesi karena belum dicoba sendiri terlebih dahulu — selalu lakukan dry run, uji coba mandiri, sehari sebelumnya. Dari sisi etik, formulir persetujuan atau informed consent wajib ditandatangani partisipan, isinya menjelaskan bahwa sesi akan direkam, data hanya dipakai untuk keperluan riset kelas, dan partisipan boleh berhenti kapan saja tanpa alasan. Poin yang sering terlupa: sampaikan eksplisit kepada partisipan bahwa "yang kami uji adalah desainnya, bukan kemampuan Anda" — kalimat sederhana ini terbukti mengurangi rasa cemas partisipan secara signifikan, seperti yang dipraktikkan tim riset Bukalapak sebelum sesi pengujian mereka.

Skrip Pembuka Sesi — Langkah demi Langkah

Urutan pembuka yang konsisten membuat setiap partisipan mendapat pengalaman yang setara (adil secara metodologis).

Langkah	Isi Pembicaraan Moderator
1. Sambutan & ucapan Terima Kasih	"Terima Kasih sudah meluangkan waktu untuk membantu kami hari ini."
2. Jelaskan tujuan & yang diuji	"Kami menguji desain aplikasi ini, bukan menguji Anda — tidak ada jawaban salah."
3. Ajarkan cara berpikir keras	"Silakan ucapkan apa pun yang Anda pikirkan, lihat, atau cari — sekecil apa pun."
4. Latihan singkat (warm-up)	Beri satu tugas contoh sederhana yang tidak terkait produk yang diuji.
5. Mulai tugas sesungguhnya	Bacakan skenario tugas pertama persis seperti tertulis di test plan.

Skrip pembuka ini bukan sekadar basa-basi — konsistensi urutannya menjaga agar setiap partisipan diperlakukan setara, sehingga perbandingan hasil antar-partisipan tetap adil secara metodologis. Langkah ketiga sering diabaikan pemula: banyak partisipan awam tidak terbiasa berpikir keras sambil bekerja, jadi moderator perlu memberi contoh singkat, misalnya "coba pikirkan keras sambil membuka kalkulator di ponsel Anda sekarang". Langkah keempat, latihan pemanasan dengan tugas yang tidak berkaitan dengan produk yang diuji — misalnya minta partisipan mencari resep di Google sambil bersuara — membantu mereka terbiasa sebelum masuk ke tugas sesungguhnya yang datanya akan kita pakai. Setelah warm-up ini, barulah moderator membacakan skenario tugas pertama dari test plan persis seperti yang tertulis, tanpa improvisasi kata-kata yang bisa mengubah makna instruksi.

Teknik Bertanya (Probing): Netral vs Menuntun

Probing adalah pertanyaan lanjutan moderator saat partisipan diam terlalu lama atau terlihat bingung — kalimatnya harus netral, tidak mengarahkan jawaban.

Netral (Boleh)

"Apa yang sedang Anda pikirkan sekarang?"
"Apa yang Anda harapkan terjadi jika klik itu?"
"Ceritakan apa yang Anda cari."

Menuntun (Hindari)

"Apakah tombol hijau itu yang Anda maksud?"
"Coba klik menu di kanan atas."
"Bukankah ini lebih mudah dari aplikasi lain?"

Probing yang baik membuka ruang bagi partisipan untuk bercerita dengan kata-katanya sendiri, sementara probing yang buruk secara tidak sengaja memberi tahu jawabannya — begitu moderator menyebut lokasi atau warna tombol, data tentang "apakah tombol itu mudah ditemukan" jadi tidak valid lagi. Kesalahan ini sangat mudah terjadi karena naluri manusia ingin menolong orang yang terlihat kebingungan, jadi moderator perlu latihan sadar untuk menahan diri. Sebagai gambaran, saat menguji aplikasi OVO, kalau partisipan diam lama mencari tombol top-up, moderator yang baik bertanya "apa yang sedang Anda cari sekarang?", bukan "coba lihat pojok kanan bawah". Aturan praktisnya: kalau pertanyaan Anda mengandung nama tombol, warna, atau posisi elemen antarmuka, itu tandanya pertanyaan tersebut sudah menuntun dan sebaiknya diganti dengan pertanyaan terbuka.

Kesalahan Umum Saat Memoderasi

Membantu partisipan yang kesulitan — refleks berkata "coba klik yang itu" menghancurkan validitas seluruh data sesi tersebut.

Diam terlalu lama tanpa probing — partisipan merasa canggung dan berhenti bersuara, padahal data verbal itulah intinya.

Bereaksi terhadap kesalahan partisipan — ekspresi wajah kaget atau tertawa membuat partisipan merasa dinilai, bukan desainnya.

Solusi: latihan peran (role-play) dengan teman sekelompok sebelum sesi asli — moderator baru sering butuh 1–2 sesi latihan.

Ketiga kesalahan ini adalah yang paling sering dilakukan moderator pemula, dan uniknya semuanya berasal dari niat baik — ingin menolong, memberi ruang tenang, atau menunjukkan empati — tapi justru merusak data yang sedang dikumpulkan. Contoh nyata, dalam simulasi pengujian aplikasi kampus, seorang moderator pemula tanpa sadar berkata "oh sepertinya bukan di situ ya" saat partisipan salah klik, padahal komentar itu sudah cukup membuat partisipan tahu bahwa pilihannya salah sebelum ia menyimpulkannya sendiri. Solusi paling efektif dan murah adalah latihan peran, di mana satu anggota kelompok berperan sebagai partisipan pura-pura bingung, dan calon moderator berlatih menahan diri untuk tidak membantu sambil tetap terdengar ramah. Sebelum sesi pengujian sungguhan minggu ini, sangat disarankan setiap kelompok melakukan minimal satu kali latihan peran seperti ini agar moderator lebih percaya diri dan konsisten.

Bagian 2 dari 3

Menangkap & Mengorganisasi Data

Dari rekaman mentah menjadi catatan temuan yang bisa dianalisis.

Apa yang Dicatat Selama Sesi?

Catatan yang baik memisahkan fakta yang diamati dari tafsiran/opini — tafsiran menyusul saat analisis, bukan saat mencatat.

Dicatat Saat Sesi (Fakta)

Kutipan verbatim (kata persis partisipan)
Waktu mulai/selesai tiap tugas
Klik salah / kembali ke halaman sebelumnya
Ekspresi & bahasa tubuh (mengernyit, ragu)

Ditunda ke Tahap Analisis

"Menurut saya tombolnya jelek" (opini pribadi)
Kesimpulan penyebab masalah
Usulan solusi perbaikan

Prinsip paling penting di slide ini adalah memisahkan fakta dari tafsiran — saat sesi berlangsung, note-taker hanya boleh mencatat apa yang benar-benar terjadi dan terucap, bukan kesimpulan atau solusi yang terlintas di kepala. Misalnya, catatan yang benar adalah "partisipan klik ikon keranjang tiga kali, berkata 'kok tidak bertambah ya', lalu mengernyitkan dahi", bukan "tombol keranjangnya jelek dan harus diganti warna". Kalau note-taker langsung menyimpulkan solusi di tengah sesi, ada risiko dua orang berbeda menyimpulkan hal berbeda dari fakta yang sama, dan kita kehilangan jejak data mentahnya. Contoh nyata dari pengujian aplikasi Ruangguru, tim mencatat verbatim "saya kira video ini gratis" pada satu fitur berbayar — kutipan persis inilah yang nantinya jadi bukti kuat saat mempresentasikan temuan ke tim produk, jauh lebih meyakinkan daripada sekadar opini "labelnya membingungkan".

Hitung dari Nol #1 — Severity Rating Gabungan

Skala Nielsen Severity Rating (0–4): 0=bukan masalah, 1=kosmetik, 2=minor, 3=major, 4=catastrophe. Temuan "tombol checkout tersembunyi" dinilai oleh 3 observer secara independen.

Langkah	Perhitungan	Nilai
1. Rating Observer A	Diberikan dari lembar observasi	3
2. Rating Observer B	Diberikan dari lembar observasi	4
3. Rating Observer C	Diberikan dari lembar observasi	2
4. Severity gabungan (rata-rata)	(3 + 4 + 2) ÷ 3	3,0

Severity Gabungan

3,0

Kategori: Major (skala 0–4)

Karena penilaian severity bersifat subjektif, praktik terbaik adalah meminta beberapa observer menilai temuan yang sama secara independen, lalu merata-ratakannya untuk mengurangi bias satu orang. Pada contoh ini, tiga observer memberi nilai 3, 4, dan 2 untuk masalah yang sama, kita jumlahkan menjadi 9 lalu bagi 3 orang, hasilnya severity gabungan 3,0. Skala Nielsen sendiri berjenjang dari 0 yang berarti bukan masalah sama sekali, 1 kosmetik atau sekadar tidak rapi, 2 minor yang mudah diatasi partisipan sendiri, 3 major yang menghambat penyelesaian tugas, sampai 4 catastrophe yang membuat tugas gagal total. Skor 3,0 di contoh kita masuk kategori major, artinya masalah "tombol checkout tersembunyi" ini cukup serius dan sebaiknya menjadi prioritas tinggi untuk diperbaiki sebelum aplikasi dirilis, mirip temuan nyata yang pernah dilaporkan pengguna pada versi awal aplikasi PeduliLindungi.

Dari Catatan Mentah ke Affinity Diagram

Affinity diagram (diagram afinitas) adalah cara mengelompokkan temuan-temuan serupa dari berbagai sesi menjadi tema besar — dikerjakan bertahap seperti ini:

Tahap	Yang Dilakukan Tim
1. Tulis tiap temuan di kartu terpisah	Satu temuan = satu kartu (fisik/digital), dari SEMUA sesi & observer.
2. Sebar semua kartu di satu papan	Tanpa dikelompokkan dulu — lihat gambaran besarnya.
3. Kelompokkan kartu yang mirip	Diskusi tim: "ini soal navigasi", "ini soal label tombol", dst.
4. Beri nama tiap kelompok (tema)	Mis. "Navigasi Membingungkan" (7 kartu dari 4 partisipan berbeda).

Setelah lima sesi pengujian selesai, Anda mungkin punya 30 sampai 50 temuan kecil yang tersebar di berbagai catatan — affinity diagram adalah cara sistematis untuk mengubah kekacauan ini menjadi pola yang bermakna. Caranya, tiap temuan individual ditulis di satu kartu terpisah, baik memakai sticky note fisik di papan tulis atau kartu digital di Miro/FigJam, lalu seluruh kartu disebar tanpa pengelompokan dulu supaya tim melihat gambaran besarnya. Tahap berikutnya adalah diskusi kelompok mengelompokkan kartu-kartu yang punya kemiripan tema, misalnya beberapa kartu tentang "partisipan tidak menemukan tombol filter" dan "partisipan salah paham ikon pencarian" bisa digabung jadi tema "Navigasi Membingungkan". Kekuatan teknik ini adalah kalau satu tema muncul dari beberapa partisipan berbeda, misalnya 7 kartu dari 4 partisipan, itu sinyal kuat bahwa masalahnya bukan kebetulan satu orang, melainkan pola desain yang perlu diperbaiki secara sistemik — persis seperti proses yang dilakukan tim UX Traveloka saat merapikan temuan dari uji multi-sesi mereka.

Menulis Temuan: Buruk vs Baik

Temuan Buruk (Kabur)

"Tombolnya jelek."
"UX-nya membingungkan."
"Ada masalah di halaman checkout."

Temuan Baik (Spesifik & Berbukti)

3 dari 5 partisipan tidak menemukan tombol "Bayar Sekarang" dalam 15 detik pertama.
Kutipan: "saya kira ini cuma banner iklan"
Severity: 3 (major) — menghambat penyelesaian tugas

Temuan yang ditulis kabur seperti "tombolnya jelek" tidak berguna bagi tim desain karena tidak jelas apa yang harus diperbaiki, berapa banyak orang yang terdampak, atau seberapa serius masalahnya. Temuan yang baik selalu menyertakan angka konkret — berapa dari berapa partisipan yang mengalami masalah ini — ditambah kutipan verbatim sebagai bukti, dan skor severity yang sudah kita hitung di slide sebelumnya. Pola penulisan yang direkomendasikan adalah: [jumlah partisipan] mengalami [masalah spesifik] saat [konteks tugas], dibuktikan dengan [kutipan], tingkat keparahan [skor]. Kebiasaan menulis temuan seperti ini akan sangat membantu kelompok Anda saat menyusun laporan akhir proyek, karena tim desain atau dosen penguji bisa langsung memahami urgensi setiap masalah tanpa harus menonton ulang rekaman video.

Bagian 3 dari 3

Menganalisis & Memprioritaskan Temuan

Mengubah daftar masalah menjadi rekomendasi perbaikan yang bisa dikerjakan tim.

Bagian terakhir ini menjawab pertanyaan paling praktis: setelah punya belasan temuan yang sudah dikelompokkan dan diberi skor severity, mana yang harus diperbaiki dulu? Tim desain di dunia nyata selalu punya keterbatasan waktu dan sumber daya, jadi kemampuan memprioritaskan berdasarkan data, bukan berdasarkan siapa yang paling vokal di rapat, adalah keterampilan yang sangat dihargai industri. Kita akan belajar matriks prioritas yang menggabungkan seberapa parah masalahnya dengan seberapa sering ditemui, menghitung skor prioritas gabungan, lalu menerjemahkan temuan tertinggi menjadi rekomendasi perbaikan yang konkret dan bisa langsung dikerjakan. Bagian ini adalah puncak dari seluruh proses usability testing yang kita pelajari sejak dua pertemuan lalu — dari perencanaan sampai rekomendasi akhir.

Matriks Prioritas: Severity × Frequency

Masalah yang parah dan sering ditemui harus diperbaiki lebih dulu daripada yang parah tapi jarang, atau ringan meski sering.

Matriks dua sumbu ini membantu tim melihat sekilas mana temuan yang paling mendesak: sumbu vertikal adalah severity atau tingkat keparahan yang sudah kita hitung, sumbu horizontal adalah frequency atau seberapa sering masalah itu ditemui di antara partisipan yang diuji. Kuadran kanan atas, parah dan sering, adalah prioritas utama yang harus dikerjakan lebih dulu karena berdampak besar ke banyak pengguna sekaligus. Kuadran kiri atas, parah tapi jarang, tetap perlu ditangani tapi bisa menunggu giliran kedua, sementara kuadran kanan bawah, ringan tapi sering, kadang tetap penting kalau frekuensinya sangat tinggi meski dampaknya kecil. Sebagai contoh nyata, tim Shopee pernah menemukan bug ringan pada ikon keranjang yang dialami hampir semua partisipan uji — meski severity-nya rendah, frekuensinya yang sangat tinggi membuat perbaikan itu tetap dinaikkan prioritasnya.

Hitung dari Nol #2 — Skor Prioritas Gabungan

Priority Score = Severity × Frequency (proporsi partisipan yang mengalami masalah). Temuan "tombol checkout tersembunyi" dari slide sebelumnya (severity 3,0) dialami 6 dari 8 partisipan.

Langkah	Perhitungan	Nilai
1. Severity gabungan (hasil hitung sebelumnya)	Diberikan	3,0
2. Partisipan yang mengalami masalah ini	Diberikan dari observation log	6 dari 8
3. Frequency (proporsi)	6 ÷ 8	0,75
4. Priority Score	3,0 × 0,75	2,25

Priority Score

2,25

~ Prioritas tinggi (skala 0–4)

Skor prioritas menggabungkan dua angka yang sudah kita hitung sebelumnya: severity gabungan 3,0 dari penilaian tiga observer, dan frequency yaitu proporsi partisipan yang mengalami masalah yang sama, dalam kasus ini 6 dari 8 partisipan. Kita hitung frequency dengan membagi 6 dengan 8 sama dengan 0,75, lalu kalikan dengan severity 3,0 untuk mendapatkan priority score 2,25. Perlu Anda catat, ambang batas "prioritas tinggi" di sini bersifat ilustratif untuk latihan kelas, bukan standar baku industri tunggal — di lapangan, tim biasanya menetapkan ambang sendiri berdasarkan kapasitas perbaikan yang tersedia. Yang terpenting bukan angka presisinya, melainkan bahwa skor ini memberi dasar objektif untuk berdebat tentang urutan perbaikan, alih-alih hanya mengandalkan pendapat anggota tim yang paling vokal di rapat — mirip cara tim produk Halodoc menentukan urutan perbaikan bug dari hasil pengujian mereka.

Coba Sendiri: Hitung Skor Prioritas Temuan Anda

Ubah severity dan proporsi partisipan yang mengalami masalah, lalu amati bagaimana priority score bergeser.

Dari Temuan ke Rekomendasi Actionable

Rekomendasi yang baik menjawab apa yang harus diubah, bukan sekadar mengulang masalahnya.

Temuan

6 dari 8 partisipan tidak menemukan tombol "Bayar Sekarang" dalam 15 detik pertama; beberapa mengira itu banner iklan. Priority Score: 2,25.

Rekomendasi

Ubah warna tombol jadi kontras tinggi dari latar
Hindari bentuk mirip banner iklan (hilangkan gambar dekoratif di sekitarnya)
Tambah label teks jelas "Bayar Sekarang", bukan hanya ikon

Perhatikan bahwa rekomendasi di sini bukan sekadar mengulang kalimat "tombolnya susah ditemukan", melainkan langkah konkret yang bisa langsung dikerjakan tim desain, seperti mengubah kontras warna atau menambah label teks. Menyusun rekomendasi seperti ini butuh kembali ke akar penyebab masalah — dalam kasus ini, partisipan mengira tombol itu banner iklan, jadi solusinya bukan sekadar memperbesar tombol, tapi menghilangkan kemiripan visualnya dengan iklan yang biasa diabaikan pengguna. Kebiasaan mengabaikan elemen yang terlihat seperti iklan ini disebut banner blindness, kebutaan-banner, sebuah fenomena yang sudah lama diteliti dalam dunia UX dan sering menjebak desainer yang tidak menyadarinya. Sebagai perbandingan, aplikasi seperti Blibli sengaja membuat tombol checkout dengan warna solid mencolok dan bentuk kotak tegas, sangat berbeda dari banner promosi yang biasanya berbentuk gambar besar dengan teks tumpang tindih.

Contoh Laporan Temuan Ringkas

Format Laporan yang Direkomendasikan

Temuan	Severity	Frequency	Priority	Rekomendasi
Tombol bayar tak ditemukan	3,0	6/8	2,25	Ubah warna & label
Ikon filter membingungkan	2,0	3/8	0,75	Tambah teks di ikon
Notifikasi sukses terlalu cepat hilang	1,0	5/8	0,63	Perpanjang durasi tampil

Urutkan baris laporan dari Priority Score tertinggi ke terendah — itulah urutan pengerjaan yang direkomendasikan ke tim desain.

Tabel ini adalah contoh format laporan ringkas yang bisa langsung Anda pakai untuk proyek akhir kelompok — setiap baris mewakili satu temuan dengan severity, frequency, priority score, dan rekomendasinya masing-masing. Perhatikan temuan pertama, tombol bayar yang tidak ditemukan, punya priority score tertinggi 2,25 sehingga ditempatkan di urutan teratas laporan sebagai yang paling mendesak untuk diperbaiki. Temuan ketiga, notifikasi sukses yang cepat hilang, punya severity rendah karena tidak menggagalkan tugas, tapi frekuensinya cukup tinggi karena hampir semua partisipan sempat melewatkannya. Format laporan seperti ini yang dipakai secara luas di industri, termasuk tim UX di perusahaan seperti Mekari, karena memudahkan product manager mengambil keputusan cepat tentang apa yang dikerjakan sprint berikutnya tanpa harus membaca laporan naratif panjang.

Latihan Kelompok — Analisis Temuan Sesi

Instruksi: gunakan rekaman/catatan sesi pengujian kelompok Anda minggu ini (atau data simulasi dari dosen bila belum sempat menguji).

Langkah Kerja (20 menit)

1. Tulis minimal 5 temuan di kartu terpisah
2. Kelompokkan ke 2–3 tema (affinity diagram)
3. Beri severity rating tiap temuan (skala 0–4)
4. Hitung priority score temuan tertinggi

Output Latihan

Tabel Laporan

Satu tabel format seperti slide sebelumnya, diurutkan dari priority score tertinggi, siap dipresentasikan singkat ke kelas.

Sekarang giliran kelompok Anda mempraktikkan langsung apa yang baru saja kita pelajari — kalau kelompok Anda sudah sempat melaksanakan sesi pengujian minggu ini, gunakan data sungguhan; kalau belum, saya akan bagikan lembar data simulasi untuk latihan hari ini. Mulai dengan menuliskan temuan-temuan individual di kartu terpisah, lalu diskusikan bersama untuk mengelompokkannya menjadi dua atau tiga tema besar seperti yang kita praktikkan pada affinity diagram tadi. Setelah itu, beri skor severity untuk temuan-temuan utama, hitung priority score-nya, dan susun dalam tabel laporan seperti contoh yang baru kita bahas. Saya akan berkeliling membantu kelompok yang kesulitan, dan di akhir sesi kita akan minta dua atau tiga kelompok mempresentasikan temuan tertinggi mereka secara singkat ke seluruh kelas.

Rangkuman & Menuju Pertemuan 14

Cheat Sheet Hari Ini

Konsep	Inti
Think-aloud	Partisipan bersuara terus saat mencoba
Probing netral	Tanya apa yang dipikirkan, bukan arahkan
Severity Rating	Rata-rata skor observer, skala 0–4
Priority Score	Severity × Frequency
Affinity diagram	Kelompokkan temuan jadi tema

Tugas Sebelum Pertemuan 14

Laporan Temuan

Kelompok menyelesaikan tabel laporan temuan lengkap (severity, frequency, priority, rekomendasi) dari sesi pengujian, sebagai dasar iterasi desain minggu depan.

Mari kita rangkum: hari ini Anda belajar memoderasi sesi think-aloud dengan probing yang netral, mencatat fakta terpisah dari tafsiran, menghitung severity rating dan priority score untuk memprioritaskan temuan, serta mengelompokkan temuan lewat affinity diagram menjadi tema besar. Anda juga sudah melihat contoh format laporan temuan yang ringkas dan actionable, jauh lebih berguna bagi tim desain daripada sekadar daftar keluhan tanpa data pendukung. Minggu depan di Pertemuan 14, kita akan menggunakan laporan temuan yang kelompok Anda susun hari ini sebagai dasar untuk melakukan iterasi desain — memperbaiki prototipe berdasarkan bukti nyata dari pengguna, sekaligus mempersiapkan presentasi proyek akhir. Pastikan sebelum pertemuan berikutnya, kelompok Anda sudah menyelesaikan tabel laporan temuan lengkap dari sesi pengujian minggu ini — selamat mengerjakan, dan sampai jumpa di sesi iterasi desain.