Tutorial Design Thinking Lengkap dengan Studi Kasus

Pelajari lima tahap Design Thinking melalui studi kasus aplikasi KosKu: riset pengguna, empathy map, persona, ide solusi, wireframe, prototipe, dan usability testing, lengkap dengan contoh artefak setiap tahap.

PANDUAN PRAKTIK • DESIGN THINKING • UI/UX • STUDI KASUS

Materi ini ditujukan bagi mahasiswa, pengajar, UI/UX designer, product manager, dan pengembang perangkat lunak. Setiap tahap disertai aktivitas, contoh instrumen, artefak, prompt AI opsional, hasil yang diharapkan, checkpoint, serta kesalahan yang perlu dihindari. Anda juga memperoleh prototipe HTML interaktif dan worksheet untuk latihan.

1. Apa Itu Design Thinking?

Design Thinking adalah pendekatan pemecahan masalah yang berpusat pada manusia dengan menggabungkan pemahaman kebutuhan pengguna, eksplorasi alternatif solusi, pembuatan prototipe, dan pembelajaran dari pengujian. Stanford d.school mengenalkan lima mode yang populer: Empathize, Define, Ideate, Prototype, Test. Mode bukan tahapan kaku yang wajib selalu berjalan satu arah. Stanford d.school — Design Thinking Bootleg.

Model yang juga sering digunakan adalah Double Diamond dari Design Council: Discover, Define, Develop, Deliver. Kedua model dapat dipahami sebagai cara memperluas penelusuran masalah/solusi (divergen), lalu memilih fokus berbasis bukti (konvergen). Double Diamond juga menekankan iterasi, bukan resep mekanis. Design Council — Double Diamond.

Catatan: pemetaan di atas bersifat konseptual, bukan kesetaraan tahap satu-banding-satu. Dalam praktik, proses dapat kembali ke tahap sebelumnya ketika ditemukan asumsi yang keliru.

2. Studi Kasus: Merancang Aplikasi KosKu

Bayangkan sekelompok mahasiswa ingin merancang layanan digital untuk penghuni kos. Mereka awalnya mengusulkan aplikasi yang menyediakan seluruh fitur: pencarian kos, pembayaran, obrolan, pemesanan fasilitas, dan keluhan. Tetapi tim belum tahu persoalan mana yang paling penting.

Tujuan pembelajaran akhir: pembaca mampu (1) menyiapkan riset, (2) merumuskan masalah berdasarkan data, (3) menghasilkan alternatif solusi, (4) membuat prototipe, dan (5) mengevaluasi kemudahan tugas dengan bukti pengamatan. Hasil akhirnya berupa clickable prototype KosKu dengan fitur contoh: rincian tagihan, laporan fasilitas, dan riwayat laporan.

3. Tools dan Persiapan Kerja

Gunakan alat hanya sesuai kebutuhan tahapnya. Dokumen dan spreadsheet membantu pencatatan riset; papan kolaborasi membantu menyusun insight; editor prototipe membantu menggambarkan interaksi; dan browser digunakan untuk menguji prototipe HTML. Kebutuhan alat dapat berbeda menurut tim, sehingga tidak semua layanan harus dipasang sekaligus.

3.1 Struktur folder yang perlu disiapkan

Unduh paket pendamping di bagian akhir artikel. Ekstrak ZIP, lalu siapkan folder sebagaimana berikut. Anda tidak memerlukan Node.js, Python, database, atau koneksi server untuk mencoba prototipe HTML.

design-thinking-kosku/
├── README_MULAI_DI_SINI.md
├── template_wawancara.md
├── template_artefak_design_thinking.md
├── template_pengujian.csv
├── rencana_kegiatan_5_hari.md
├── prototipe_kosku.html
└── ilustrasi_*.png

1. Unduh ZIP dari tautan bagian akhir artikel.
2. Ekstrak ZIP ke folder yang mudah ditemukan.
3. Buka README_MULAI_DI_SINI.md untuk memahami fungsi setiap file.
4. Klik dua kali prototipe_kosku.html; browser akan menampilkan simulasi KosKu.
5. Jika ingin mengedit, buka folder menggunakan VS Code → File → Open Folder. Pilih file HTML, ubah teks, simpan, lalu muat ulang browser.
6. Siapkan lembar wawancara, dokumen artefak, dan template CSV sebelum melakukan riset nyata.

4. Tahap 1 — Empathize: Memahami Pengguna

Contoh artefak visual tahap Empathize

Pada tahap empathize, fokus utama bukan membuat solusi, melainkan menangkap realitas pengguna secara apa adanya. Artefak yang baik harus memperlihatkan bukti lapangan, kutipan nyata, perilaku, dan emosi pengguna.

Apa yang divisualisasikan?

• Ringkasan wawancara: siapa yang diwawancarai, tujuan, dan temuan kunci.
• Empathy map: apa yang pengguna katakan, pikirkan, lakukan, dan rasakan.
• Pemisahan antara bukti, asumsi, dan interpretasi agar tim tidak terburu-buru menyimpulkan.

Mengapa artefak ini penting?

• Membantu tim menyamakan pemahaman sebelum masuk ke tahap define.
• Mencegah bias “kita sudah tahu masalahnya”.
• Menjadi dasar yang dapat dirujuk ketika nanti memilih fitur.

Format artefak

Catatan wawancara, empathy map, foto observasi, highlight kutipan.

Contoh insight

Penghuni kos cemas karena informasi tagihan tersebar di chat dan mudah terlupa.

Output keputusan

Tim memprioritaskan masalah kejelasan tagihan dan status laporan fasilitas.

Tujuan: memahami aktivitas, tujuan, emosi, kendala, dan konteks pengguna dari pengalaman yang mereka ceritakan/unjukkan. Jangan langsung meminta pengguna menyetujui fitur yang sudah dibuat tim.

Langkah 1 — Susun pertanyaan penelitian

Contoh pertanyaan: “Bagaimana penghuni kos mengetahui nominal tagihan, memeriksa detail biaya, dan mengatasi fasilitas bermasalah?” Pecah menjadi fokus informasi biaya, komunikasi pengelola, dan pelacakan keluhan.

Langkah 2 — Rekrut dan minta persetujuan

Untuk latihan kualitatif awal, tim dapat merencanakan 5–8 sesi wawancara eksploratif dengan variasi pengalaman tinggal; ini adalah rencana praktikum, bukan jaminan saturasi atau representativitas. Jelaskan tujuan, kerahasiaan, lama sesi, perekaman jika ada, hak menolak/berhenti, dan cara penyimpanan data. Hindari menyimpan data pribadi yang tidak diperlukan.

Langkah 3 — Wawancara berbasis kejadian nyata

Gunakan pertanyaan terbuka seperti: “Ceritakan terakhir kali Anda mengetahui tagihan kos”, “Apa yang Anda lakukan ketika keran kamar bermasalah?”, dan “Bagaimana Anda tahu perbaikan telah selesai?”. Lanjutkan dengan pertanyaan penelusur: “Bisa beri contoh?” dan “Apa yang terjadi setelah itu?”.

Langkah 4 — Observasi dan pisahkan bukti dari asumsi

Langkah 5 — Buat empathy map

Bagi catatan menjadi Says, Thinks, Does, Feels. Kolom Says/Does sebaiknya diisi bukti langsung; Thinks/Feels adalah inferensi sementara yang perlu diberi label dan divalidasi. Hindari menganggap setiap perasaan sebagai fakta hanya karena tim menduganya.

Hasil tahap Empathize: daftar peserta tersamarkan, persetujuan, catatan observasi, kutipan dengan ID, kelompok temuan awal, dan daftar asumsi. Checkpoint: setiap insight memiliki bukti yang dapat ditelusuri.

5. Tahap 2 — Define: Merumuskan Masalah

Contoh artefak visual tahap Define

Tahap define merangkum data kualitatif menjadi rumusan masalah yang tajam. Di sini tim mulai berpindah dari kumpulan data mentah menuju fokus masalah yang layak diselesaikan.

Elemen inti artefak define

• Persona ringkas berbasis pola, bukan tokoh fiktif tanpa dasar data.
• Point of View (POV) yang menyatakan siapa pengguna, kebutuhannya, dan alasan kebutuhannya.
• How Might We (HMW) untuk membuka ruang ide tanpa mengunci satu solusi sejak awal.

Cara membacanya

• Persona membantu tim mengingat fokus pengguna utama.
• POV merumuskan inti persoalan dengan bahasa yang lebih operasional.
• HMW mengubah problem statement menjadi peluang desain yang bisa diideasi.

Format artefak

Persona, POV statement, HMW list, problem framing board.

Contoh insight

Nadia membutuhkan cara terstruktur melihat tagihan dan melaporkan masalah karena informasi saat ini tersebar dan tidak jelas statusnya.

Output keputusan

Masalah utama difokuskan pada transparansi tagihan dan keterlacakan laporan.

Tujuan: mengubah catatan riset yang tersebar menjadi masalah desain yang spesifik, penting, dan tidak mengunci solusi sejak awal.

Langkah 6 — Affinity mapping

Setelah wawancara, jangan langsung menghitung frekuensi jawaban sebagai keputusan desain. Kelompokkan terlebih dahulu bukti pengalaman yang memiliki pola serupa. Aktivitas ini disebut affinity mapping; setiap kesimpulan harus tetap dapat ditelusuri ke catatan sumbernya.

1. Tulis satu observasi/kutipan per sticky note dan beri ID sumber, misalnya P-01/Q-04.
2. Kelompokkan catatan yang memiliki makna serupa tanpa menamai cluster terlalu cepat.
3. Diskusikan nama tema: “kejelasan biaya”, “status penyelesaian”, dan “riwayat bukti”.
4. Catat perbedaan pengalaman, bukan hanya temuan mayoritas.
5. Rumuskan insight dan tautkan ke ID bukti asalnya.

Langkah 7 — Susun persona berbasis pola

Langkah 8 — Susun journey map

Langkah 9 — Tulis Point of View (POV)

Langkah 10 — Ubah POV menjadi How Might We (HMW)

HMW terarah: “Bagaimana kita dapat membantu penghuni kos mengetahui progres penanganan masalah fasilitas tanpa harus menanyakan status berulang kali?”

HMW yang terlalu luas (“Bagaimana membuat kos lebih baik?”) sulit dipakai untuk ideasi; terlalu sempit (“Bagaimana menambah tombol status merah?”) mengunci solusi sejak awal.

Checkpoint: ada POV, HMW, dan bukti yang mendasari rumusannya. Jika kutipan tidak mendukung problem statement, kembali ke Empathize.

6. Tahap 3 — Ideate: Menghasilkan Alternatif Solusi

Contoh artefak visual tahap Ideate

Pada tahap ideate, tim menghasilkan banyak kemungkinan solusi terlebih dahulu sebelum menyempitkan pilihan. Artefak visual yang baik harus menunjukkan keluasan ide dan logika prioritasnya.

Yang harus terlihat

• Backlog ide atau sticky notes hasil brainstorming.
• Pemisahan antara ide utama, ide pendukung, dan ide masa depan.
• Matriks prioritas seperti impact–effort untuk memilih MVP secara transparan.

Nilai praktisnya

• Tim tidak terjebak pada satu ide pertama yang terasa menarik.
• Keputusan prioritas dapat dipertanggungjawabkan kepada pemangku kepentingan.
• Artefak memudahkan transisi dari diskusi ke pemilihan scope prototipe.

Format artefak

Idea backlog, crazy 8, impact–effort matrix, voting dots.

Contoh insight

Fitur “dashboard tagihan”, “pengingat jatuh tempo”, dan “status laporan” memberi dampak tinggi dengan upaya yang masih realistis.

Output keputusan

Scope MVP KosKu difokuskan pada empat fitur inti agar prototipe tetap ringan.

Tujuan: menjajaki beberapa cara memecahkan masalah sebelum memutuskan fitur. Gunakan brainwriting atau Crazy 8s untuk mendorong keragaman gagasan, lalu evaluasi bersama.

Langkah 11 — Hasilkan minimal 10 alternatif (contoh sintetis)

Pada tahap ideasi, tujuan pertama adalah memperluas kemungkinan solusi. Tim tidak harus langsung memilih aplikasi seluler; beberapa kendala mungkin dapat diselesaikan dengan prosedur komunikasi yang lebih sederhana. Setelah pilihan terkumpul, barulah evaluasi dilakukan.

Langkah 12 — Prioritaskan secara transparan

Tentukan kriteria bersama: dampak pada tugas pengguna, kelayakan teknis, biaya, risiko privasi, dan ketergantungan pada pengelola. Skor 1–5 dalam latihan ini boleh dipakai untuk diskusi, tetapi merupakan penilaian tim yang subjektif, bukan hasil statistik. Untuk MVP prototipe dipilih tiga kemampuan yang bisa diuji: melihat rincian tagihan, membuat laporan, dan menemukan riwayat/status.

Checkpoint: tersedia daftar alternatif dan alasan pemilihan konsep; tim tidak langsung memilih ide karena terlihat paling menarik.

7. Tahap 4 — Prototype: Mewujudkan Solusi

Contoh artefak visual tahap Prototype

Tahap prototype mengubah ide prioritas menjadi bentuk yang bisa dicoba pengguna. Artefak pada tahap ini harus membantu tim menguji alur, isi informasi, dan kejelasan antarmuka dengan cepat.

Komponen artefak prototype

• Task flow: urutan tindakan pengguna dari tujuan ke hasil.
• Wireframe: susunan elemen layar tanpa fokus berlebihan pada estetika.
• Clickable prototype: simulasi interaksi untuk uji cepat sebelum implementasi penuh.

Mengapa dibuat sederhana?

• Prototype low-fidelity lebih murah untuk direvisi.
• Tim bisa fokus pada kegunaan, bukan detail warna atau visual akhir.
• Perubahan besar masih mungkin dilakukan tanpa biaya pengembangan tinggi.

Format artefak

Task flow, wireframe, storyboard layar, prototype HTML/Figma.

Contoh insight

Empat layar inti KosKu: Beranda, Tagihan, Lapor, dan Status.

Output keputusan

Asumsi yang diuji: pengguna dapat melapor kerusakan dan memantau status tanpa bantuan moderator.

Tujuan: membuat representasi solusi yang cukup nyata untuk diuji, bukan langsung membangun aplikasi produksi. Mulai dengan sketsa atau wireframe, lalu lanjutkan ke clickable prototype.

Langkah 13 — Definisikan tiga task flow

Prototipe sebaiknya dibangun berdasarkan tugas yang ingin diselesaikan pengguna, bukan sekadar daftar layar. Task flow membantu memastikan bahwa setiap perpindahan layar punya tujuan yang jelas dan dapat diuji.

1. T1—Cek tagihan: Beranda → Tagihan → Baca rincian dan status.
2. T2—Laporkan fasilitas: Lapor → Pilih kategori → Isi deskripsi → Kirim → Lihat status.
3. T3—Temukan riwayat: Riwayat → Buka daftar laporan → Identifikasi status.

Langkah 14 — Buat wireframe

Di Figma: klik New design file → Frame → Phone, buat frame Beranda, Tagihan, Lapor, dan Riwayat. Tambahkan tombol, teks, serta komponen formulir. Pada tab Prototype, sambungkan tombol ke frame tujuan menggunakan interaksi On click → Navigate to. Klik Present untuk mencoba. Istilah menu dapat berbeda menurut pembaruan produk.

Langkah 15 — Jalankan prototipe HTML pendamping

Alternatif tanpa akun Figma: unduh prototipe_kosku.html dan buka di Chrome, Firefox, Safari, atau Edge. Klik Tagihan untuk melihat perincian; klik Lapor, pilih kategori, tulis deskripsi minimal 10 karakter, lalu kirim. Anda akan diarahkan ke Riwayat dengan status “Terkirim (simulasi)”.

Langkah 16 — Catat asumsi yang hendak diuji

Hipotesis desain: “Label Tagihan yang terlihat di navigasi membantu pengguna menemukan rincian nominal tanpa bantuan moderator.” Bukti yang dibutuhkan: observasi tugas, waktu, keberhasilan, kesalahan, dan ucapan pengguna. Jangan menilai kemudahan hanya dari komentar “desainnya bagus”.

8. Tahap 5 — Test: Pengujian Usability

Contoh artefak visual tahap Test

Tahap test bertujuan melihat apa yang benar-benar terjadi ketika pengguna mencoba solusi. Artefak visualnya harus mudah dibaca agar tim cepat memahami temuan dan menurunkannya menjadi revisi desain.

Isi artefak pengujian

• Ringkasan peserta, skenario tugas, dan hasil task success.
• Catatan observasi perilaku, kebingungan, dan komentar pengguna.
• Daftar rekomendasi revisi dengan tingkat prioritas atau severity.

Bagaimana memanfaatkannya?

• Temuan diubah menjadi backlog perbaikan desain.
• Tim dapat membandingkan isu paling kritis dan paling sering muncul.
• Hasil uji menjadi dasar untuk iterasi, bukan sekadar dokumentasi.

Format artefak

Usability log, tabel temuan, severity ranking, rekomendasi revisi.

Contoh insight

Sebagian peserta tidak langsung menemukan status laporan dan menganggap tombol kirim terlalu kecil.

Output keputusan

Beranda perlu shortcut status laporan, label diperjelas, dan tombol aksi utama diperbesar.

Pengujian formatif mencari masalah interaksi agar prototipe dapat diperbaiki. Nielsen Norman Group menjelaskan bahwa sekitar lima peserta sering menjadi titik awal yang berguna untuk studi kualitatif formatif, tetapi angka tersebut bukan standar universal dan tidak cukup untuk menyimpulkan performa kuantitatif populasi. Baca How Many Test Users in a Usability Study?.

Langkah 17 — Siapkan protokol uji

Pengujian dilakukan untuk menemukan hambatan penggunaan, bukan membuktikan bahwa rancangan tim sudah benar. Moderator sebaiknya memberikan tugas tanpa menunjukkan langkah penyelesaiannya, lalu mencatat perilaku, hambatan, dan keberhasilan peserta.

1. Tetapkan tujuan, segmen peserta, kriteria inklusi, jumlah peserta, dan metode pencatatan.
2. Minta persetujuan; jelaskan yang diuji adalah desain, bukan kecakapan peserta.
3. Berikan skenario tugas tanpa membocorkan nama menu yang harus diklik.
4. Izinkan peserta mencoba sendiri; moderator boleh meminta mereka mengungkapkan apa yang dipikirkan tanpa mengarahkan pilihan.
5. Catat durasi, penyelesaian, bantuan, error, rute yang dilalui, dan ucapan spontan.
6. Lakukan debrief singkat; prioritaskan masalah berdasarkan bukti dan dampaknya.

Langkah 18 — Tetapkan tugas dan kriteria sebelum sesi

Langkah 19 — Hitung metrik dan dokumentasikan temuan

Task success rate = jumlah tugas yang berhasil / jumlah tugas yang dicoba × 100%. Task time = waktu sejak tugas dibacakan sampai peserta selesai/menyerah sesuai protokol. Error count = jumlah kejadian kesalahan operasional yang definisinya ditetapkan sebelum sesi. Assistance rate = proporsi tugas yang memerlukan bantuan moderator.

Contoh hitungan ilustratif (DATA SINTETIS):
5 peserta × 3 tugas = 15 percobaan tugas
12 tugas selesai tanpa bantuan
Task success rate = 12 / 15 × 100% = 80%

Penting: 80% ini BUKAN hasil uji KosKu,
melainkan contoh cara menghitung.

Untuk pelaporan kualitatif, tampilkan masalah, bukti, dampak tugas, prioritas revisi, dan rencana pengujian ulang. Jangan memberi label hasil “valid”, “efektif”, atau “terbukti” hanya dari contoh simulasi.

9. Contoh Interaksi Prompt–Respons ChatGPT yang Dapat Diikuti

AI dapat menjadi asisten menyusun artefak, tetapi tidak boleh menggantikan suara pengguna. Jangan mengunggah transkrip mentah yang berisi identitas atau informasi sensitif tanpa dasar izin dan kebijakan yang sesuai. Contoh respons berikut adalah simulasi pedagogis, bukan transkrip percakapan model yang diaudit.

Interaksi 1 — Merancang riset pengguna

Tindakan: sesuaikan instrumen dari template_wawancara.md, lakukan tinjauan oleh tim/dosen, lalu gunakan pada wawancara nyata. Hasil: instrumen siap pakai, belum menghasilkan insight.

Interaksi 2 — Mengelompokkan bukti tanpa fabrikasi

Tindakan: periksa setiap klasifikasi AI terhadap catatan asli. Hasil: draft cluster dengan provenance, bukan keputusan final.

Interaksi 3 — Menyusun POV dan HMW

Tindakan: pilih POV/HMW yang paling sesuai bukti. Jangan mengambil HMW hanya karena terdengar kreatif.

Interaksi 4 — Ideasi alternatif, bukan langsung satu fitur

Interaksi 5 — Merancang task flow dan wireframe

Tindakan: implementasikan spesifikasi sebagai wireframe Figma atau gunakan prototipe_kosku.html yang disediakan. Hasil: rangkaian layar yang bisa diuji.

Interaksi 6 — Membuat skenario pengujian

Interaksi 7 — Analisis setelah uji sungguhan

Prinsip utama: respons yang mengakui kurangnya data lebih baik daripada insight yang terdengar meyakinkan tetapi fiktif.

10. Dari Temuan Uji ke Revisi Desain

Setelah sesi sungguhan, buat daftar masalah berdasarkan frekuensi, dampak pada penyelesaian tugas, dan tingkat keparahan. Contoh keputusan berikut juga ilustratif:

Untuk handoff pengembangan perangkat lunak, serahkan artefak: problem statement, persona berbasis riset, journey map, desain layar, task flows, aturan validasi, daftar error state, acceptance criteria, dan backlog. Design Thinking membantu eksplorasi kebutuhan, tetapi tidak menggantikan perancangan arsitektur, security engineering, software testing, atau manajemen proyek.

Contoh acceptance criteria fitur laporan

Given pengguna membuka halaman Lapor
When kategori belum dipilih atau deskripsi < 10 karakter
Then sistem menolak submit dan memberi pesan yang jelas

Given kategori dan deskripsi valid
When pengguna menekan Kirim laporan
Then laporan tampil pada Riwayat
And status awal adalah "Terkirim (simulasi)"

11. Kesalahan yang Sering Terjadi dan Solusinya

Troubleshooting prototipe

• File HTML tampak sebagai teks: periksa ekstensi .html, buka melalui browser, bukan pengolah kata.
• Tombol Kirim tidak bekerja: pilih kategori dan tulis minimal 10 karakter; cek pesan validasi.
• Riwayat hilang: prototipe hanya menyimpan data pada memori sesi, sehingga refresh menghapus data; ini perilaku yang disengaja.
• Ilustrasi tidak tampil di Blogger: editor/template Blogger mungkin menyaring data: URI; unggah file PNG pendamping ke penyimpanan gambar Blogger lalu ganti nilai src dengan URL gambar yang diberikan Blogger.
• CSS bertabrakan: pertahankan pembungkus .acw-article; uji pratinjau di tema Blogger sebenarnya.

12. FAQ — Pertanyaan yang Sering Diajukan

13. Download File Pendamping Design Thinking

14. Referensi Terverifikasi dan Bacaan Lanjutan

1. Stanford d.school. Design Thinking Bootleg. Sumber pengenalan lima mode Design Thinking. Baca sumber resmi.
2. Stanford d.school. (2025). Let's Stop Talking about THE Design Process. Menjelaskan pembelajaran desain tidak perlu dipahami sebagai urutan linear tunggal. Baca artikel.
3. Design Council. The Double Diamond. Penjelasan Discover, Define, Develop, Deliver. Baca sumber resmi.
4. Design Council. Framework for Innovation. Prinsip people-centred, visual, collaboration, dan iteration. Baca sumber resmi.
5. Nielsen, J. (2012). How Many Test Users in a Usability Study? Nielsen Norman Group. Baca artikel.

Ditulis untuk: ariqcahya.com • Topik: Design Thinking, UX Research, Prototyping, Usability Testing • Pembaruan referensi: 30 Oktober 2026 • Status studi kasus: simulasi edukatif, bukan laporan penelitian empiris.

Kembali ke bagian atas ↑