Riset UX Inklusif: Designing 'With', Not 'For'
Penulis
Redaksi Disabilitas.com
Riset UX Inklusif: Designing "With", Not "For"
Dalam desain perangkat lunak tradisional, desainer merancang produk untuk (for) pengguna. Namun, dalam dunia aksesibilitas, merancang perangkat lunak untuk penyandang disabilitas sering kali berujung pada asumsi yang merendahkan dan solusi yang tidak praktis. Pendekatan modern menuntut kita untuk mendesain bersama (with) mereka.
Slogan terkenal dalam komunitas disabilitas adalah "Nothing About Us Without Us" (Tidak ada tentang kami tanpa kami). Berdasarkan sintesis metodologi riset dari Guide to Digital Accessibility dan Inclusive Design for Accessibility, artikel ini akan membongkar kesalahan fatal dalam riset UX tradisional dan bagaimana membangun sesi pengujian inklusif yang sesungguhnya.
Insight Terkait
Mengapa Alat Audit Aksesibilitas Otomatis Bukan Segalanya1. Kesalahan Fatal: Simulasi Disabilitas (Blindfold Fallacy)
Banyak agensi UX mencoba melakukan "pengujian empati" dengan menyuruh desainer mereka memakai penutup mata (blindfold), sarung tangan tebal, atau penyumbat telinga, lalu mencoba menggunakan situs web mereka.
Praktik ini sangat ditentang oleh para ahli aksesibilitas (termasuk Jonathan Lazar dan Dale Cruse). Mengapa?
- Bukan Realitas yang Sebenarnya: Seorang desainer yang matanya ditutup akan mengalami kepanikan dan kebingungan mendadak. Sebaliknya, seorang tunanetra sejati telah hidup bertahun-tahun dengan kondisi tersebut; mereka sangat mahir menggunakan Screen Reader dengan kecepatan 400 kata per menit—sesuatu yang mustahil dilakukan oleh desainer berpenutup mata.
- Fokus pada Kesedihan, Bukan Solusi: Simulasi ini biasanya hanya menghasilkan kesimpulan "Wah, ternyata susah sekali ya menjadi tunanetra", alih-alih menghasilkan data UX objektif mengenai letak kesalahan navigasi DOM.
Solusinya: Jangan pernah mensimulasikan disabilitas. Rekrutlah penyandang disabilitas asli untuk menguji produk Anda.
Insight Terkait
Metodologi Pengujian Aksesibilitas Manual (Web & Mobile Apps)2. Expert Review vs Usability Testing
Dalam mengaudit situs web, Anda membutuhkan dua hal yang berbeda: Expert Review dan Usability Testing. Jangan mencampuradukkan keduanya.
A. Expert Review (Tinjauan Ahli)
Dilakukan oleh auditor aksesibilitas teknis. Tugas mereka adalah memeriksa kode sumber, memastikan kontras 4.5:1, memvalidasi tag ARIA, dan memastikan situs web secara teknis mematuhi hukum WCAG. Ini adalah pengujian berbasis checklist.B. Usability Testing (Pengujian Kegunaan)
Dilakukan oleh pengguna disabilitas (orang awam). Tugas mereka bukan untuk mencari pelanggaran WCAG. Tugas mereka adalah mencoba membeli sepatu di situs e-commerce Anda. Sebuah situs web bisa saja lulus 100% audit WCAG secara hukum, tetapi jika pengguna tunanetra membutuhkan waktu 30 menit hanya untuk menemukan tombol "Checkout", maka pengalaman UX-nya gagal total.3. Logistik Pengujian Bersama Penyandang Disabilitas
Mengadakan sesi Usability Testing inklusif memerlukan penyesuaian logistik:
- Gunakan Perangkat Mereka Sendiri: Jangan memaksa partisipan tunanetra untuk menggunakan laptop yang disediakan kantor Anda. Mereka telah mengatur konfigurasi Screen Reader (JAWS, NVDA, atau VoiceOver), pengaturan kecepatan baca, dan keyboard shortcut makro di mesin mereka sendiri. Mengubah mesin akan merusak pengujian.
- Kompensasi yang Adil: Pengetahuan hidup (lived experience) mereka adalah data ahli. Bayar mereka secara profesional seperti Anda membayar konsultan IT.
- Penyediaan Akomodasi Tambahan: Tanyakan sebelumnya apakah mereka membutuhkan penerjemah bahasa isyarat, akses kursi roda ke gedung pengujian, atau perangkat lunak pencatat (transcription) tambahan.
4. Analisis Data dan Bias Kasihan (Pity Bias)
Saat menganalisis hasil riset, peneliti UX sering kali jatuh ke dalam perangkap "Bias Kasihan". Jika partisipan disabilitas gagal menyelesaikan tugas, peneliti sering kali membantu mereka atau memaklumi kegagalan tersebut karena "kasihan, kondisinya sulit".
Insight Terkait
Anatomi Laporan Audit Aksesibilitas (Bug Report & ACR/VPAT)Ini adalah penghinaan terhadap data. Jika partisipan gagal karena antarmuka Anda buruk, catat itu sebagai kegagalan UX yang mutlak. Jangan memperlakukan pengguna disabilitas sebagai pasien yang rapuh; perlakukan mereka sebagai konsumen (User) yang memiliki standar tinggi terhadap kualitas produk yang mereka gunakan.
5. Kesimpulan
Mendesain perangkat lunak inklusif tidak bisa dilakukan hanya dari belakang layar monitor yang dikelilingi oleh buku spesifikasi W3C. Mematuhi WCAG membuat Anda aman dari tuntutan hukum, tetapi mengundang penyandang disabilitas nyata ke dalam laboratorium UX Anda adalah apa yang membuat produk Anda dicintai. Desain yang hebat selalu dibangun dari pengamatan empiris manusia, bukan sekadar asumsi kode.
Referensi
Kritik terhadap simulasi disabilitas (blindfold fallacy) serta diferensiasi fundamental antara kepatuhan teknis (Expert Review) dan pengalaman praktis (Usability Testing) diekstrak dari wawasan metodologis di dalam Inclusive Design for Accessibility (Dale Cruse, Denis Boudreau). Panduan logistik pelaksanaan riset bersama partisipan disabilitas merujuk pada kerangka kerja manajerial di dalam Guide to Digital Accessibility (Rae Mancilla).Bagaimana menurut Anda?
Berikan reaksi Anda pada artikel ini