Belajar UX Designer - Jobs-to-be-Done & Problem Framing

#Pendahuluan

Setelah di episode 3 kita mengumpulkan data riset untuk JagaKota, pertanyaan berikutnya adalah: bagaimana mengubah data menjadi arah yang jelas? Inilah topik episode 4: jobs-to-be-done (JTBD) dan problem framing. Dua kerangka ini menjawab dua pertanyaan krusial — apa yang sebenarnya ingin dicapai pengguna? dan masalah apa yang sedang kita selesaikan?

Mengapa penting? Karena kebanyakan produk gagal bukan karena desainnya jelek, tapi karena memecahkan masalah yang salah. JTBD mencegah kita terpaku pada fitur dan kompetitor, sementara problem framing memastikan seluruh tim mendefinisikan masalah dengan cara yang sama.

#Jobs-to-be-Done: Orang "Menyewa" Produk

Konsep JTBD diambil dari kata-kata Clayton Christensen: orang tidak membeli produk — mereka menyewa produk untuk menyelesaikan sebuah pekerjaan. Milkshake tidak dibeli karena enak, tapi karena menyelesaikan pekerjaan "menghilangkan kebosanan perjalanan pagi dan membuat saya kenyang sampai makan siang".

Kerangka JTBD menuntun kita menulis pernyataan dengan struktur standar:

Ketika [situasi/momen], saya ingin [motivasi], supaya saya bisa
[hasil yang diharapkan] (tanpa harus [alternatif yang dihindari]).

Contoh untuk JagaKota:

Ketika saya melihat lubang jalan di rute saya, saya ingin melaporkannya
dengan cepat dan tahu bahwa laporan saya ditangani, supaya saya bisa
lewat dengan aman (tanpa harus menebak-nebak saluran resmi atau
mengeluh di media sosial yang tidak ditindaklanjuti).

Perhatikan: JTBD berbicara tentang momen dan hasil, bukan fitur. Belum ada kata "form", "upload foto", atau "map" — solusi teknis datang belakangan di tahap ideate.

#Problem Statement: Definisi Bersama

Problem statement adalah kalimat ringkas yang menyatukan pengguna, kebutuhan, dan insight riset. Ia jadi titik acuan yang mencegah tim menyimpang. Format yang umum dipakai:

[Nama pengguna] membutuhkan [kebutuhan] karena [insight],
sehingga [dampak yang diharapkan].

Draft untuk JagaKota:

Warga kota yang menghadapi masalah infrastruktur membutuhkan cara
melapor dan memantau status laporan yang transparan, karena laporan
resmi saat ini terasa seperti kotak hitam tanpa kabar lanjutan,
sehingga banyak yang memilih media sosial dan menurunkan kepercayaan
pada pemerintah.

Problem statement yang baik memenuhi tiga syarat: ringkas (satu kalimat), berbasis bukti (bersumber dari riset), dan menyebut dampak (mengapa perlu diselesaikan).

Perbandingan problem statement yang lemah vs kuat:

LEMAH: "Warga perlu aplikasi pelaporan yang lebih baik."
       ← solusi sudah dikunci ("aplikasi"), dampak tidak jelas
 
KUAT: "Warga yang menghadapi masalah infrastruktur membutuhkan
       kejelasan status laporan, karena laporan resmi terasa
       seperti kotak hitam, sehingga kepercayaan pada pemerintah
       menurun dan media sosial jadi saluran utama."
       ← menyebut pengguna, kebutuhan, insight, dan dampak

#Success Metrics: Mengukur, Bukan Berharap

Setelah masalah terdefinisi, tentukan bagaimana kita tahu masalahnya terpecahkan. Metrics yang baik bersifat terukur dan berorientasi perilaku. Untuk JagaKota:

Hindari vanity metric — angka yang bagus di atas kertas tapi tidak menandakan kesuksesan. "100 ribu unduhan" tidak berarti masalah terpecahkan; "80% laporan terselesaikan" lebih berarti.

#Common Pitfalls

• Menulis solusi di problem statement — "membutuhkan aplikasi dengan form sederhana" sudah terjebak di solusi; tulis kebutuhannya, bukan bentuknya.
• Metrik tanpa baseline — tak bisa mengukur kemajuan tanpa angka awal.
• JTBD yang terlalu sempit — "ingin mengisi form alamat" adalah pekerjaan fitur, bukan pekerjaan yang disewa; lihat momen dan hasil, bukan langkah UI.
• Berpindah masalah saat ada ide — problem statement bukan dokumen sakral, tapi jangan diubah hanya karena ide baru terasa keren.

#Penutup

Inti yang harus dibawa pulang:

• Orang "menyewa" produk untuk menyelesaikan pekerjaan — pahami pekerjaannya, bukan fiturnya.
• JTBD menangkap situasi, motivasi, hasil yang diharapkan, dan alternatif yang dihindari.
• Problem statement menyatukan pengguna, kebutuhan, insight, dan dampak dalam satu kalimat.
• Success metrics mengubah harapan menjadi angka yang bisa dievaluasi.

Di episode 5 selanjutnya kita akan membahas information architecture — bagaimana mengorganisasi sitemap, navigasi, dan taxonomy lewat card sorting dan tree testing untuk JagaKota. Pastikan problem statement dan metrics kalian sudah ditulis di notebook, karena keduanya jadi kompas di episode-episode berikutnya!