Stop Buka Code Editor! Panduan Praktis UX Research untuk Junior Engineer

Halo Gaes!. Sebagai developer, saya tahu gatal rasanya tangan ini ingin langsung buka code editor, setup project baru pakai Next.js, instal Tailwind CSS, dan langsung merancang skema database. Tapi tahan dulu.

Hari ini kita akan bahas fondasi paling penting sebelum satu baris kode pun ditulis atau satu frame Figma pun dibuat. Kita akan fokus pada tahap pertama dari UI/UX Design Process: 01. RESEARCH — User Research & Analysis.

Mari kita mulai.

1. OPENING: JANGAN LANGSUNG DESAIN

Ada sebuah cerita klasik di dunia software development.

Seorang Product Owner datang kepada developer dan berkata:

"Kita perlu membuat aplikasi kasir untuk UMKM."

Mendengar itu, developer langsung semangat. Dia membuat sistem otentikasi (login/register), dashboard dengan berbagai grafik analitik, modul manajemen produk, sistem transaksi multi-step, laporan keuangan komprehensif, manajemen stok, database pelanggan, dan settings yang super lengkap. Setelah dua minggu sprint, UI sudah terlihat bagus dan API berjalan mulus.

Tetapi, ketika aplikasi itu diberikan kepada seorang pemilik warung kelontong, apa yang terjadi?

Pemilik warung bingung karena terlalu banyak menu.
Transaksi kasir menjadi sangat lambat karena harus melewati banyak langkah konfirmasi, padahal pembeli sedang mengantre.
Beberapa produk eceran sulit dimasukkan ke sistem karena satuan jualnya berbeda-beda.
Pemilik warung sebenarnya lebih sering mencatat hutang (kasbon) pelanggan setianya, tapi fitur ini malah tidak ada.
Koneksi internet warung sering putus-nyambung, membuat aplikasi web-based itu sering error.
Dashboard analitik yang keren itu tidak pernah dibuka; pemilik warung hanya butuh satu laporan sederhana: "Hari ini untung berapa?"

Masalahnya di sini bukan karena developer tidak bisa coding. Secara teknikal, aplikasinya mungkin sempurna.

Masalahnya adalah: Developer membuat solusi sebelum benar-benar memahami masalah.

Inilah kenapa tahap Research itu wajib. Don't start with the solution. Start with understanding the problem.

2. APA ITU RESEARCH DALAM UI/UX?

UX Research adalah proses sistematis untuk mengumpulkan data dan wawasan (insight) tentang pengguna, masalah mereka, dan konteks penggunaan produk.

Tujuannya? Untuk memastikan bahwa apa yang akan kita bangun (Technology) benar-benar menyelesaikan masalah nyata pengguna (User) dan sejalan dengan target bisnis (Business).

Kesalahan yang sering terjadi: Research sering disalahartikan sebagai sekadar, "Tanya user mau aplikasi seperti apa."

Ini berbahaya, karena user belum tentu bisa merumuskan solusi yang tepat.

Contoh:

User berkata: "Saya ingin ada tombol export ke Excel."

Sebagai developer, kamu mungkin langsung berpikir: "Oke, saya buatkan endpoint untuk generate CSV."

Tapi sebagai UX Researcher, kamu tidak boleh langsung menerima itu sebagai solusi. Kamu harus menggali:

Kenapa user membutuhkan Excel?
Data apa yang sebenarnya ingin mereka ambil?
Apa yang mereka lakukan setelah file itu di-export?
Siapa yang akan membaca file tersebut?

Ternyata, setelah digali, alasannya adalah karena di sistem saat ini tidak ada fitur filter berdasarkan tanggal, sehingga user harus men- download semuanya ke Excel untuk mem- filter data secara manual.

Jadi, akar masalahnya bukan "butuh export Excel", melainkan "butuh filter tanggal di dalam aplikasi". Research itu mencari masalah dan konteks, bukan sekadar mengumpulkan request fitur.

3. RESEARCH VS ASSUMPTION

Sebagai engineer, kita sangat terbiasa menggunakan logika kita sendiri. Ini membuat kita sering terjebak dalam Assumption (Asumsi).

Assumption: "Kemungkinan user membutuhkan fitur grafik tren penjualan bulanan di dashboard." (Ini hanya tebakan kita).
Evidence: "Dari 8 pemilik warung yang diwawancarai, 6 orang menyatakan kesulitan melacak stok barang mana yang paling cepat habis setiap minggunya." (Ini adalah fakta berbasis data).

Don't design what you think users need. Understand what they actually need.

Tentu saja, kita tidak menelan mentah-mentah semua keinginan user. Kita mencari evidence (bukti) dan menghubungkannya dengan kapabilitas teknis serta tujuan bisnis.

4. MEMULAI RESEARCH DARI PROBLEM

Sebelum bertanya kepada siapa pun, researcher harus paham masalah apa yang sebenarnya sedang kita hadapi. Gunakan framework Problem Discovery (5W1H + Impact) sederhana ini:

Who: Siapa yang mengalami problem? (Pemilik warung).
What: Apa problemnya? (Kesulitan mengetahui keuntungan harian).
When: Kapan problem itu terjadi? (Saat akhir hari ketika warung tutup).
Where: Di mana terjadinya? (Di warung, saat merekap uang di laci).
Why: Kenapa terjadi? (Karena pencatatan transaksi masih dicampur aduk secara manual di buku tulis).
Impact: Apa dampaknya? (Pemilik tidak tahu apakah penjualan hari tersebut benar-benar menghasilkan keuntungan, sehingga perputaran modal terhambat).

5. BUSINESS PROBLEM VS USER PROBLEM

Masalah bisnis dan masalah user itu berbeda, meskipun saling berkaitan. Mari kita bedah:

Business Problem: "Retensi pelanggan di aplikasi kita rendah." (Apa yang dikeluhkan oleh perusahaan).
User Problem: "User kesulitan menemukan fitur riwayat transaksi sehingga mereka merasa aplikasi ini tidak aman dan berhenti menggunakannya." (Apa yang dialami pengguna).
Technical Problem: "API endpoint untuk riwayat transaksi membutuhkan waktu query 5 detik." (Apa yang dilihat sistem/developer).
UX Problem: "User menganggap aplikasi nge-bug karena layar hanya blank putih tanpa ada skeleton loader atau pesan error ketika data sedang diproses." (Apa interaksi yang gagal).

Nasihat Senior: Jangan menerima kalimat dari stakeholder mentah-mentah sebagai problem statement. Kalau stakeholder bilang aplikasinya jelek, tugas kita adalah menggali apa yang sebenarnya terjadi di lapangan.

6. MENENTUKAN RESEARCH OBJECTIVE

Research yang baik harus punya tujuan (objective) yang jelas. Kalau tidak, kamu hanya akan ngobrol ngidul tanpa arah.

❌ Objective Buruk: "Mencari tahu pendapat user tentang aplikasi kasir." (Terlalu luas, tidak bisa diukur).

✅ Objective Baik: "Memahami bagaimana pemilik UMKM mencatat transaksi harian dan mengidentifikasi hambatan utama yang menyebabkan pencatatan dilakukan secara manual."

Contoh Objective Lainnya:

Memahami proses manajemen stok barang masuk dan keluar di warung sembako.
Mengidentifikasi kebiasaan pelanggan dalam berhutang dan bagaimana pemilik warung menagihnya.
Menemukan alasan utama mengapa pemilik warung berhenti menggunakan aplikasi POS kompetitor.
Memetakan kendala teknis (seperti internet dan perangkat) yang dialami UMKM saat operasional sehari-hari.
Memahami bagaimana pemilik UMKM melakukan rekapitulasi keuangan di akhir bulan.

7. MEMBUAT RESEARCH QUESTION

Research Objective adalah tujuan akhir kita, sedangkan Research Question adalah pertanyaan besar yang harus terjawab agar tujuan itu tercapai. (Catatan: ini bukan pertanyaan yang diajukan langsung ke user ya, tapi panduan untuk kita).

Objective: Memahami proses pencatatan transaksi UMKM.

Research Questions:

Bagaimana user mencatat transaksi saat ini?
Kapan user biasanya mencatat transaksi?
Apa yang dilakukan user setelah transaksi selesai?
Apa kesulitan terbesar dalam pencatatan?
Apakah user pernah menggunakan aplikasi kasir sebelumnya?
Mengapa user berhenti atau tidak menggunakan aplikasi tersebut?

8. MEMILIH METODE RESEARCH

Bagaimana cara kita menjawab Research Questions di atas? Kita pilih metodenya:

A. User Interview: Mengobrol langsung 1-on-1. Gunakan saat butuh pemahaman mendalam (why dan how). Kelebihannya bisa menggali emosi dan cerita. Kekurangannya memakan waktu dan rentan bias jika penanya menggiring opini.
B. Observation: Mengamati user di habitat aslinya. Kenapa? Karena apa yang dikatakan user sering berbeda dengan apa yang mereka lakukan (Say vs Do).
C. Survey: Mengirim kuesioner. Cocok digunakan ketika kita sudah tahu masalahnya dan butuh validasi kuantitatif (misalnya membuktikan bahwa 80% dari 1000 user juga mengalami hal yang sama).
D. Competitive Research: Menganalisis kompetitor. Bukan untuk copy-paste fitur, tapi melihat standar pasar dan celah yang belum diselesaikan kompetitor.
E. Secondary Research: Mencari data dari luar, seperti laporan industri, review di Google Play Store/App Store, jurnal akademis, atau forum UMKM.
F. Analytics: Jika produknya sudah jalan, kita bisa melihat data seperti conversion rate, drop-off (di halaman mana user sering keluar), atau API metrics. Ini ibarat mengecek server logs untuk mencari tahu behavior user.

9. STUDY CASE UTAMA: APLIKASI POS SEDERHANA UNTUK UMKM WARUNG

Agar lebih praktis, mari kita gunakan study case. Anggaplah kita ingin membangun platform POS komersial.

Stakeholder berkata: "Kita mau membuat aplikasi kasir yang lengkap supaya bisa bersaing dengan POS yang sudah ada."

Sebagai senior, saya akan bilang: "Tahan, jangan langsung bikin arsitektur microservices atau landing page marketing-nya dulu. Mari kita research."

10. STUDY CASE — LANGKAH 1: MEMAHAMI KONTEKS

Business Goal: Membuat produk POS yang mudah digunakan oleh UMKM kecil dan memiliki tingkat penggunaan berulang (retention) yang tinggi.
Research Goal: Memahami bagaimana UMKM kecil melakukan proses transaksi, pencatatan stok, pencatatan hutang, dan pembuatan laporan saat ini.

Research Questions:

Bagaimana alur transaksi dari pelanggan datang hingga selesai?
Perangkat apa yang biasa digunakan di area kasir?
Seberapa sering masalah koneksi internet terjadi?
Bagaimana cara user mengelola hutang pelanggan?
Bagaimana cara user memantau ketersediaan barang?
Berapa lama waktu rata-rata untuk melayani satu pelanggan?
Laporan apa saja yang krusial bagi pemilik warung?
Apa yang membuat kasir merasa stres saat warung ramai?
Apakah ada satuan ukur barang yang kompleks (misal: jual rokok per bungkus vs per batang)?
Apa keluhan utama terhadap sistem yang mereka pakai sekarang (manual/digital)?

11. STUDY CASE — LANGKAH 2: MENENTUKAN PARTICIPANT

Siapa yang harus kita wawancarai?

Pemilik warung (pengambil keputusan)
Kasir atau karyawan toko (pengguna harian)
User yang sudah pakai aplikasi POS lain
User yang masih 100% manual

Kenapa kita tidak boleh sekadar bertanya pada teman developer kita? Karena temanmu tech-savvy. Mereka representasi yang salah. Kita butuh representative participant. Untuk penelitian eksploratif awal, 5-8 participant dengan latar belakang yang relevan sudah cukup untuk menemukan pattern (pola) masalah yang berulang.

12. STUDY CASE — LANGKAH 3: USER INTERVIEW

Berikut adalah panduan pertanyaan (Interview Guide).

Background: "Sudah berapa lama mengelola warung ini? Berapa rata-rata pelanggan per hari?"
Current Behavior: "Bisa ceritakan langkah demi langkah saat ada pembeli yang membeli barang dalam jumlah banyak?"
Pain Point: "Apa bagian paling merepotkan saat merekap pendapatan di malam hari?"
Motivation: "Kenapa Bapak memilih mencatat pakai buku ketimbang aplikasi di HP?"
Existing Solution: "Bagaimana cara Bapak mengingat pelanggan mana yang masih punya kasbon?"
Expectation: "Jika ada tongkat ajaib yang bisa menyelesaikan satu masalah di warung Bapak, apa yang ingin diselesaikan?"

Penting: Hindari pertanyaan leading (menggiring opini).

❌ "Apakah Anda merasa aplikasi kasir sulit digunakan?" (User akan cenderung menjawab "Iya").

✅ "Ceritakan pengalaman terakhir Anda ketika menggunakan aplikasi kasir." (User akan bercerita jujur tentang kesulitannya).

13. STUDY CASE — LANGKAH 4: OBSERVATION

Kita mengunjungi sebuah warung. Dari hasil pengamatan, kita melihat:

Pemilik warung menerima pesanan sambil ngobrol.
Menghitung total menggunakan kalkulator fisik besar, bukan smartphone.
Menerima uang tunai, menaruhnya di laci yang berantakan.
Tidak mencatat transaksi satuan, hanya mengumpulkan uangnya.
Kalau ada yang hutang, dia buru-buru menulis di buku lecek di bawah meja.

Di sinilah kita sadar: Kalau kita bikin UI di mana kasir harus memilih kategori barang > mencari produk > memasukkan jumlah > klik bayar > pilih metode pembayaran... Itu terlalu lama! Behavior ini memberi insight bahwa kecepatan adalah segalanya.

14. STUDY CASE — LANGKAH 5: COMPETITIVE RESEARCH

Kita lihat aplikasi POS X dan POS Y yang sudah ada di pasar. Kita tidak melihat ini untuk mencontek source code atau meniru UI mereka.

Kita menganalisis:

Posisi pasar mereka terlalu mengarah ke franchise besar.
Banyak review bintang 1 yang mengeluhkan aplikasi sering logout sendiri saat sinyal jelek.
Fitur inventory-nya mengharuskan input SKU, padahal warung kecil tidak kenal SKU.

Tujuannya adalah "Memahami market, expectation user, dan opportunity" yang bisa kita isi.

15. STUDY CASE — LANGKAH 6: MENGUMPULKAN DATA

Setelah wawancara, kumpulkan notes-nya. (Catatan: Data di bawah adalah SIMULASI/DATA FIKTIF untuk latihan).

Participant P01: "Saya sebenarnya punya aplikasi kasir, tapi jarang dipakai karena terlalu banyak menu. Pusing carinya pas lagi antre."
Participant P02: "Kalau transaksi kecil kayak beli terigu sebungkus, saya lebih cepat pakai kalkulator. Gak perlu buka HP."
Participant P03: "Yang paling saya butuhkan sebenarnya tahu total penjualan hari ini, dan uang yang di laci itu cocok nggak sama catatannya."
Participant P04: "Stok sering lupa diperbarui. Pas orang mau beli, eh ternyata di gudang udah habis."
Participant P05: "Banyak tetangga suka ngutang (kasbon). Pencatatannya masih di buku, kadang bukunya terselip."

16. STUDY CASE — AFFINITY MAPPING

Sebagai developer, anggap saja proses ini seperti menormalisasi database—mengelompokkan raw data menjadi relational tables (tema). Kita buat Affinity Map:

Theme 1 — Transaction Speed: (P01, P02) User butuh transaksi secepat kalkulator, aplikasi terlalu lambat/kompleks.
Theme 2 — Reporting: (P03) Kebutuhan utama adalah mencocokkan uang fisik dengan rekap harian secara cepat.
Theme 3 — Stock: (P04) Manajemen stok yang terpisah dari transaksi harian membuat data tidak akurat.
Theme 4 — Debt: (P05) Pencatatan hutang adalah budaya UMKM yang belum terfasilitasi dengan baik secara digital.

17. DARI DATA MENJADI INSIGHT

Ini bagian yang sering keliru. Insight bukan sekadar mengulang ucapan pengguna.

Observation: User menghitung uang belanjaan pembeli dengan kalkulator.
Finding: Sebagian user UMKM masih menggunakan kalkulator fisik meskipun memiliki aplikasi kasir di HP mereka.
Insight: Kecepatan dan kelancaran transaksi saat melayani pelanggan jauh lebih penting bagi user UMKM daripada kelengkapan pencatatan data secara mendetail. Aplikasi yang ada saat ini menambah beban kognitif mereka.
Opportunity: Bagaimana membuat flow transaksi semudah menekan tombol kalkulator, tanpa mengurangi akurasi pencatatan di background?

18. PAIN POINT PRIORITIZATION

Dalam software development, kita tidak mungkin mengerjakan semua backlog dalam satu sprint. Kita butuh prioritas.

Pain Point	Frequency	Severity	Impact	Priority
Proses transaksi terlalu lama	Tinggi	Tinggi	Tinggi	P1
Pencatatan kasbon sering hilang	Sedang	Tinggi	Tinggi	P1
Stok sulit dipantau real-time	Tinggi	Sedang	Sedang	P2
Laporan bulanan kurang detail	Rendah	Rendah	Rendah	P3

Kita tidak perlu langsung membuat modul analitik yang rumit. Fokus pada penyelesaian P1 terlebih dahulu.

19. DELIVERABLE TAHAP RESEARCH

Pada akhir tahap ini, kamu tidak menyerahkan code. Kamu menyerahkan pemahaman. Beberapa dokumen yang biasanya dihasilkan:

Research Brief & Objective: Dasar pelaksanaan riset.
Interview Notes & Observation Notes: Data mentah.
Affinity Map: Pengelompokan masalah.
Key Findings & Insights: Penemuan utama yang bisa ditindaklanjuti.
Pain Points: Daftar masalah beserta prioritasnya.
Opportunity Areas: Celah ruang untuk perbaikan (biasanya diformat menjadi How Might We).
Research Report: Rangkuman dari semua proses di atas untuk dipresentasikan ke stakeholder.

20. KAPAN RESEARCH DIANGGAP SELESAI?

Apakah kita harus mewawancarai 100 orang agar valid? Tidak.

Research bukan berarti: "Kita sudah wawancara 10 orang, berarti selesai."

Research di tahap eksplorasi dianggap cukup ketika kamu mulai mendengar jawaban yang sama berulang-ulang dari partisipan yang berbeda (mencapai data saturation). Intinya, Research cukup ketika kita sudah memiliki evidence yang memadai untuk mengurangi ketidakpastian yang relevan dengan keputusan desain dan engineering selanjutnya.

21. KESALAHAN JUNIOR YANG HARUS DIHINDARI

Berikut adalah "jebakan" yang sering memakan korban junior:

Langsung membuat UI atau arsitektur sistem. (Solusi: Pahami masalahnya dulu).
Menganggap stakeholder selalu benar. (Solusi: Stakeholder tahu goal bisnis, tapi UX researcher yang menggali fakta lapangan).
Menganggap developer paling tahu apa yang dimau user. (Solusi: Kamu bukan user!)
Bertanya kepada teman sesama IT. (Solusi: Cari target pengguna asli).
Menggunakan pertanyaan leading. (Solusi: Biarkan user bercerita terbuka).
Hanya mencari validasi terhadap ide sendiri. (Solusi: Bersiaplah idemu dipatahkan oleh fakta lapangan).
Mengabaikan behavior. (Solusi: Perhatikan apa yang mereka lakukan, bukan cuma yang diucapkan).
Menganggap satu keluhan mewakili semua user. (Solusi: Cari polanya, minimal terlihat di beberapa partisipan).
Mengumpulkan terlalu banyak data tanpa tujuan. (Solusi: Selalu kembali ke Research Objective).
Tidak melakukan synthesis (pengelompokan). (Solusi: Gunakan Affinity Mapping).
Mengubah SEMUA request user menjadi fitur. (Solusi: Gali akar masalah, bukan kumpulkan daftar belanjaan fitur).
Menganggap kompetitor adalah blueprint mutlak. (Solusi: Kompetitor juga bisa salah bikin fitur).
Mengabaikan business constraint (waktu, budget, resource). (Solusi: Sesuaikan opportunity dengan kapasitas tim).
Tidak mencatat evidence. (Solusi: Dokumentasikan semua rekaman dan notes).
Membuat persona berdasarkan imajinasi/asumsi. (Solusi: Persona harus lahir dari data riset).

22. HUBUNGAN RESEARCH DENGAN SOFTWARE ENGINEERING

Sebagai engineer, mungkin kamu bertanya, "Apa gunanya buat saya?" UX Research itu berhubungan langsung dengan arsitektur aplikasimu.

Developer biasanya bertanya: "Endpoint API apa saja yang harus dibuat?"

UX Research membuat kita tahu proses bisnis sebenarnya, sehingga domain-driven design API-mu lebih tepat sasaran.
Developer bertanya: "Field apa saja yang harus ada di tabel transaksi?"

UX Research membantu menjawab informasi spesifik apa yang krusial bagi pencatatan user di dunia nyata (misal: perlu tambahan field is_kasbon).
Developer mendesain web-based app yang heavy loading.

UX Research menginformasikan bahwa user sering berada di area susah sinyal. Engineer akhirnya memutuskan untuk mengimplementasikan arsitektur Offline-First (PWA/Service Worker) alih-alih me- request data ke server di tiap click.

UX Research dan software engineering bukanlah dua dunia yang terpisah. Research yang baik mencegah engineer membangun fitur sampah yang tidak terpakai.

23. SENIOR ENGINEER ADVICE: KALAU SAYA MEMBIMBING KAMU

Kalau kamu baru mulai belajar ini, ini pesan saya:

"Kalau kamu menerima requirement 'buatkan aplikasi X', jangan langsung buka VS Code atau Figma."
"Jangan takut bertanya 'Kenapa?'. Kemampuan bertanya adalah skill paling underrated dalam product development."
"Jangan mengejar jumlah fitur. Kejar seberapa tajam kita menyelesaikan masalah inti."
"Kode yang bersih (clean code) atau UI yang estetik tidak akan bisa menyelamatkan problem definition yang salah."
"Kalau bingung, turun ke lapangan. Lihat user-mu berkeringat menghadapi masalahnya."
"Berhentilah membela idemu di depan user. Tugasmu mendengarkan, bukan jualan."
"Gunakan bahasa manusia biasa saat ngobrol sama user. Jangan pakai istilah 'API', 'Database', atau 'Dashboard'."
"Riset itu tidak perlu berbulan-bulan. Tiga hari riset yang solid lebih baik daripada setahun coding dalam kegelapan."
"Data itu cuma angka. Insight adalah nyawa yang menggerakkan produk."
"Ingat, kamu membangun software untuk memudahkan hidup orang lain, bukan sekadar memuaskan ego engineering-mu."

24. SIMULASI END-TO-END RESEARCH

Mari kita lihat secara urut sebelum kita tutup:

Step 1: Stakeholder requirement: "Kami ingin membuat POS untuk UMKM."
Step 2: Research objective: "Memahami bagaimana UMKM melakukan transaksi harian dan pencatatan hutang."
Step 3: Research questions: "Bagaimana alur kasir saat jam sibuk? Bagaimana menangani kasbon?"
Step 4: Participant recruitment: Merekrut 5 pemilik warung kelontong setempat.
Step 5: Interview: Menggali pain point menggunakan pertanyaan terbuka.
Step 6: Observation: Melihat langsung bahwa mereka menghitung pakai kalkulator fisik.
Step 7: Competitive research: Menganalisis mengapa POS yang ada di pasaran ditinggalkan.
Step 8: Data synthesis: Mengumpulkan notes wawancara ke dalam Affinity Map.
Step 9: Findings: User UMKM mengutamakan kecepatan; pencatatan kasbon sangat vital tapi manual.
Step 10: Insights: Aplikasi kasir yang kompleks menambah beban kognitif saat melayani pelanggan.
Step 11: Pain points: Transaksi terlalu banyak langkah (P1), rekap kasbon sering tercecer (P1).
Step 12: Opportunity areas: "Bagaimana jika aplikasi POS dibuat seringkas kalkulator dengan sistem kasbon built-in?"
Step 13: Research conclusion: Fokus MVP pada fitur kalkulator pintar dan manajemen hutang pelanggan sederhana, bukan pada laporan analitik grafis.

Berhenti. Sampai sini, kita sudah siap membawa pemahaman ini ke tahap berikutnya (Define).

25. FINAL OUTPUT: RESEARCH CHEAT SHEET

Simpan ringkasan ini baik-baik.

Sebelum Research (Persiapan):
- Tentukan Problem Statement & Business Goal.
- Tentukan Research Objective.
- Susun Research Questions.
- Pilih Metode (Interview, Observasi, dll).
- Buat Interview Guide.
- Cari Partisipan yang tepat (bukan teman sendiri).
Saat Research (Pelaksanaan):
- Dengarkan lebih banyak, bicara lebih sedikit.
- Perhatikan behavior (apa yang dilakukan), jangan cuma opinion (apa yang diucapkan).
- Tanya mengapa berulang kali sampai menemukan akar masalah.
- Dokumentasikan setiap sesi (catatan/audio).
Setelah Research (Sintesis):
- Kumpulkan data mentah.
- Lakukan Affinity Mapping (pengelompokan).
- Ekstrak Key Findings & Insights.
- Prioritaskan Pain Points.
- Buat ringkasan (Research Report).

Pertanyaan Penting untuk Refleksi Diri:

Siapa user kita?
Apa yang mereka lakukan?
Apa masalah utama mereka?
Mengapa masalah tersebut terjadi?
Seberapa sering masalah itu terjadi?
Bagaimana mereka menyelesaikannya sekarang secara manual?
Apa dampaknya terhadap hidup/bisnis mereka?
Apa evidence (bukti nyata) yang kita punya?
Mana bagian dari ide kita yang ternyata masih berupa asumsi?

Jadi, stop dulu buka VS Code-nya. Pahamilah konteksnya. Kumpulkan buktinya. Formulasikan insight-nya. Setelah kamu benar-benar paham akar masalahnya, barulah temuan riset ini menjadi fondasi yang kuat untuk melangkah ke tahap Define dan Design. Selamat meriset!

Kembali ke Artikel