Belajar UI Designer - UI Research & Iteration Loop

#Pendahuluan

Setelah di episode 24 desain sudah menyuarakan brand, pada episode ini kita memastikan produk terus membaik: loop riset & iterasi. Desain pertama hampir tidak pernah yang terbaik — produk yang hebat adalah hasil ribuan iterasi kecil yang didorong data dan feedback nyata.

Mengapa loop iterasi adalah kompetensi inti UI designer? Karena kesempurnaan bukan momen, melainkan proses. Desainer yang tidak pernah menguji karyanya hidup di asumsi; desainer yang membangun loop iterasi terus-menerus mengecilkan risiko keputusan yang salah. Di era AI yang mempercepat produksi (episode 21), kecepatan iterasi inilah pembeda — siapa yang paling cepat belajar dari feedback, dia yang menang.

#Alur Iterasi: Build → Test → Learn

Siklus dasar yang harus menjadi kebiasaan:

Setiap putaran menjawab satu pertanyaan prioritas ("apakah alur tambah transaksi dipahami?"), bukan semua hal sekaligus. Satu putaran selesai = satu keputusan: perbaiki, pertahankan, atau ubah arah.

#Metode Pengujian yang Praktis

UI designer tidak selalu punya lab riset penuh — tetapi banyak metode yang murah dan cukup:

Aturan minimal: 5 pengguna cukup untuk menemukan mayoritas masalah (riset Nielsen) — lebih baik 5 tes kecil teratur daripada 1 tes besar yang jarang.

#Mengumpulkan dan Menyaring Feedback

Feedback mentah adalah campuran: berharga, menyesatkan, dan kontradiktif. UI designer menyaringnya dengan disiplin:

• Ambil perilaku, bukan keluhan literal — "tombol ini kecil" bisa berarti "saya tidak melihat aksinya"; perbaiki akar, bukan gejalanya.
• Pisahkan opini dan fakta — "saya tidak suka warnanya" vs "saya mengira ini bukan tombol" — yang terakhir lebih bisa ditindak.
• Cari pola — satu orang yang bingung bisa jadi anomali; tiga orang yang bingung di tempat sama adalah temuan.
• Tidak semua feedback harus diikuti — pengguna hebat dalam menunjukkan masalah, bukan dalam memberi solusi.

Mentah  : "Bagian saldo bikin pusing."
Saring  : 3 dari 5 peserta salah mengira grafik kecil itu tombol.
Temuan  : Elemen grafik tanpa affordance membingungkan → kaitkan ke heuristik 6.
Aksi    : Tambah label + hapus interaktivitas palsu pada grafik.

#Prioritas Perbaikan

Tidak semua temuan setara. Prioritaskan dengan mempertimbangkan dampak × frekuensi:

• Dampak tinggi + sering — perbaiki segera (alur inti yang gagal).
• Dampak rendah + sering — perbaiki saat sempat (gangguan kecil yang berulang).
• Dampak tinggi + jarang — jadwalkan (halaman yang jarang tapi krusial).
• Dampak rendah + jarang — simpan sebagai backlog.

Metode yang umum dipakai: Impact/Effort matrix — perbaiki dulu yang dampaknya besar dan usahanya kecil. Daftar ini juga menjadi bahan komunikasi ke stakeholder: kalian tidak "menuruti semua keinginan", tetapi memilih perbaikan berdampak.

#Versioning Desain

Iterasi yang rapi butuh versioning — tanpa itu, "versi mana yang benar?" menjadi perang.

• Simpan eksplorasi, bukan menghapus — buat page Figma Explorations untuk opsi yang dibuang; keputusan bisa berubah.
• Jelaskan perubahan — catat apa yang berubah dan mengapa (dasar keputusan bisa ditelusuri).
• Satu versi "current" — di file produksi, hanya ada satu versi aktif; sisanya di page arsip.
• Nama konsisten — V2 - Feedback 25/08 lebih jelas daripada final-final-2.

Di episode 26, ketika desain bergeser ke "mendesain aturan", versioning ini menjadi governance: setiap perubahan token dan komponen tercatat dan diuji sebelum rilis.

#Praktik: Satu Putaran Iterasi Penuh

1. Pilih satu alur (misal "lihat rekap bulanan") dan tentukan satu pertanyaan prioritas.
2. Uji prototype ke 3-5 orang (guerrilla testing), catat perilaku & kata-kata.
3. Saring feedback menjadi 2-3 temuan terverifikasi (pola, bukan anekdot).
4. Prioritaskan perbaikan (impact/effort) dan terapkan yang paling layak.
5. Arsipkan versi lama, tulis catatan perubahan, dan siapkan putaran berikutnya.

#Common Pitfalls

• Menguji terlalu telat — desain sudah "selesai", feedback mahal untuk diakomodasi.
• Menuruti semua feedback — desain jadi "hasil komite"; saring dengan pola & prioritas.
• Menghapus eksplorasi — keputusan yang dibuang tidak bisa ditelusuri lagi.
• Iterasi tanpa pertanyaan — mengubah-ubah tanpa fokus; tiap putaran harus menjawab satu pertanyaan.
• Mengukur dengan perasaan — tanpa pola/observasi, feedback jadi opini.

#Penutup

Pada episode 25 ini, kalian telah membangun siklus perbaikan yang membuat Kantongin terus membaik.

Inti yang harus dibawa pulang:

• Loop iterasi: build → test → learn, satu pertanyaan per putaran.
• Metode murah (guerrilla testing, Maze, heuristik) cukup untuk sebagian besar iterasi.
• Saring feedback: pola & perilaku, bukan keluhan literal; tidak semua diikuti.
• Prioritas berdasar impact/effort; versioning membuat riwayat keputusan telusur.

Di episode 26 selanjutnya kita akan membahas ekosistem & tren modern 2026 — agentic UX, generative interfaces, dan peran baru desainer sebagai Design System Governor. Sampai jumpa di episode 26!