Design UI/UX

How Might We: Pengertian, Contoh, dan Cara Memakainya dalam UX

Pinterest LinkedIn Tumblr

Kalau kamu sering ikut workshop design thinking, sprint, atau sesi problem framing, kemungkinan besar kamu pernah dengar pertanyaan “How Might We”. Istilah ini sering dipakai, tapi tidak selalu dijelaskan dengan cara yang benar-benar praktis.

Padahal, How Might We atau HMW adalah salah satu cara paling sederhana untuk mengubah masalah yang terasa buntu menjadi ruang eksplorasi yang lebih terbuka. Framework ini membantu tim berhenti fokus pada keluhan mentah, lalu mulai memikirkan peluang solusi.

Kalau kamu bekerja di UX, product design, research, atau innovation team, memahami HMW akan sangat membantu saat kamu ingin merumuskan problem dengan lebih tajam tanpa langsung lompat ke solusi.

Apa Itu How Might We?

How Might We adalah cara membingkai masalah dalam bentuk pertanyaan terbuka. Tujuannya bukan mencari satu jawaban cepat, tapi membuka banyak kemungkinan solusi yang masih relevan dengan problem asli.

Kenapa format ini efektif? Karena HMW punya tiga kualitas penting:

  • “How” mengajak tim berpikir tentang cara
  • “Might” memberi ruang eksplorasi, bukan jawaban mutlak
  • “We” mendorong rasa kolaboratif, bukan kerja sendiri-sendiri

Jadi, daripada berkata:

  • “User sering gagal menyelesaikan onboarding”

Kita bisa mengubahnya menjadi:

  • “How might we membantu user menyelesaikan onboarding tanpa merasa kewalahan?”

Perubahan kecil seperti ini sering membuat diskusi tim jadi jauh lebih produktif.

Salah satu alasan HMW terasa efektif adalah karena ia langsung menggeser fokus dari keluhan ke kemungkinan. Saat sebuah tim bertanya dengan format HMW, ruang diskusi jadi terasa lebih ringan, lebih terbuka, dan lebih mudah mengundang ide dari banyak arah.

planning with use of sticky notes
Photo by Walls.io on Pexels.com

Kenapa How Might We Penting dalam UX dan Design Thinking?

Banyak tim punya data, insight, atau hasil interview user, tapi bingung mengubahnya menjadi arah ide yang jelas. Di titik inilah HMW berguna.

How Might We membantu kamu:

  • mengubah insight menjadi problem statement yang bisa dieksplor
  • menjaga diskusi tetap fokus pada kebutuhan user
  • mencegah tim terlalu cepat mengunci diri pada satu solusi
  • membuat sesi ideation terasa lebih terarah

Dalam praktik design thinking, HMW biasanya muncul setelah tim memahami masalah dan sebelum masuk ke tahap ideation. Jadi fungsinya seperti jembatan antara riset dan eksplorasi solusi.

Ciri HMW yang Bagus

Tidak semua pertanyaan HMW itu bagus. Ada yang terlalu sempit, terlalu luas, atau diam-diam sudah mengunci solusi sejak awal.

HMW yang baik biasanya punya ciri seperti ini:

  • cukup spesifik untuk membahas masalah nyata
  • cukup terbuka untuk memunculkan beberapa ide
  • fokus pada kebutuhan atau hambatan user
  • tidak langsung menyebut satu fitur tertentu sebagai jawaban

Contoh yang kurang bagus:

“How might we add chatbot to landing page?”

    Masalahnya, ini sebenarnya bukan problem framing, tapi solusi yang disamarkan jadi pertanyaan.

    Contoh yang lebih baik:

    “How might we membantu calon user mendapatkan jawaban cepat sebelum mereka memutuskan mendaftar?”

      Versi kedua masih terbuka. Solusinya bisa chatbot, FAQ, live chat, onboarding email, atau hal lain yang lebih tepat.

      Cara Membuat Statement How Might We

      Kalau kamu ingin mulai memakai HMW, cara paling aman adalah mengikuti alur sederhana ini:

      1. Mulai dari insight atau friction yang nyata

      Cari dulu masalah yang benar-benar muncul dari user research, observation, usability test, atau data produk. Jangan mulai dari asumsi internal semata.

      Contoh insight:

      • user baru bingung saat harus memilih template pertama

      2. Cari kebutuhan di balik masalah

      Tanya lagi: user sebenarnya ingin mencapai apa? Hambatan apa yang bikin mereka stuck?

      Di contoh tadi, kebutuhan yang lebih dalam bisa jadi:

      • user ingin cepat mulai tanpa takut salah pilih

      3. Ubah jadi pertanyaan yang terbuka

      Setelah kebutuhan makin jelas, baru ubah ke format HMW.

      Misalnya:

      • “How might we membantu user baru memilih template pertama dengan lebih percaya diri?”

      4. Rapikan supaya tidak terlalu luas atau terlalu sempit

      Kalau pertanyaannya terlalu umum, ide yang keluar jadi kabur. Kalau terlalu sempit, tim malah susah mengeksplor.

      Karena itu, HMW yang bagus biasanya terasa:

      • jelas konteksnya
      • ada arah problem yang spesifik
      • tapi tetap memberi ruang ide

      Contoh How Might We dalam Beberapa Konteks

      Supaya lebih kebayang, ini beberapa contoh HMW yang bisa dipakai di konteks berbeda:

      Product onboarding

      • How might we membantu user memahami value produk dalam 2 menit pertama?

      E-commerce

      • How might we membuat user lebih yakin sebelum checkout produk yang belum pernah mereka beli?

      Education product

      • How might we membantu siswa tetap konsisten belajar meski waktu mereka terbatas?

      Healthcare

      • How might we membuat pasien lebih mudah memahami instruksi setelah konsultasi?

      Format seperti ini berguna karena tim bisa langsung menggunakannya untuk sesi brainstorm, workshop, atau prioritas eksperimen.

      Hubungan How Might We dengan Jobs To Be Done

      How Might We sering jadi lebih kuat kalau dipakai setelah kamu memahami kebutuhan user lewat framework lain seperti Jobs To Be Done.

      JTBD membantu kamu memahami apa yang sebenarnya ingin diselesaikan user. Setelah itu, HMW membantu mengubah pemahaman tersebut menjadi pertanyaan yang siap dieksplor oleh tim.

      Kalau mau dibedakan secara singkat:

      • JTBD membantu memahami kebutuhan inti
      • HMW membantu membuka arah solusi

      Kalau kamu ingin melihat perbandingan dua framework ini dengan lebih jelas, lanjutkan ke artikel perbedaan How Might We dan Jobs To Be Done.

      Kesalahan Umum Saat Memakai HMW

      Ada beberapa jebakan yang cukup sering terjadi saat tim memakai HMW.

      Terlalu cepat mengunci solusi

      Kalau pertanyaannya sudah menyebut fitur tertentu, biasanya itu tanda bahwa framing-nya belum netral.

      Terlalu luas

      Contoh seperti:

      • “How might we membuat pengalaman digital lebih baik?”

      Ini terlalu besar dan sulit dipakai sebagai dasar ideation yang fokus.

      Tidak nyambung ke insight user

      Kalau HMW dibuat tanpa dasar research atau problem yang jelas, hasilnya sering terasa keren di workshop tapi lemah saat dibawa ke eksekusi.

      Kapan Sebaiknya Menggunakan How Might We?

      How Might We paling cocok dipakai saat:

      • tim baru selesai merangkum insight research
      • kamu ingin memulai ideation session
      • problem sudah cukup jelas, tapi solusi belum ingin diputuskan
      • kamu butuh bahasa bersama yang cepat dipahami lintas fungsi

      Di sisi lain, HMW kurang cocok kalau problem dasarnya sendiri belum jelas. Dalam kondisi itu, kamu lebih perlu memperdalam research atau merapikan problem framing dulu.

      HMW dalam Workflow Design yang Lebih Modern

      Di era sekarang, designer makin sering terlibat bukan cuma di output visual, tapi juga di cara tim memahami masalah. Karena itu, skill seperti merumuskan HMW jadi makin relevan.

      Framework ini membantu diskusi tim jadi lebih rapi, terutama saat bekerja bareng PM, researcher, engineer, atau stakeholder non-design. Kalau kamu sedang membangun cara kerja design yang lebih terstruktur, artikel DESIGN.md untuk designer juga layak kamu baca sebagai konteks lanjutan.

      Kesimpulan

      How Might We adalah framework sederhana yang sangat berguna untuk mengubah masalah menjadi peluang eksplorasi. Dengan HMW, kamu bisa membantu tim melihat problem secara lebih terbuka, lebih kolaboratif, dan lebih siap diterjemahkan menjadi ide yang relevan.

      Kalau kamu sering merasa sesi brainstorming berantakan atau terlalu cepat masuk ke solusi, mulai dari HMW bisa jadi langkah kecil yang dampaknya besar.

      Saya Dei, UI/UX Designer yang suka ngulik Figma, design system, AI tools, dan cara kerja desain yang lebih praktis. Blog ini jadi tempat saya menulis ulang pengalaman, catatan belajar, opini, dan eksperimen seputar desain produk, freelance, dan AI. Kadang isinya teknis, kadang reflektif, kadang cuma hasil penasaran yang kebablasan. Portfolio saya bisa dilihat di theprojekts.com