Belajar UI/UX Design - Desain Berbasis Data & A/B Testing
Mengambil keputusan desain berdasarkan data nyata: memahami heatmap, session recording, dan metodologi A/B testing, menyusun hipotesis yang terukur, serta menjalankan eksperimen pada alur transaksi KasirKita dan menginterpretasikan hasilnya dengan benar.
#Pendahuluan
Setelah di episode 16 kita menetapkan metrik dan rencana pengukuran, pada episode ini kita mengambil keputusan dari data — mengamati perilaku nyata lewat heatmap & session recording, lalu menguji perubahan dengan A/B testing. Ini mengubah desain dari "menurut saya" menjadi "menurut data".
Mengapa penting? Perdebatan desain paling mahal adalah yang diselesaikan dengan opini. Data tidak menggantikan judgment desainer — ia menyediakan dasar yang bisa dipertanggungjawabkan untuk keputusan, dan membuktikan ke stakeholder apakah perubahan benar-benar berhasil.
#Heatmap dan Session Recording
#Heatmap
Heatmap adalah visualisasi agregat perilaku di satu halaman: di mana pengguna menggulir, mengeklik, atau menggerakkan mata. Tiga jenis umum:
- Click map — titik klik/ketukan tersebar di halaman.
- Scroll map — seberapa jauh pengguna menggulir.
- Eye-tracking (move map) — area yang lama diamati (platform tertentu).
Untuk KasirKita: click map pada layar Beranda bisa mengungkap pengguna mengklik area yang bukan tombol (kesalahan affordance, episode 11), atau tombol Bayar yang tidak menonjol.
#Session Recording
Session recording merekam ulang sesi pengguna nyata — klik, scroll, jeda, kegagalan. Nilainya: melihat proses, bukan hanya hasil agregat. Contoh pola yang hanya terlihat dari recording:
- Pengguna membuka halaman produk lalu kembali (kebingungan).
- Jeda lama di satu input (ragu mengisi).
- Tiga kali klik pada elemen non-interaktif (frustrasi).
Tip
Hotjar (disiapkan episode 0) menyediakan heatmap & session recording sekaligus. Mulai dari 20-30 sesi saja sudah cukup menangkap pola umum. Biasakan menonton recording bersama tim seminggu sekali — sesi 15 menit ini sering menghasilkan ide perbaikan yang tidak muncul dari laporan angka.
#A/B Testing: Metodologi
A/B testing membagi pengguna menjadi dua kelompok: satu melihat kontrol (versi lama), satu melihat treatment (versi baru), lalu membandingkan metrik tujuannya.
#Menyusun Hipotesis yang Benar
Hipotesis yang baik mengikuti pola Jika → Maka → Karena:
JIKA tombol "Bayar" dipindah dari kanan-atas menjadi bar
mengambang di bawah layar Beranda
MAKA waktu mulai transaksi menurun 20%
KARENA tombol berada di thumb zone (episode 14) dan selalu
terlihat tanpa menggulir (episode 8).Perhatikan: hipotesis berisi prediksi terukur (turunan 20%) dan alasan berbasis prinsip (thumb zone, visibility). Tanpa "karena", eksperimen tidak memberi pembelajaran jika gagal.
#Komponen Eksperimen yang Sehat
| Komponen | Persyaratan |
|---|---|
| Metrik tunggal | Satu metrik primer per eksperimen (misal konversi transaksi) |
| Traffic | Cukup banyak untuk signifikansi statistik |
| Durasi | Cukup lama (minimal 1 siklus penggunaan lengkap, misal 1 minggu) |
| Kontrol | Hanya satu variabel yang diubah antara kontrol & treatment |
| Randomisasi | Pembagian pengguna acak, bukan berdasarkan kemauan |
#Signifikansi Statistik
Jangan tergoda kesimpulan dari perbedaan kecil. Aturan dasar:
- Perbedaan harus signifikan secara statistik (p-value < 0.05) — bukan sekadar "persentasenya naik dikit".
- Hitung confidence interval; jika lebar, sample belum cukup.
- Jangan berhenti di tengah "karena sudah terlihat menang" — itu memicu false positive.
- Satu eksperimen, satu keputusan: memilih pemenang hanya setelah periode selesai.
#Praktik: Eksperimen A/B pada Flow
Pilih satu hipotesis dari daftar berikut (atau buat sendiri):
- Posisi tombol Bayar — kanan-atas vs bar mengambang di bawah (thumb zone).
- Jumlah langkah checkout — 3 langkah vs 2 langkah (gabung konfirmasi & pembayaran).
- Label tombol — "Bayar" vs "Selesaikan Pembelian" (kejelasan microcopy).
Langkah:
- Tulis hipotesis lengkap (Jika-Maka-Karena) di frame
A/B Experiment. - Desain kedua varian di Figma (kontrol & treatment).
- Tentukan metrik primer + durasi + kriteria signifikansi.
- Implementasikan lewat tool A/B (Google Optimize/amplitude experiment) setelah handoff.
- Evaluasi setelah periode selesai — bukan sebelum.
Warning
Waspada peeking — melihat hasil berulang kali selama eksperimen berjalan dan berhenti "karena sudah kelihatan menang". Ini meningkatkan false positive secara drastis. Tentukan durasi & kriteria sebelum eksperimen dimulai, lalu evaluasi sekali di akhir. Data kecil juga rawan — jika traffic belum cukup, tunggu, jangan ambil kesimpulan.
#Common Pitfalls
- Mengubah 2 variabel sekaligus — tidak tahu perubahan mana yang bekerja.
- Hipotesis tanpa "karena" — eksperimen sukses/gagal tanpa pembelajaran.
- Terlalu cepat berhenti — kesimpulan dari sample kecil.
- Mengabaikan segmen — hasil keseluruhan bisa menutupi pola segmen (pemilik warung vs kasir).
- A/B untuk hal yang bisa diputuskan dengan riset — jangan A/B untuk keputusan yang jawabannya sudah jelas dari usability test.
#Penutup
Pada episode 17 ini, kalian telah memahami cara mengambil keputusan desain berbasis data.
Inti yang harus dibawa pulang:
- Heatmap menunjukkan di mana pengguna berinteraksi; session recording menunjukkan bagaimana prosesnya.
- Hipotesis A/B mengikuti pola Jika-Maka-Karena dengan prediksi terukur.
- Eksperimen sehat: satu metrik, satu variabel, randomisasi, durasi cukup, dan evaluasi signifikansi di akhir.
- Jangan peeking — evaluasi sekali setelah periode selesai; sample kecil menghasilkan kesimpulan salah.
- Data memutuskan debat opini, tetapi judgment desainer tetap dibutuhkan untuk memilih apa yang diuji.
Di episode 18 selanjutnya kita akan merancang kepercayaan: trust, privacy & consent UX — transparansi, data privacy (GDPR), cookie consent UX, dan dark patterns vs ethical design untuk KasirKita. Sampai jumpa di episode 18!