Usability Testing Adalah: Panduan Uji Alur Bank sebelum Go-Live

Usability testing adalah pengujian di mana orang yang mewakili target konsumen mencoba menyelesaikan tugas nyata di sebuah aplikasi atau website, sementara tim mencatat di mana mereka gagal, ragu, atau salah paham. Bagi bank, asuransi, sekuritas, dan multifinance, catatan itu lebih dari daftar perbaikan desain: menurut bacaan kami, ia bisa menjadi bagian dari dokumentasi pengujian produk baru yang diwajibkan POJK 22/2023 Pasal 26 ayat (4). Lima partisipan menemukan sekitar 85% masalah menurut model Nielsen, tetapi hanya untuk satu kelompok pengguna yang sebanding. Nasabah 60 tahun ke atas dan penyandang disabilitas perlu kelompok uji sendiri.

Definisi umum dan empat langkah dasarnya (tentukan tujuan dan skenario, rekrut partisipan, jalankan sesi, analisis temuan) sudah ada di mana-mana, termasuk di artikel kami tentang proses riset pengalaman pengguna. Saat kami menarik hasil Google untuk "usability testing" di Indonesia pada 16 Oktober 2026, AI Overview di puncaknya menyarankan merekrut 3 sampai 5 pengguna yang cocok dengan target audiens. Tidak ada sepatah kata pun soal nasabah lansia atau penyandang disabilitas. Artikel ini membahas yang tidak ada di sana: berapa partisipan, siapa saja, skor apa yang dianggap rata-rata, dan apa yang harus disimpan sebelum alur yang diawasi OJK naik ke produksi. Pembacanya CTO atau product lead yang menandatangani go-live, dengan compliance officer sebagai pembaca kedua bagian berkas bukti.

Mengapa hasil usability testing bisa masuk berkas bukti POJK 22

POJK 22/2023 tentang Pelindungan Konsumen dan Masyarakat di Sektor Jasa Keuangan ditetapkan 20 Desember 2023 dan berlaku sejak diundangkan pada 22 Desember 2023 (Pasal 125). Pasal 26 berisi empat kewajiban berurutan:

(1) PUJK wajib melakukan pengujian produk dan/atau layanan baru. … (4) PUJK wajib mendokumentasikan hasil pengujian sebagaimana dimaksud pada ayat (1).

Di antara keduanya, ayat (2) menyebut tujuan pengujian, yaitu menilai risiko yang berpotensi merugikan konsumen. Ayat (3) mewajibkan peninjauan ulang bila hasilnya menunjukkan potensi kerugian. Pelanggaran ayat (1), (3), atau (4) bisa berujung sanksi administratif, dari peringatan tertulis sampai pencabutan izin usaha, dengan denda paling banyak Rp15 miliar.

Penjelasan Pasal 26 memberi tim produk digital tiga pegangan:

• Apa yang dihitung "baru": produk yang ditawarkan pertama kali, atau pengembangan yang mengubah produk secara material, termasuk menjualnya ke target konsumen baru. Memindahkan pembukaan rekening ke aplikasi untuk segmen yang selama ini dilayani di cabang bisa masuk kategori ini.
• Cara menguji: "antara lain melalui survei, riset pemasaran, uji coba secara terbatas", atau sandbox.
• Aspek yang dinilai: tujuan produk, transparansi informasi, kesesuaian pemasaran dengan kebutuhan dan kemampuan target konsumen, dan kesesuaian perjanjian baku.

Ini bacaan kami, bukan pernyataan OJK. Pasal 26 tidak menyebut kata "usability" dan tidak menunjuk metode tertentu. Argumen kami: usability test dengan temuan tercatat adalah satu bentuk "uji coba secara terbatas", dan ia menguji langsung aspek transparansi informasi. Kalau nasabah tidak bisa menemukan biaya di layar ringkasan produk, itu temuan transparansi. Bukan soal selera desain. Penjelasan ayat (2) juga membatasi cakupannya: risiko yang melekat pada produk, seperti turunnya nilai investasi karena kondisi pasar, tidak termasuk. Pasal 27 mengecualikan produk untuk program pemerintah atau otoritas (Bank Indonesia dan OJK) dan produk Lembaga Keuangan Mikro.

Kewajiban layar lainnya di POJK 22, dari RIPLAY sampai jam layanan pengaduan, sudah kami uraikan di POJK perlindungan konsumen sebagai spesifikasi layar. Di sini cukup Pasal 26 dan 54.

Pilih metode berdasarkan risiko alurnya

Halaman-halaman yang meranking untuk istilah ini menyajikan jenis uji berpasangan, moderated atau unmoderated, remote atau tatap muka, tanpa aturan kapan memakai yang mana. Untuk alur yang diawasi, aturannya sederhana: makin mahal akibat salah paham bagi nasabah, makin perlu fasilitator yang bisa bertanya "tadi Anda pikir biaya ini untuk apa?". Tabel berikut rekomendasi kami, bukan ketentuan regulasi.

Kelompok lansia dan disabilitas sengaja hanya ditaruh di dua baris pertama. Di sanalah nasabah menyatakan setuju dan mengikatkan diri, dan di sana pula kesalahan paling sulit dibatalkan.

Yang bukan usability testing

Sebagian halaman di hasil pencarian memasukkan A/B testing, survei kepuasan, dan card sorting sebagai "metode usability testing", sebagian lagi tidak. Kami tidak memasukkannya. A/B test mengukur varian mana yang menang, tetapi tidak menjelaskan mengapa nasabah gagal. Survei mengukur pendapat, bukan perilaku. Card sorting menguji struktur menu sebelum layarnya ada. Ketiganya berguna, tetapi tidak satu pun memperlihatkan orang yang sedang mencoba menyelesaikan tugas.

User acceptance testing (UAT) juga lain, dan bedanya terasa saat tanda tangan. UAT membuktikan sistem sesuai spesifikasi, biasanya ditandatangani unit bisnis pemilik kebutuhan. Usability test membuktikan nasabah yang mewakili target konsumen bisa memakainya tanpa salah paham. Sebuah alur bisa lulus UAT 100% dan tetap membuat 3 dari 5 partisipan melewatkan biaya administrasi. Dua tanda tangan, dua pertanyaan.

Berapa partisipan: model Nielsen dan batasnya

Jakob Nielsen dan Thomas K. Landauer memodelkan penemuan masalah usability pada 1993 (Proc. ACM INTERCHI'93, hlm. 206–213). Nielsen meringkasnya dalam "Why You Only Need to Test with 5 Users" (18 Maret 2000): masalah yang ditemukan dengan n partisipan = N(1 − (1 − L)ⁿ), dengan L adalah porsi masalah yang ditemukan satu orang. Nilai L tipikal dari proyek-proyek yang ia pelajari 31%. Angka di bawah hasil hitungan kami dari rumus itu.

Ada dua hal dari artikel yang sama yang sering hilang saat angka "5" dikutip. Pertama, Nielsen menyarankan anggaran 15 partisipan dibagi menjadi 3 putaran berisi 5 orang, dengan perbaikan desain di antara putaran, bukan satu putaran 15 orang. Putaran kedua itulah yang menjadi bukti bahwa temuan sudah ditangani. Kedua, rumus itu hanya berlaku untuk pengguna yang sebanding. Untuk tiga kelompok atau lebih, ia menyarankan 3 orang per kelompok, dan jangan kurang dari 3 untuk kelompok mana pun.

Karena itu rencana yang kami sarankan untuk alur onboarding atau RIPLAY: 11 orang di putaran pertama (5 nasabah umum, 3 berusia 60 tahun ke atas, 3 penyandang disabilitas), lalu re-test dengan sedikitnya 5 orang setelah perbaikan. Menambah nasabah umum menjadi 11 tidak akan menemukan masalah yang hanya dialami pengguna pembaca layar atau mata berusia 70 tahun. Pendapat kami terus terang: satu putaran tanpa re-test belum bukti apa-apa. Itu baru daftar keluhan.

Mengapa kelompok 60+ dan disabilitas, dengan angka

Menurut hasil SUPAS 2025 BPS (BRS No. 51/05/Th. XXIX, 5 Mei 2026), penduduk lansia mencapai 11,97%, naik dari 9,93% pada 2020. Prevalensi penyandang disabilitas usia 5 tahun ke atas 2,17%, naik dari 1,43% pada Long Form SP2020; jenis tertinggi adalah kesulitan berjalan atau naik tangga (0,95%). BPS memakai batas lansia 60 tahun, sama persis dengan definisi "lanjut usia" di Penjelasan Pasal 54 POJK 22.

Pasal 54 ayat (3) menyatakan PUJK "mempunyai tanggung jawab untuk mendukung penyediaan layanan khusus" bagi penyandang disabilitas dan lanjut usia, dan Penjelasannya menyebut fitur aplikasi yang memperhatikan penyandang disabilitas sebagai salah satu dari tujuh contoh. Supaya tepat: ayat (3) tidak bersanksi (sanksi ayat (4) hanya menjangkau ayat (1) dan (2)), dan POJK 22 tidak menyebut standar teknis apa pun, termasuk WCAG. Jadi kelompok uji ini bukan kewajiban tertulis. Ia cara paling langsung untuk menunjukkan bahwa tanggung jawab itu dijalankan, dalam bentuk yang bisa dibuka saat pemeriksaan.

SUS: skor 68 itu rata-rata, bukan "baik"

System Usability Scale (SUS) dibuat John Brooke pada 1986: 10 pernyataan, masing-masing dengan 5 pilihan jawaban. Cara menghitungnya, menurut Jeff Sauro (MeasuringU, 3 Februari 2011): untuk butir ganjil kurangi jawaban dengan 1, untuk butir genap kurangi 5 dengan jawaban, jumlahkan, lalu kalikan 2,5. Hasilnya 0–100, dan rata-rata dari 500 studi adalah 68.

Skor SUS bukan persentase. Skor 68 berada di persentil ke-50, 75 di persentil ke-73, dan 52 di persentil ke-15. Tabel nilai di bawah memakai kurva Sauro–Lewis dari "5 Ways to Interpret a SUS Score" (19 September 2018), yang menggeser batas dibanding tabel 2011.

Pita yang beredar di hasil pencarian Indonesia, 85 ke atas, 70–84, dan 50–69, tidak cocok dengan sumber ini. Di pita itu skor 70 terdengar memuaskan; di tabel Sauro–Lewis 70 adalah C, sedikit di atas rata-rata. Dengan 11 partisipan, laporkan SUS per kelompok sebagai petunjuk arah, bukan ambang lulus. Bukti utamanya tetap kegagalan tugas dan salah paham yang tercatat.

Isi berkas bukti: apa yang disimpan

Tidak satu pun dari delapan halaman peringkat atas untuk "usability testing adalah" yang kami baca pada 16 Oktober 2026 menyebut apa yang harus disimpan setelah sesi uji. Untuk alur yang diawasi, ini berkas yang kami sarankan, disusun supaya auditor bisa membacanya tanpa perlu bertanya ke tim desain:

1. Rencana uji: alur dan versi build yang diuji, tujuan, tanggal, dan aspek Pasal 26 yang dinilai (misalnya transparansi informasi).
2. Kriteria rekrutmen dan log partisipan yang dianonimkan: kelompok, rentang usia, jenis disabilitas bila relevan, tanpa nama dan NIK.
3. Formulir persetujuan untuk partisipasi dan perekaman.
4. Skrip tugas dan pertanyaan pemahaman, kata demi kata.
5. Rekaman sesi beserta daftar siapa yang boleh mengaksesnya.
6. Temuan dengan tingkat keparahan, masing-masing dengan jumlah partisipan yang mengalaminya.
7. Log perbaikan: temuan mana yang diperbaiki, ditunda, atau diterima sebagai risiko, dan oleh siapa.
8. Hasil re-test pada build yang sudah diperbaiki.
9. Tanda tangan pemilik produk dan fungsi pelindungan konsumen.

POJK 22 tidak menetapkan masa simpan untuk dokumentasi pengujian. Tetapkan sendiri di kebijakan internal, dan catat dasarnya di berkas yang sama.

Data di layar uji

Rekaman layar, wajah, dan suara partisipan yang dapat dikenali adalah data pribadi menurut UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi. Jalankan sesi dengan akun uji dan data dummy atau data yang sudah dimasking, jangan pernah meminta partisipan mengetik NIK atau nomor rekening asli, dan minta persetujuan perekaman terpisah dari persetujuan ikut serta. Dasar pemrosesan dan penilaian dampaknya sudah kami bahas di DPIA Pasal 34 UU PDP untuk bank dan asuransi. Itu juga jawaban jujur untuk pertanyaan "apakah user testing aman?": aman, selama data asli tidak pernah muncul di layar.

Apa yang bisa kami tunjukkan, dan apa yang belum

Studi kasus CGS International mencatat tantangan "Kepatuhan Regulasi dan Kemudahan Akses": menjamin semua fitur platform mematuhi hukum dan pedoman keuangan tanpa mengorbankan fungsionalitas. Itu ketegangan yang sama dengan yang dibahas artikel ini. Studi kasus itu tidak menggambarkan usability test, jadi kami tidak mengklaimnya. Studi kasus Olaif, merek produk konsumen dan bukan lembaga keuangan, menyebut riset UX sebagai dasar desainnya. Protokol di atas disusun dari sumber publik yang kami tautkan, bukan dari temuan proyek lembaga keuangan yang bisa kami publikasikan.

Untuk CTO dan product lead: sebelum tanda tangan go-live

Ajukan lima pertanyaan ini ke tim, atau ke vendor, sebelum alur onboarding, RIPLAY, atau pengaduan naik ke produksi:

• Apakah alur ini "baru" menurut Penjelasan Pasal 26, termasuk karena menyasar target konsumen baru?
• Berapa partisipan per kelompok, dan apakah ada kelompok 60+ dan disabilitas yang masing-masing berisi sedikitnya 3 orang?
• Berapa skor SUS per kelompok, dibandingkan dengan rata-rata 68, dan apa nilainya di tabel Sauro–Lewis?
• Apakah ada re-test pada build yang diperbaiki, atau hanya daftar temuan?
• Apakah rekaman bebas dari data nasabah asli, dan siapa yang memegang aksesnya?

Usability testing menjawab apakah nasabah bisa memakai alurnya. Apakah orang lain bisa membobolnya, itu dijawab pengujian penetrasi, yang ruang lingkupnya kami uraikan di checklist SoW pentest untuk bank. Cara mengukur pengalaman setelah go-live, dari NPS sampai jumlah pengaduan, ada di artikel customer experience sebagai kewajiban POJK 22/2023. Untuk riset dan desain yang menyiapkan alur sebelum diuji, lihat layanan UX research dan UX design WEBARQ.