Program Studi Bisnis Digital • FEB UNDIP

Desain UI & UX

Pertemuan 2 — Proses Desain Berpusat Pengguna: Design Thinking

Empathize, Define, Ideate, Prototype, Test — lima tahap berpikir yang dipakai tim desain Tokopedia, GoJek, hingga BCA untuk merancang produk digital yang benar-benar dibutuhkan penggunanya.

RPS MINGGU 2 · 2X50 MENIT

Selamat pagi, selamat datang kembali di mata kuliah Desain UI dan UX. Minggu lalu Anda sudah berkenalan dengan istilah UI dan UX serta perannya dalam bisnis digital, dan hari ini kita masuk ke jantung dari seluruh proses desain, yaitu Design Thinking. Anda tidak perlu punya latar belakang desain sama sekali untuk mengikuti pertemuan ini, karena Design Thinking sebenarnya adalah cara berpikir yang sudah sering Anda pakai tanpa sadar, misalnya ketika mencoba memahami kenapa teman Anda kesulitan memakai aplikasi tertentu lalu mencari solusinya. Hari ini kita akan bedah lima tahapnya satu per satu, yaitu Empathize, Define, Ideate, Prototype, dan Test, lengkap dengan contoh nyata dari perusahaan digital Indonesia seperti Tokopedia dan BCA. Pertemuan ini dua kali lima puluh menit, cukup untuk membangun fondasi yang akan kita pakai terus sepanjang semester, termasuk saat riset pengguna di pertemuan tiga nanti.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu memahami dan menerapkan kerangka Design Thinking. Secara rinci:

CAPAIAN 1 — MINDSET

POLA PIKIR DESAIN

Menjelaskan apa itu Design Thinking dan mengapa pendekatannya berpusat pada manusia (human-centered), bukan pada teknologi atau asumsi tim.

CAPAIAN 2 — LIMA TAHAP

EMPATHIZE—TEST

Menguraikan tujuan dan aktivitas kunci di tiap tahap: Empathize, Define, Ideate, Prototype, Test, serta sifatnya yang tidak linear.

CAPAIAN 3 — PRAKTIK DASAR

POV & PROTOTIPE

Menyusun Point of View statement sederhana dan membedakan tingkat fidelity prototipe (rendah vs tinggi).

CAPAIAN 4 — STUDI KASUS

PRAKTIK INDONESIA

Menganalisis penerapan Design Thinking pada produk digital Indonesia untuk melihat dampaknya pada pengalaman pengguna.

Perhatikan empat kotak capaian ini karena inilah peta perjalanan kita hari ini. Capaian pertama soal pola pikir, Anda akan paham kenapa Design Thinking disebut human-centered, berpusat pada manusia, bukan pada kecanggihan teknologi semata. Capaian kedua adalah inti pertemuan, lima tahap Design Thinking mulai dari Empathize sampai Test, dan pentingnya memahami bahwa kelimanya bukan tahapan kaku yang harus urut sekali jalan. Capaian ketiga bersifat praktis, Anda akan berlatih menyusun rumusan masalah sederhana yang disebut Point of View statement, serta mengenal perbedaan prototipe kasar dan prototipe halus. Terakhir kita tutup dengan studi kasus produk digital Indonesia, supaya Anda melihat bahwa kerangka ini bukan teori kosong, tapi benar-benar dipakai tim desain di Tokopedia maupun bank seperti BCA.

Dari Pertemuan 1: Kenapa UI/UX Butuh Sebuah Proses?

Minggu lalu Anda belajar UI (tampilan) dan UX (pengalaman) itu berbeda tapi saling melengkapi. Pertanyaannya sekarang: bagaimana cara merancang keduanya secara sistematis?

Tanpa proses yang jelas, tim sering langsung lompat ke tahap desain visual atau coding berdasarkan asumsi — bukan kebutuhan nyata pengguna. Hasilnya: fitur bagus di mata tim, tapi tidak dipakai pelanggan.

POSISI PERTEMUAN 2 DALAM RPS SATU SEMESTER

Minggu 1 — Pengantar UI/UX & peran dalam bisnis digital (selesai).
Minggu 2 (hari ini) — Proses Design Thinking sebagai kerangka besar.
Minggu 3 — Riset pengguna mendalam: metode, persona, empathy map, journey map.
Minggu 4 — Mendefinisikan masalah & ideasi lanjutan (How Might We, Crazy 8's).

Kenapa Produk Bagus Bisa Gagal di Pasar?

Bandingkan dua tim yang sama-sama membangun fitur pembayaran untuk UMKM.

TIM A — "KAMI TAHU YANG TERBAIK"

Asumsi Internal

Langsung desain fitur QRIS canggih dengan banyak opsi laporan. Peluncuran sepi peminat: pemilik warung ternyata cuma butuh satu tombol "terima bayar" yang cepat.

TIM B — "KAMI DENGAR DULU"

Riset ke Lapangan

Wawancara 10 pedagang pasar, amati cara mereka mencatat transaksi manual. Desain jadi sederhana & sesuai kebiasaan. Adopsi tinggi sejak minggu pertama.

Fitur yang secara teknis "bagus" bisa gagal total kalau tidak lahir dari pemahaman nyata terhadap pengguna. Inilah alasan Design Thinking selalu dimulai dari empati, bukan dari solusi.

Mari kita bayangkan situasi nyata yang sering terjadi di industri digital Indonesia. Tim A merasa sudah paham kebutuhan pengguna hanya berdasarkan diskusi internal di kantor, lalu langsung membangun fitur pembayaran QRIS dengan banyak sekali opsi laporan keuangan yang canggih, tetapi saat diluncurkan ternyata sepi peminat karena pemilik warung di pasar sebenarnya cuma butuh satu tombol sederhana untuk menerima pembayaran dengan cepat, mereka tidak sempat membaca laporan rumit di sela melayani pembeli. Tim B melakukan hal berbeda, mereka mewawancarai sepuluh pedagang pasar, mengamati langsung bagaimana kebiasaan mencatat transaksi secara manual di buku, lalu merancang fitur yang sesuai kebiasaan itu, hasilnya tingkat adopsi tinggi sejak minggu pertama peluncuran. Perbedaan hasil ini bukan soal siapa timnya lebih pintar secara teknis, tapi soal siapa yang benar-benar berempati pada penggunanya. Inilah alasan kenapa Design Thinking selalu dimulai dari tahap empati, bukan langsung lompat ke solusi.

Apa Itu Design Thinking?

Sebuah metodologi pemecahan masalah yang berpusat pada manusia (human-centered), dipopulerkan oleh IDEO & Stanford d.school.

DESIRABILITY (diinginkan manusia) + FEASIBILITY (bisa dibangun teknologi) + VIABILITY (layak secara bisnis)

HUMAN-CENTERED

Mulai dari Manusia

Solusi lahir dari kebutuhan & masalah nyata pengguna, bukan dari fitur yang "keren" secara teknis.

ITERATIF

Bolak-balik, Bukan Lurus

Tim boleh kembali ke tahap sebelumnya kapan saja begitu ada temuan baru — tidak harus urut sekali jalan.

BERBASIS AKSI

Coba, Bukan Cuma Diskusi

Ide cepat dibuat prototipenya dan diuji ke pengguna nyata, bukan diperdebatkan lama di ruang rapat.

Sekarang kita definisikan istilahnya secara formal. Design Thinking adalah metodologi pemecahan masalah yang berpusat pada manusia, dipopulerkan oleh konsultan desain IDEO dan sekolah desain di Stanford yang disebut d.school. Solusi yang baik menurut kerangka ini harus memenuhi tiga hal sekaligus, yaitu diinginkan oleh manusia, disebut desirability, bisa dibangun dengan teknologi yang tersedia, disebut feasibility, dan layak secara bisnis alias menguntungkan, disebut viability. Tiga sifat pentingnya yang perlu Anda ingat baik-baik, pertama human-centered, solusi selalu mulai dari manusia bukan dari fitur yang terdengar keren, kedua iteratif, artinya tim boleh dan memang sering kembali ke tahap sebelumnya begitu menemukan hal baru, dan ketiga berbasis aksi, artinya ide cepat-cepat dibuat prototipenya dan diuji ke pengguna sungguhan, bukan hanya diperdebatkan berjam-jam di ruang rapat. Istilah desirability, feasibility, dan viability ini akan sering muncul lagi terutama saat kita bicara kelayakan produk di pertemuan-pertemuan berikutnya.

Lima Tahap Design Thinking (Model Stanford d.school)

Bukan tangga lurus ke atas, melainkan siklus yang bisa diulang & dilompat maju-mundur.

Anggap kelima tahap ini sebagai lensa berpikir, bukan urutan wajib. Tim bisa loncat dari Test kembali ke Empathize kalau uji coba menunjukkan pemahaman pengguna masih meleset.

Lihat diagram di layar, ini lima tahap Design Thinking versi Stanford d.school yang akan menjadi kerangka kerja kita sepanjang semester. Dari kiri ke kanan ada Empathize untuk memahami pengguna, Define untuk merumuskan masalah, Ideate untuk menghasilkan ide, Prototype untuk mewujudkan ide jadi bentuk nyata meski kasar, dan Test untuk mengujinya ke pengguna sungguhan. Perhatikan garis putus-putus di atas yang melengkung kembali dari Test ke Empathize, itu menggambarkan sifat iteratif yang tadi kita bahas, tim boleh dan sering kembali ke tahap awal begitu hasil pengujian menunjukkan pemahaman mereka tentang pengguna ternyata masih meleset. Anggaplah kelima tahap ini bukan tangga yang harus dinaiki satu arah, tapi lebih seperti lensa berpikir yang bisa dipakai bergantian sesuai kebutuhan, persis seperti tim developer aplikasi yang terus bolak-balik memperbaiki fitur berdasarkan masukan pengguna setelah rilis.

Bagian 1 dari 3

Empathize & Define

Dua tahap paling sering dilewatkan tim pemula — padahal di sinilah letak fondasi produk yang benar-benar dibutuhkan pengguna.

EMPATHIZE — Memahami Dunia Pengguna Secara Mendalam

Tujuannya bukan mengumpulkan data untuk laporan, tapi membangun pemahaman emosional & kontekstual tentang siapa yang Anda rancang produknya.

YANG DICARI TIM DESAIN

Kebutuhan yang belum diucapkan pengguna sendiri.
Kebiasaan & kendala nyata di lapangan (bukan di ruang rapat).
Emosi: frustrasi, kekhawatiran, kebanggaan saat memakai sesuatu.

JEBAKAN YANG HARUS DIHINDARI

Menganggap diri sendiri (tim) mewakili pengguna.
Bertanya lalu langsung mempertahankan ide sendiri, bukan mendengarkan.
Berhenti riset setelah wawancara 1–2 orang saja.

Istilah kunci: empati di sini berarti kemampuan menempatkan diri di posisi pengguna untuk merasakan masalahnya — bukan sekadar simpati atau kasihan.

Tahap Empathize sering disalahpahami sebagai sekadar mengumpulkan data untuk laporan, padahal tujuan sesungguhnya adalah membangun pemahaman emosional dan kontekstual tentang siapa sebenarnya orang yang produk kita rancang untuknya. Yang dicari tim desain bukan cuma fakta permukaan, tapi kebutuhan yang bahkan belum diucapkan pengguna sendiri, kebiasaan nyata di lapangan yang berbeda dari yang mereka klaim di ruang rapat, dan emosi seperti frustrasi atau kebanggaan saat memakai sesuatu. Ada beberapa jebakan yang sering dijatuhi mahasiswa dan bahkan tim profesional, misalnya menganggap diri sendiri sudah cukup mewakili pengguna, padahal Anda sebagai mahasiswa bisnis digital yang melek teknologi belum tentu mewakili pedagang pasar berusia lima puluh tahun yang baru belajar pakai QRIS. Perlu dicatat istilah empati di sini artinya kemampuan menempatkan diri di posisi pengguna untuk benar-benar merasakan masalahnya, bukan sekadar kasihan sesaat lalu lupa.

Tiga Metode Utama untuk Berempati

Sekilas dulu — detail teknis tiap metode akan kita praktikkan penuh di Pertemuan 3 (Riset Pengguna).

WAWANCARA

Interview Mendalam

Ajukan pertanyaan terbuka ("ceritakan pengalaman Anda...") — hindari pertanyaan tertutup yang cuma dijawab ya/tidak.

OBSERVASI

Amati Langsung

Lihat perilaku asli pengguna di lingkungan sehari-hari — sering berbeda dari yang mereka ceritakan saat diwawancara.

IMMERSION

Alami Sendiri

Tim mencoba langsung menjadi "pengguna" — misalnya berjualan sehari di pasar memakai aplikasi kasir digital.

Prinsip lapangan: "apa yang orang katakan" sering berbeda dengan "apa yang orang lakukan." Karena itu observasi selalu mendampingi wawancara.

Ada tiga metode utama yang biasa dipakai tim desain untuk masuk ke tahap Empathize, dan hari ini kita bahas sekilas dulu karena praktik detailnya akan kita dalami penuh di pertemuan tiga tentang riset pengguna. Pertama wawancara mendalam, kuncinya mengajukan pertanyaan terbuka seperti "ceritakan pengalaman Anda", bukan pertanyaan tertutup yang cuma dijawab ya atau tidak. Kedua observasi, yaitu mengamati langsung perilaku asli pengguna di lingkungan sehari-hari, karena sering kali apa yang orang lakukan berbeda dari apa yang mereka ceritakan saat diwawancara. Ketiga immersion, artinya tim benar-benar mencoba mengalami sendiri posisi pengguna, misalnya tim desainer aplikasi kasir digital berjualan sehari penuh di pasar tradisional untuk merasakan langsung kendalanya. Prinsip lapangan yang harus Anda ingat, apa yang orang katakan sering berbeda dengan apa yang orang lakukan, karena itu observasi selalu mendampingi wawancara, tidak bisa berdiri sendiri.

Langkah demi Langkah — Empathize pada Aplikasi Kasir UMKM

Studi kasus: tim merancang aplikasi kasir digital untuk pedagang pasar tradisional.

ALUR EMPATHIZE

Langkah	Apa yang Dilakukan Tim	Temuan
1. Rencana lapangan	Pilih 8 pedagang pasar Johar Semarang dengan usia & jenis dagangan beragam	Sampel representatif
2. Wawancara	Tanya kebiasaan mencatat transaksi & kendala memakai HP untuk berjualan	Banyak masih pakai buku tulis
3. Observasi	Amati saat pedagang sungguhan melayani 3 pembeli berturut-turut	Tangan sibuk, tak sempat lihat layar lama
4. Sintesis awal	Kumpulkan seluruh catatan & kutipan pengguna ke satu papan bersama	Pola: butuh 1 tombol cepat, bukan menu rumit

Kutipan pengguna nyata (dicatat apa adanya, tanpa disaring): "Saya nggak sempat lihat layar lama-lama, tangan saya harus terus melayani pembeli antre."

Mari kita telusuri contoh nyata langkah demi langkah, kasusnya tim yang merancang aplikasi kasir digital untuk pedagang pasar tradisional, sebut saja studi kasus Pasar Johar Semarang. Langkah pertama, tim merencanakan lapangan dengan memilih delapan pedagang yang beragam usia dan jenis dagangannya, supaya sampelnya representatif bukan cuma satu jenis pedagang saja. Langkah kedua, wawancara tentang kebiasaan mencatat transaksi, dan ternyata banyak yang masih memakai buku tulis manual meski sudah punya HP. Langkah ketiga, observasi langsung saat pedagang melayani tiga pembeli berturut-turut, dan tim menyadari tangan pedagang selalu sibuk sehingga tidak sempat melihat layar HP terlalu lama. Langkah keempat, tim mengumpulkan seluruh catatan dan kutipan pengguna ke satu papan bersama, sampai muncul pola jelas bahwa pedagang butuh satu tombol cepat, bukan menu yang rumit. Perhatikan kutipan pengguna di kotak bawah, kalimat seperti itu, dicatat apa adanya tanpa disaring atau diperhalus, justru menjadi bahan paling berharga untuk tahap Define berikutnya.

DEFINE — Merumuskan Masalah yang Tepat Sasaran

Ubah tumpukan temuan Empathize menjadi satu rumusan masalah tajam yang mengarahkan seluruh ide berikutnya.

[PENGGUNA] butuh [KEBUTUHAN] karena [WAWASAN/INSIGHT]

CONTOH POINT OF VIEW (POV) STATEMENT

"Pedagang pasar berusia 40–60 tahun butuh cara mencatat transaksi yang tidak menyita perhatian dari pembeli karena tangan & mata mereka harus tetap fokus melayani antrean, bukan menatap layar HP."

POV yang baik spesifik & bisa diukur — bukan "aplikasi harus user-friendly" (terlalu umum, tidak mengarahkan ide apa pun).

Setelah tahap Empathize menghasilkan tumpukan data mentah berupa catatan wawancara, observasi, dan kutipan pengguna, tahap Define bertugas mengubah semua itu menjadi satu rumusan masalah yang tajam, yang akan mengarahkan seluruh proses ideasi berikutnya. Formatnya sederhana, ada tiga bagian, pengguna spesifik, kebutuhan yang mereka miliki, dan wawasan atau insight yang menjelaskan kenapa kebutuhan itu muncul. Lihat contoh di layar, rumusan itu menyebutkan pedagang pasar berusia empat puluh sampai enam puluh tahun, kebutuhan mereka adalah cara mencatat transaksi yang tidak menyita perhatian dari pembeli, dan alasannya karena tangan dan mata mereka harus tetap fokus melayani antrean. Perhatikan betapa spesifiknya rumusan ini dibanding kalimat umum seperti "aplikasi harus user-friendly," yang terdengar bagus tapi sebenarnya tidak mengarahkan tim ke ide konkret apa pun karena semua orang bisa setuju tanpa tahu harus membangun apa. Rumusan seperti ini disebut Point of View statement, dan akan kita latih lebih dalam di pertemuan empat.

Dari POV ke Pertanyaan Pembuka Ide: How Might We

POV yang sudah tajam diubah jadi pertanyaan optimis yang membuka ruang ide — teknik How Might We (HMW).

DARI POV

Pedagang butuh cara cepat mencatat transaksi

Rumusan masalah tajam hasil tahap Define sebelumnya.

MENJADI HMW

"Bagaimana caranya kita membuat pencatatan transaksi tidak butuh mata & tangan penuh?"

Pertanyaan terbuka, tidak mengarah ke satu solusi — siap dijawab banyak ide berbeda di tahap Ideate.

HMW sengaja dibuat tidak terlalu sempit (baru satu solusi) dan tidak terlalu luas (kembali jadi masalah umum). Detail teknik ini akan kita latih penuh minggu depan.

Setelah rumusan masalah dalam bentuk POV statement selesai, langkah selanjutnya sebelum benar-benar berimajinasi mencari ide adalah mengubahnya menjadi pertanyaan pembuka yang disebut How Might We, sering disingkat HMW. Lihat contoh di layar, POV kita tadi tentang pedagang yang butuh cara cepat mencatat transaksi, diubah menjadi pertanyaan "bagaimana caranya kita membuat pencatatan transaksi tidak butuh mata dan tangan penuh," pertanyaan ini sengaja dibuat terbuka, tidak langsung mengarah pada satu solusi tunggal seperti "bagaimana caranya kita membuat tombol besar," supaya ruang untuk ide tetap luas. Ada keseimbangan yang perlu dijaga, HMW tidak boleh terlalu sempit sehingga seolah sudah menyiratkan satu jawaban saja, tapi juga tidak boleh terlalu luas sehingga kembali menjadi masalah umum yang sulit dicari solusinya. Teknik menyusun HMW yang baik, termasuk variasi-variasinya, akan kita latih penuh di pertemuan empat bersamaan dengan teknik ideasi Crazy 8's.

Bagian 2 dari 3

Ideate, Prototype & Test

Dari ledakan ide sampai bukti nyata di tangan pengguna — tiga tahap yang mengubah rumusan masalah menjadi solusi teruji.

Ideate Prototype Test

IDEATE — Divergen Dulu, Konvergen Kemudian

Tujuannya menghasilkan sebanyak mungkin ide sebelum memilih yang terbaik — kuantitas dulu, kualitas belakangan.

FASE DIVERGEN (MELEBAR)

Curah gagasan bebas — tunda penilaian, jangan langsung mengkritik ide.
Semakin "liar" ide, semakin baik — bisa disaring belakangan.
Target: puluhan ide, bukan 2–3 ide "aman".

FASE KONVERGEN (MENYEMPIT)

Kelompokkan ide serupa, lalu pilih berdasarkan dampak & kelayakan.
Libatkan kembali data dari tahap Empathize sebagai penyaring.
Hasil akhir: 2–3 ide terkuat untuk dilanjutkan ke Prototype.

Kesalahan umum: tim langsung mengevaluasi tiap ide begitu diucapkan. Itu mematikan ide liar yang justru sering jadi terobosan terbaik.

Tahap Ideate ini yang paling sering dibayangkan orang saat mendengar kata "brainstorming," tapi ada aturan mainnya supaya efektif. Tahap ini terbagi dua fase, pertama fase divergen atau melebar, di sini aturan utamanya adalah menunda penilaian, jangan langsung mengkritik ide begitu diucapkan, karena semakin liar sebuah ide justru semakin baik sebab bisa disaring belakangan, targetnya puluhan ide bukan cuma dua atau tiga ide yang terasa aman. Fase kedua adalah konvergen atau menyempit, di sini tim mengelompokkan ide-ide serupa lalu memilih berdasarkan dampak dan kelayakan, dengan tetap melibatkan kembali data dari tahap Empathize sebagai penyaring supaya pilihan tidak asal comot, hasil akhirnya biasanya dua sampai tiga ide terkuat yang siap dilanjutkan ke Prototype. Kesalahan umum yang sering terjadi di kelas maupun tim kerja nyata adalah langsung mengevaluasi tiap ide begitu diucapkan seseorang, padahal itu justru mematikan ide liar yang sering kali menjadi terobosan terbaik, mirip bagaimana ide awal GoJek yang terdengar "aneh" saat pertama kali diusulkan justru jadi terobosan besar.

PROTOTYPE — Wujudkan Ide Secepat & Semurah Mungkin

Prinsip: "fail fast, fail cheap" — lebih baik gagal di atas kertas daripada gagal setelah aplikasi jadi.

LOW-FIDELITY

Sketsa Kertas

Dibuat dalam hitungan menit, murah, mudah dicoret ulang. Cocok untuk menguji alur, bukan tampilan detail.

HIGH-FIDELITY

Mockup Digital Interaktif

Dibuat setelah alur teruji, mendekati produk asli (warna, teks, interaksi klik). Cocok untuk uji tampilan & detail.

Aturan emas: jangan lompat ke high-fidelity sebelum alur dasarnya teruji lewat sketsa murah. Detail visual (Gestalt, warna, tipografi) baru kita bahas mendalam paruh kedua semester.

Tahap Prototype adalah saatnya mewujudkan ide terpilih menjadi sesuatu yang bisa dipegang dan dicoba, dengan prinsip yang sering disebut "fail fast, fail cheap," artinya lebih baik gagal di atas selembar kertas yang harganya nyaris nol daripada gagal setelah aplikasi selesai dibangun dan menghabiskan jutaan rupiah biaya pengembangan. Ada dua tingkat kematangan prototipe yang disebut fidelity, low-fidelity berupa sketsa kertas yang dibuat dalam hitungan menit, murah, dan mudah dicoret ulang, cocok untuk menguji alur secara kasar bukan tampilan detailnya. High-fidelity berupa mockup digital interaktif yang mendekati produk asli lengkap dengan warna, teks, dan interaksi klik, tapi ini baru dibuat setelah alur dasarnya sudah teruji lewat sketsa murah tadi. Aturan emasnya, jangan pernah lompat langsung ke high-fidelity sebelum alur dasarnya diuji, karena kalau ternyata alurnya salah, Anda sudah terlanjur membuang waktu berjam-jam mendesain detail visual yang percuma. Detail visual seperti prinsip Gestalt, psikologi warna, dan tipografi akan kita bahas mendalam di paruh kedua semester.

Langkah demi Langkah — dari Sketsa ke Uji Coba Nyata

Lanjutan studi kasus aplikasi kasir UMKM: dari ide terpilih sampai diuji ke pedagang pasar sungguhan.

ALUR PROTOTYPE & TEST

Langkah	Apa yang Dilakukan Tim	Hasil
1. Sketsa kertas	Gambar 3 alternatif tata letak layar "terima bayar" dengan pena & kertas	Selesai dalam 20 menit
2. Uji alur cepat	Minta 3 pedagang menunjuk alur mana yang paling masuk akal	1 alur unggul jelas
3. Mockup digital	Alur pemenang dibuat mockup interaktif (klik-tap) di aplikasi desain	Prototipe siap diuji
4. Usability test	Think-aloud: 5 pedagang mencoba sambil bersuara apa yang dipikirkan	2 titik kebingungan ditemukan → kembali ke Ideate

Angka 5 partisipan bukan sembarang — riset klasik Jakob Nielsen menunjukkan 5 pengguna sudah cukup menemukan ~85% masalah usability utama.

Sekarang kita lanjutkan studi kasus aplikasi kasir UMKM yang sama, dari ide yang sudah terpilih sampai benar-benar diuji ke pedagang pasar sungguhan. Langkah pertama, tim membuat tiga alternatif sketsa layar terima bayar dengan pena dan kertas saja, selesai dalam dua puluh menit, sangat murah dan cepat. Langkah kedua, ketiga sketsa itu ditunjukkan ke tiga pedagang untuk melihat alur mana yang paling masuk akal bagi mereka, dan ternyata satu alur jelas lebih unggul dibanding dua lainnya. Langkah ketiga, alur pemenang tadi baru dibuat menjadi mockup digital interaktif yang bisa diklik dan ditap, menggunakan aplikasi desain, sehingga terasa seperti aplikasi sungguhan meski di baliknya belum ada kode pemrograman. Langkah keempat, dilakukan usability test dengan teknik think-aloud, artinya lima pedagang mencoba mockup itu sambil mengucapkan apa yang mereka pikirkan, dan dari situ ditemukan dua titik kebingungan yang membuat tim harus kembali ke tahap Ideate untuk mencari solusi baru. Angka lima partisipan ini bukan sembarang angka, riset klasik dari pakar usability Jakob Nielsen menunjukkan lima pengguna saja sudah cukup untuk menemukan sekitar delapan puluh lima persen masalah usability utama, jadi tidak perlu menguji ke ratusan orang sekaligus.

TEST — Uji ke Pengguna, Lalu Ulangi Siklusnya

Tujuan Test bukan membuktikan ide kita benar, tapi menemukan di mana ide kita masih salah — sedini mungkin.

Test bisa mengirim tim kembali ke mana saja — Empathize (pemahaman meleset), Define (masalahnya salah rumus), Ideate (idenya kurang tepat), atau Prototype (eksekusinya yang perlu diperbaiki).

Tahap Test sering disalahpahami sebagai "pembuktian bahwa ide kita bagus," padahal tujuan sesungguhnya justru sebaliknya, yaitu menemukan di mana ide kita masih salah, sedini dan semurah mungkin, sebelum uang dan waktu terlanjur habis. Lihat diagram di layar, tahap Test bisa mengirim tim kembali ke mana saja tergantung jenis masalah yang ditemukan. Kalau ternyata pemahaman terhadap pengguna yang meleset, tim kembali ke Empathize untuk riset ulang. Kalau rumusan masalahnya yang kurang tepat, tim kembali ke Define untuk merumuskan ulang POV statement. Kalau masalahnya sudah benar tapi solusi yang dipilih kurang pas, tim kembali ke Ideate untuk mencari ide lain. Dan kalau ide sudah tepat tapi eksekusi prototipenya yang membingungkan pengguna, tim cukup kembali ke Prototype untuk memperbaiki detail interaksinya saja. Inilah kenapa dari awal kita tekankan Design Thinking bukan proses satu arah, melainkan siklus yang terus berputar sampai solusinya benar-benar pas dengan kebutuhan pengguna, mirip bagaimana aplikasi seperti BCA mobile terus memperbarui fiturnya berdasarkan masukan nasabah dari waktu ke waktu.

Bagian 3 dari 3

Studi Kasus & Praktik Kelas

Melihat kelima tahap bekerja bersama pada produk digital Indonesia, lalu mencobanya sendiri.

Studi Kasus: Evolusi Fitur "Pesan Instan" Ojek Online

Bagaimana fitur pemesanan ojek daring di Indonesia berkembang lewat siklus Design Thinking selama bertahun-tahun.

EMPATHIZE + DEFINE

Tim mengamati: penumpang bingung menjelaskan lokasi via telepon ke tukang ojek pangkalan.
POV: pengguna butuh cara memesan tanpa perlu menjelaskan lokasi secara lisan.

IDEATE + PROTOTYPE + TEST

Ide: pakai titik GPS otomatis menggantikan deskripsi lisan.
Prototipe awal diuji ke pengguna & driver — ditemukan masalah baru: sinyal GPS lemah di gang sempit.
Iterasi: tambah fitur chat & telepon dalam aplikasi sebagai cadangan.

Fitur "titik jemput otomatis + chat cadangan" yang kini terasa biasa saja, lahir dari berulang kali melewati siklus Empathize–Test, bukan sekali jadi.

Mari kita lihat contoh nyata bagaimana kelima tahap ini bekerja bersama dalam produk yang mungkin Anda pakai setiap hari, yaitu evolusi fitur pemesanan pada aplikasi ojek daring di Indonesia. Pada tahap Empathize dan Define, tim mengamati bahwa penumpang sering kebingungan menjelaskan lokasi mereka secara lisan lewat telepon kepada tukang ojek pangkalan, sehingga muncul rumusan masalah bahwa pengguna butuh cara memesan tanpa perlu menjelaskan lokasi secara lisan. Pada tahap Ideate, Prototype, dan Test, muncul ide memakai titik GPS otomatis untuk menggantikan deskripsi lisan, prototipe awal ini diuji ke pengguna dan pengemudi, dan ditemukan masalah baru yaitu sinyal GPS sering lemah di gang-gang sempit perumahan padat, sehingga tim melakukan iterasi dengan menambahkan fitur chat dan telepon dalam aplikasi sebagai cadangan. Fitur gabungan titik jemput otomatis dan chat cadangan yang sekarang terasa biasa saja dan kita anggap remeh, sebenarnya lahir dari berulang kali melewati siklus Empathize sampai Test, bukan sekali jadi langsung sempurna, ini contoh sempurna dari sifat iteratif Design Thinking yang kita bahas sejak awal pertemuan.

Latihan Kelas & Ringkasan Pertemuan 2

LATIHAN KELOMPOK (15 MENIT)

Bentuk kelompok 3–4 orang, pilih 1 aplikasi kampus/UMKM yang sering bermasalah.
Tuliskan 1 POV statement berdasarkan dugaan masalah pengguna (boleh asumsi awal).
Ubah POV itu menjadi 1 kalimat How Might We.
Siapkan untuk dibahas singkat sebelum kelas berakhir.

RINGKASAN 5 TAHAP

Empathize — pahami pengguna lewat wawancara, observasi, immersion.
Define — rumuskan masalah tajam via POV & How Might We.
Ideate — divergen dulu (banyak ide), baru konvergen (pilih terbaik).
Prototype — mulai dari low-fidelity, murah & cepat gagal.
Test — uji ke pengguna nyata, siap kembali ke tahap mana pun.

Minggu depan (Pertemuan 3): kita bedah tuntas metode riset pengguna — persona, empathy map, journey map, dan etika riset.

Sebagai penutup, mari kita praktikkan langsung apa yang sudah dipelajari lewat latihan kelompok singkat. Silakan bentuk kelompok tiga sampai empat orang, pilih satu aplikasi kampus atau aplikasi UMKM di sekitar Anda yang menurut pengamatan sering bermasalah, misalnya sistem KRS daring atau aplikasi antrean di kantin, lalu tuliskan satu rumusan POV statement berdasarkan dugaan masalah pengguna, boleh berupa asumsi awal karena kita belum sempat riset lapangan sungguhan hari ini, kemudian ubah POV itu menjadi satu kalimat How Might We, dan siapkan untuk dibahas singkat sebelum kelas berakhir. Sebelum kita tutup, mari rangkum lagi lima tahap yang sudah kita pelajari, Empathize untuk memahami pengguna, Define untuk merumuskan masalah tajam, Ideate untuk menghasilkan banyak ide sebelum menyaring, Prototype untuk mewujudkan ide secara murah dan cepat, dan Test untuk mengujinya ke pengguna nyata sambil siap kembali ke tahap mana pun kalau diperlukan. Minggu depan di pertemuan tiga, kita akan membedah tuntas metode riset pengguna, termasuk cara membuat persona, empathy map, journey map, dan etika riset yang harus Anda patuhi saat mewawancarai orang sungguhan. Sampai jumpa minggu depan.