Navigate Ambiguity: Bagaikan Kapten yang Menempa Rute Menembus Kabut

Bagaimana pemimpin product menciptakan arahan, membuat keputusan yang bertanggung jawab, dan menjaga team tetap bergerak ketika kepastian tidak tersedia.

Bagaimana Product designer bergerak secara bertanggung jawab melewati ketidakpastian tanpa menunggu kejelasan yang sempurna.

Sebelum matahari terbit di Labuan Bajo, Ameera bergabung dengan perahu kecil menuju pulau yang hanya dilihatnya di foto.

Laut tenang saat mereka meninggalkan pelabuhan. Tiga puluh menit kemudian, kabut pucat menyelimuti air. Garis pantai menghilang. Perahu-perahu lainnya menjadi bayangan samar, lalu lenyap.

Ameera memandang ke arah kapten. Dia tidak berpura-pura melihat rute lengkapnya. Dia memeriksa kompas, mengurangi kecepatan, mendengarkan mesin, mengamati arus, dan membandingkan posisinya dengan landmark familiar yang muncul selama beberapa detik setiap kalinya.

Dia tidak beku atau gegabah.

“Masih bisakah kamu menemukan pulau itu?” tanya Ameera.

“Saya dapat menemukan arah aman berikutnya,” jawabnya.

design work sering kali dimulai dengan visibilitas seperti itu. Ringkasannya tidak lengkap. Stakeholder tidak setuju. user behavior berubah. Teknologi menciptakan kemungkinan-kemungkinan yang tidak sepenuhnya dipahami oleh siapa pun. Team menginginkan kepastian sebelum bergerak, namun kepastian hanya akan datang dari pergerakan.

Stanford d.school menyebut kemampuan bekerja secara produktif dalam kondisi ini Navigate Ambiguity.

🌫️ Ringkasan Dengan Satu Kalimat Jelas dan Dua Puluh Pertanyaan Tersembunyi

Product team Ameera menerima permintaan untuk “membangun asisten AI untuk dukungan customer.”

Kalimat itu terdengar tegas. Di bawahnya ada banyak pertanyaan yang belum terjawab.

Masalah siapa yang dipecahkan oleh asisten tersebut? Customer menunggu jawaban, agen menangani tugas yang berulang, atau manajer mencoba mengurangi biaya? Jenis permintaan apa yang aman untuk diotomatisasi? Bahasa dan nada apa yang harus dipahaminya? Apa yang akan terjadi jika keadaan tidak menentu? Bagaimana orang mengetahui apakah mereka sedang berbicara dengan seseorang atau suatu sistem? Informasi apa yang dapat diakses asisten?

Leadership team menginginkan roadmap. Persyaratan yang diinginkan teknik. Hukum menginginkan penggunaan data yang pasti. Dukungan customer menginginkan keringanan namun takut kehilangan penilaian dalam kasus-kasus sensitif.

Ameera belum bisa membuat rencana yang jujur dan lengkap karena team belum cukup mengetahui.

Namun, dia dapat membantu mereka memperjelas ambiguitas tersebut.

🗺️ Sebutkan Apa yang Diketahui, Tidak Diketahui, dan Diperebutkan

Ambiguitas menjadi lebih menakutkan ketika setiap ketidakpastian bercampur menjadi satu.

Ameera membuat tiga area di dinding.

Diketahui: Volume dukungan terus meningkat. Pertanyaan status pengiriman membentuk kategori besar yang berulang. Agen menyalin informasi di beberapa alat. Customer tidak suka menunggu pembaruan sederhana.

Tidak diketahui: Seberapa akurat seorang asisten dapat menafsirkan campuran bahasa Indonesia dan ekspresi daerah. Permintaan mana yang dipercaya oleh customer untuk ditangani. Berapa banyak waktu yang sebenarnya dapat dihemat oleh agen.

Diperebutkan: Apakah tujuan utamanya adalah pengurangan biaya, penyelesaian yang lebih cepat, atau dukungan agen yang lebih baik. Apakah asisten harus berbicara langsung dengan customer atau memulai sebagai alat internal.

Memberi nama pada kategori-kategori ini tidak menyelesaikan masalah. Hal ini menghentikan team untuk memperlakukan setiap pernyataan sebagai fakta yang sama.

Beberapa hal yang tidak diketahui memerlukan research. Beberapa memerlukan eksperimen. Beberapa bidang yang diperebutkan memerlukan keputusan kepemimpinan. Beberapa kendala memerlukan feedback ahli.

Ambiguitas menjadi mudah dinavigasi karena memiliki struktur.

🧭 Pilih Arah Tanpa Berpura-pura Itu Tujuannya

Kapten di Labuan Bajo menyesuaikan arah dengan menggunakan sinyal terbaik yang tersedia. Dia tidak menarik garis lurus palsu menembus kabut.

Ameera membantu team memilih arah awal yang terbatas: asisten internal yang membantu agen mengambil informasi pengiriman dan menyusun tanggapan, sekaligus menjaga agen bertanggung jawab mengirimkannya.

Arah ini mengurangi beberapa risiko. Team dapat belajar dari kasus-kasus dukungan nyata, mengamati di mana sistem tidak pasti, dan mempertahankan penilaian manusia. Hal ini juga membuka kemungkinan otomatisasi yang berhubungan dengan customer di kemudian hari.

Keputusan tersebut bukanlah visi product permanen. Itu adalah posisi berikutnya yang bertanggung jawab.

Mengatasi ambiguitas berarti membuat komitmen sementara yang menciptakan pembelajaran tanpa mengunci team ke masa depan yang tidak didukung.

🔦 Bangun Suar Kejelasan Kecil

Ketika keseluruhan situasi tidak jelas, team mendapatkan manfaat dari hal-hal kecil yang dapat mereka percayai.

Team Ameera membuat pernyataan masalah bersama, daftar use case yang dilarang, tinjauan mingguan atas respons yang gagal, dan sebuah prinsip sederhana: ketika kepercayaan diri rendah atau konsekuensinya tinggi, sistem harus membuat ketidakpastian terlihat dan melibatkan seseorang.

Mereka juga mengumpulkan bahasa asli dari percakapan dukungan. Salah satu customer mungkin menulis, “Paketku nyangkut di mana?” Orang lain mungkin bertanya apakah suatu parsel bersifat “muter-muter”. Sistem ini membutuhkan lebih dari sekadar kosakata pengiriman formal.

Setiap sesi research dan prototype menambahkan suar kecil. Team mempelajari pertanyaan mana yang berulang, mana yang memerlukan penilaian emosional, sumber data mana yang dapat diandalkan, dan bagaimana agen ingin saran tersebut muncul.

Kejelasan terakumulasi melalui tindakan.

⚓ Tahan Ketegangan Daripada Menyelesaikannya Terlalu Dini

Proyek yang ambigu mengandung ketegangan yang tidak selalu dapat dioptimalkan menjadi satu jawaban sederhana.

Otomatisasi dapat meningkatkan kecepatan dan mengurangi perawatan pribadi. Lebih banyak akses data dapat meningkatkan jawaban dan meningkatkan risiko privasi. Respons yang percaya diri bisa bermanfaat dan menyembunyikan ketidakpastian. Tinjauan manusia dapat melindungi kualitas dan mengurangi efisiensi yang dijanjikan.

Ameera menolak slogan-slogan seperti “AI first” atau “human first” karena slogan-slogan tersebut mengakhiri percakapan sebelum team memahaminya. Dia menyusun pekerjaan berdasarkan situasi dan konsekuensi.

Untuk perkiraan pengiriman sederhana berdasarkan data yang dapat diandalkan, bantuan otomatis mungkin tepat. Untuk paket berisi obat yang hilang, sistem harus membantu manusia bertindak cepat dan hati-hati. Perbedaannya bergantung pada risiko, konteks, keyakinan, dan user need.

Mengatasi ambiguitas sering kali berarti menahan dua kekhawatiran yang valid dalam waktu yang cukup lama untuk menciptakan hubungan yang lebih baik di antara keduanya.

🌊 Ambiguitas Bukanlah Alasan untuk Penemuan Tanpa Akhir

Ada versi ketidakpastian yang nyaman di mana team terus melakukan research karena pengambilan keputusan terasa berisiko.

Ameera menetapkan poin keputusan. Setelah dua minggu, team akan memilih use case pertama. Setelah uji coba internal terbatas, mereka akan memutuskan apakah asisten tersebut mengurangi waktu penanganan tanpa menambah pekerjaan koreksi. Setelah meninjau kasus-kasus sensitif, mereka akan memutuskan batas mana yang harus tetap dipertahankan.

Setiap keputusan menggunakan bukti yang tersedia pada saat itu. Masing-masing menyertakan syarat untuk meninjaunya kembali.

Menavigasi ambiguitas aktif. Hal ini membutuhkan penginderaan, framing, pembuatan, pengujian, pengambilan keputusan, dan penyesuaian. Menunggu hingga kabut menghilang juga merupakan sebuah pilihan, dan sering kali merupakan pilihan yang mahal.

Tujuannya bukan untuk menghilangkan ketidakpastian. Hal ini berarti bergerak tanpa membiarkan ketidakpastian menjadi kelumpuhan atau kepercayaan diri yang ceroboh.

🧑‍✈️ Jadikan Rute Dapat Dibaca oleh Kru

Seorang kapten mungkin memiliki pengalaman yang tidak dapat dilihat orang lain, namun kru tetap perlu memahami apa yang terjadi.

Ameera menyampaikan mengapa team memilih asisten internal, bukti apa yang mendukungnya, apa yang masih belum diketahui, dan sinyal apa yang dapat mengubah arah. Bagian hukum memahami kapan feedback mereka dibutuhkan. Agen pendukung memahami bahwa pilot tersebut bukanlah rencana tersembunyi untuk menyingkirkan mereka. Teknik memahami kemampuan mana yang bersifat eksploratif dan batasan mana yang tegas.

Rutenya hanya sementara, tapi tidak misterius.

Hal ini penting karena ambiguitas dapat memusatkan kekuatan pada siapa pun yang mengaku memiliki intuisi. Membuat asumsi dan aturan pengambilan keputusan terlihat memungkinkan team untuk melakukan navigasi bersama.

🌅 Saat Pulau Itu Muncul

Di atas kapal, kabut mulai menipis. Sebuah lereng bukit yang gelap muncul sedikit di sebelah kiri dari tempat yang diharapkan Ameera. Kapten menyesuaikan arah sekali lagi.

Dia tidak memperkirakan setiap meter journey-nya. Dia telah menggabungkan pengalaman, instrumen, observasi, dan koreksi kecil untuk tetap bergerak dengan aman.

Beberapa bulan kemudian, team Ameera belum menciptakan asisten AI besar dari laporan aslinya. Mereka telah membangun sesuatu yang lebih mendasar: alat agen untuk permintaan yang dipilih, batasan eskalasi yang jelas, dan kumpulan pembelajaran yang membuat keputusan berikutnya lebih bijaksana.

Rute muncul melalui journey.

Designer tidak menjadi berharga dengan berpura-pura tidak ada kabut. Kita menjadi berharga dengan membantu orang melihat apa yang diketahui, memilih arah yang bertanggung jawab, menciptakan bukti, dan melakukan penyesuaian tanpa kehilangan tujuan yang lebih besar.

Anda tidak selalu membutuhkan peta lengkap.

Anda memerlukan onboarding bersama yang cukup untuk menemukan arah aman berikutnya.

🧺 Hal-Hal Penting untuk Dibawa ke Proyek Anda Berikutnya

Ambiguitas merupakan kondisi normal dalam pengerjaan design, bukan pertanda kegagalan team.
Pisahkan apa yang diketahui, tidak diketahui, diasumsikan, dan diperebutkan.
Buatlah komitmen sementara yang menciptakan pembelajaran tanpa berpura-pura menjadi jawaban akhir.
Bangunlah petunjuk kecil tentang kejelasan melalui prinsip, bukti, batasan, dan poin keputusan.
Pertahankan ketegangan penting cukup lama untuk merancang hubungan yang lebih bertanggung jawab di antara mereka.
Hindari kelumpuhan dan kepastian yang ceroboh.
Buatlah rute, asumsi, dan alasan dapat dibaca sehingga team dapat melakukan navigasi bersama.

P.S. Selanjutnya:

“Refleksi: Seperti Warung Setelah Tutup, Mengubah Hari yang Sibuk Menjadi Penilaian yang Lebih Baik” 👀

🔗 Tentang Seri Ini

Ini adalah artikel 8 dari Designerly Thinking: Eight Core Design Abilities, diikuti dengan epilog refleksi. Kemampuan tersebut berasal dari Stanford d.school dan tidak dimaksudkan sebagai rangkaian yang kaku.