Prinsip UX Don Norman bisa membantu Anda menemukan alur yang membingungkan, mengurangi biaya dukungan, dan memvalidasi layar yang dibuat lewat chat sebelum pengguna kebingungan.
Antarmuka yang membingungkan tidak hanya terasa buruk. Mereka menciptakan biaya yang dapat diukur: orang meninggalkan pendaftaran dan pembayaran, meminta refund, dan menghubungi dukungan untuk hal yang seharusnya jelas.
Seringkali masalahnya bukan desain visual. Masalahnya adalah kejelasan. Pengguna tidak bisa mengetahui apa yang sistem inginkan, apa yang akan terjadi selanjutnya, atau apakah aman untuk melanjutkan.
Kebingungan itu berubah menjadi waktu dan uang dalam beberapa cara yang dapat diprediksi. Tingkat drop‑off naik ketika orang mencapai momen keraguan. Dukungan dibanjiri dengan pertanyaan “Di mana X?” dan “Kenapa ini terjadi?” Refund dan chargeback meningkat ketika alur harga, konfirmasi, atau pembatalan tidak jelas. Secara internal, tim menghabiskan waktu menulis panduan dan solusi sementara karena produk tidak menjelaskan dirinya sendiri.
Friction kecil jadi mahal karena terulang di alur umum. Pendaftaran yang membingungkan mungkin hanya membuat Anda kehilangan satu pengguna sekali saja. Checkout yang membingungkan bisa merugikan Anda setiap kali.
Skenario sederhana menunjukkan bagaimana ini terjadi: seseorang membuat akun dan mengubah pengaturan seperti frekuensi notifikasi. Mereka melihat toggle, mengetuknya, dan tidak ada konfirmasi perubahan. Nanti mereka masih menerima email. Sekarang Anda punya tiket dukungan, pengguna merasa tertipu, dan kepercayaan turun. UI mungkin terlihat rapi, tapi pengalaman tidak jelas.
Kecepatan membuat hal ini lebih mudah terlewat. Saat Anda membangun cepat, terutama dengan alat chat yang menghasilkan layar dan alur dengan cepat, Anda bisa berakhir dengan langkah yang masuk akal bagi pembuatnya tetapi tidak bagi pengguna pertama kali.
Perbaikan dimulai dengan beberapa ide yang sering dikaitkan dengan Don Norman: buat tindakan jelas, cocokkan dengan model mental pengguna, berikan umpan balik cepat, dan cegah kesalahan sebelum terjadi. Sisa panduan ini bersifat praktis: seperangkat prinsip kecil, plus rutinitas sederhana untuk memvalidasi alur yang Anda buat dengan cepat sebelum pengguna nyata kehilangan arah.
Orang tidak membaca antarmuka. Mereka menebak.
Pengguna membawa model mental, sebuah cerita di kepala mereka tentang bagaimana sesuatu seharusnya bekerja berdasarkan aplikasi lain, objek dunia nyata, dan kebiasaan. Ketika antarmuka Anda cocok dengan model itu, orang bergerak cepat. Ketika ia bertentangan, mereka melambat, ragu, dan membuat “kesalahan” yang sebenarnya adalah kesalahan desain.
Pengguna yang mengklik "Save" mengharapkan karyanya aman. Pengguna yang mengklik "Delete" mengharapkan peringatan atau cara mudah kembali. Pengguna yang melihat kotak pencarian mengharapkan bisa mengetik dan menekan Enter. Ekspektasi ini ada sebelum teks bantuan apapun.
UX yang baik memanfaatkan ekspektasi itu daripada mencoba melatih ulang orang.
Affordance adalah apa yang elemen bisa lakukan. Signifier adalah apa yang memberi tahu Anda bahwa itu bisa dilakukan.
Field teks memungkinkan mengetik. Signifier‑nya adalah kotak yang terlihat, kursor, dan kadang placeholder. Tombol memungkinkan diklik. Signifier‑nya adalah bentuk, kontras, dan labelnya. Jika Anda menata tombol supaya terlihat seperti teks biasa, affordance tidak berubah, tetapi signifier melemah sehingga orang melewatkannya.
Gulf of execution adalah jarak antara apa yang pengguna inginkan dan tindakan yang disediakan UI. Jika seseorang ingin mengubah alamat pengiriman tapi hanya melihat "Edit Profile," mereka mungkin tidak tahu harus berbuat apa.
Gulf of evaluation adalah jarak antara apa yang sistem lakukan dan apa yang bisa dipahami pengguna dari layar. Jika mereka klik "Pay" dan tidak ada perubahan (atau hanya spinner kecil), mereka tidak tahu apakah itu berhasil, gagal, atau masih diproses.
Umpan balik yang baik cepat, jelas, dan spesifik. Jawab tiga pertanyaan: apakah berhasil, apa yang berubah, dan apa yang harus saya lakukan selanjutnya?
Ini lebih penting lagi ketika Anda membangun cepat dengan alat berbasis chat. Layar yang dihasilkan tetap membutuhkan signifier yang jelas dan umpan balik yang tak salah tafsir agar pengguna pertama kali tidak tersesat.
Antarmuka yang membingungkan jarang gagal karena kodenya salah. Mereka gagal karena layar tidak cocok dengan apa yang orang pikir akan terjadi selanjutnya.
Contoh klasik adalah kekacauan "Save vs Submit vs Publish." Di banyak alat, "Save" bisa berarti "simpan draft", "simpan dan bagikan", atau "selesaikan proses." Pengguna yang hanya ingin menyimpan pekerjaan akan ragu, atau menekan yang salah dan panik. Label seperti "Save draft" dan "Publish now" mengurangi ketakutan itu karena menjelaskan hasil.
Layar pengaturan juga banyak merusak secara diam‑diam. Toggle yang tidak jelas atau terbalik ada di mana‑mana: sakelar bertuliskan "Notifications" tanpa menjelaskan apa arti ON. Lebih buruk lagi adalah toggle yang terlihat aktif padahal fitur sebenarnya mati karena dependensi lain. Orang berhenti percaya pada halaman dan mulai menebak.
Formulir seringkali pelaku lain. Form pendaftaran yang gagal tanpa menjelaskan kenapa pada dasarnya memberi tahu pengguna, "Coba lagi sampai beruntung." Aturan password yang tersembunyi sampai setelah error, field wajib yang hanya menunjukkan outline merah kecil, atau pesan seperti "Invalid input" memaksa kerja ekstra.
Empty state juga bisa menjebak orang. Dashboard kosong yang hanya menulis "No data yet" membuat pengguna terdampar. Empty state yang membantu menjawab satu pertanyaan: apa yang harus saya lakukan selanjutnya? Sederhana seperti "Create your first project" plus satu kalimat tentang apa yang terjadi setelahnya seringkali cukup.
Tindakan destruktif sering tersembunyi di balik kata‑kata yang terasa tidak berbahaya. "Remove" bisa berarti "hapus dari daftar ini" atau "hapus selamanya." Jika hasilnya tidak bisa dibatalkan, kata‑kata harus menyatakannya.
Jika Anda membangun cepat, area ini layak diperiksa ganda terlebih dahulu: label tombol harus menggambarkan hasil, toggle harus menyatakan apa arti ON dan OFF, error form harus menunjuk field dan aturan yang tepat, empty state harus menawarkan langkah berikutnya, dan tindakan destruktif harus dinamai jelas dan dikonfirmasi bila perlu.
Banyak kebingungan mulai ketika produk dibangun dari layar ke luar alih‑alih dari tujuan pengguna ke dalam. Sebuah layar bisa terlihat lengkap namun gagal jika tidak membantu seseorang menyelesaikan apa yang mereka datang untuk lakukan.
Pilih satu tujuan dan tulis seperti tugas, bukan fitur: "Buat faktur dan kirimkan," "Pesan potong rambut untuk Jumat," atau "Terbitkan landing page." Tujuan itu adalah jangkar Anda karena mendefinisikan apa arti "selesai."
Lalu kecilkan perjalanan ke kumpulan langkah terkecil yang masih terasa natural. Salah satu cara tercepat mengurangi kebingungan adalah menghapus langkah yang ada hanya karena pembuat tahu konteks ekstra. Pembuat seringnya memajukan pengaturan karena masuk akal saat setup. Pengguna baru biasanya ingin mulai melakukan hal itu dulu, lalu mengatur pengaturan nanti.
Tes praktis: cek setiap langkah dengan tiga pertanyaan:
Saat langkah gagal pada salah satu pertanyaan ini, pengguna melambat. Mereka mengarahkan kursor, menggulir, membuka menu acak, atau meninggalkan untuk bertanya pada rekan.
Cari titik jeda yang dapat diprediksi: pilihan dengan perbedaan yang tidak jelas ("Workspace" vs "Project"), formulir yang meminta informasi yang belum mereka miliki, halaman dengan beberapa tombol utama, atau alur yang mengubah terminologi di tengah (daftar, lalu "provision," lalu "deploy").
Saat menemukan titik jeda, selaraskan tindakan berikutnya dengan tujuan. Gunakan kata‑kata pengguna, pindahkan pengaturan lanjutan ke belakang, dan buat satu langkah jelas berikutnya. Alurnya harus terasa seperti jalur yang dipandu, bukan kuis.
Orang bisa menangani hampir semua antarmuka jika mereka tahu apa yang sistem lakukan dan apa yang terjadi setelah mereka bertindak. Kebingungan mulai ketika layar diam: tidak ada tanda menyimpan, tidak ada petunjuk bahwa pekerjaan sedang berlangsung, tidak ada bukti bahwa tombol melakukan sesuatu.
Umpan balik cepat bukan hiasan. Itu adalah antarmuka yang berkata, "Saya mendengarmu." Itu mencegah klik ganda, refresh marah, dan formulir yang ditinggalkan.
Setiap tindakan yang memakan waktu lebih dari sekejap butuh status yang terlihat. Itu termasuk memuat halaman, memproses pembayaran, mengunggah file, menghasilkan laporan, atau mengirim pesan.
Aturan sederhana: jika pengguna bisa bertanya "Apakah ini berhasil?" UI Anda seharusnya sudah menjawab.
Buat konkret:
Sebuah konfirmasi berguna ketika mengatakan apa yang berubah dan di mana menemukannya. "Success" terlalu samar. "Invoice sent to [email protected]. You can see it in Sent invoices" menenangkan.
Error harus membimbing, bukan menghukum. Umpan balik error yang baik punya tiga bagian: apa yang salah, bagaimana memperbaikinya, dan jaminan bahwa pengguna tidak kehilangan pekerjaan mereka. Simpan apa yang mereka ketik. Jangan reset formulir karena satu field salah.
Kegagalan diam adalah jenis umpan balik terburuk. Jika sesuatu gagal, katakan dengan jelas dan tawarkan tindakan selanjutnya (Retry, Edit, Contact support). Jika Anda autosave, tunjukkan itu. Jika Anda tidak bisa menyimpan, jelaskan alasannya.
Orang biasanya tidak membuat kesalahan karena ceroboh. Mereka membuatnya karena antarmuka diam‑diam mengizinkan tindakan yang salah, atau gagal menunjukkan apa yang akan terjadi selanjutnya.
Ide Don Norman tentang constraint sederhana: desain sehingga tindakan paling aman adalah tindakan termudah.
Constraint yang baik bukan jalan buntu. Jika sesuatu dinonaktifkan, pengguna harus mengerti kenapa dan bagaimana memperbaikinya. "Save" abu‑abu tanpa penjelasan terasa rusak. "Save (tambahkan judul untuk melanjutkan)" terasa membantu.
Beberapa pola mengurangi kebingungan tanpa membuat pengguna merasa diawasi. Gunakan picker atau preset ketika teks bebas berpotensi typo yang bisa dihindari (tanggal, negara, peran). Berikan default yang masuk akal untuk kasus paling umum, lalu biarkan pengguna lanjutan mengubahnya. Validasi saat mengetik dengan pesan spesifik. Jika Anda menonaktifkan aksi, letakkan alasannya tepat di sebelahnya.
Contoh konkret: bayangkan alur "Create workspace" yang dibuat cepat. Jika region database diperlukan, jangan minta pengguna mengetik manual. Tawarkan picker dengan default yang direkomendasikan dan catatan singkat kenapa itu penting. Jika nama wajib, tunjukkan aturan sejak awal ("3 sampai 30 karakter") daripada menunggu sampai langkah akhir.
Dialog konfirmasi tidak harus menakutkan. Mereka harus spesifik. Ganti "Are you sure?" dengan apa yang dihapus, apa yang akan hilang, dan apakah bisa dibatalkan.
Keluar yang aman bagian dari pencegahan error. "Cancel" dan "Back" tidak boleh membuang progres secara diam‑diam. Bila memungkinkan, tawarkan Undo setelah tindakan seperti menghapus rekan tim atau draft.
Friction tambahan sepadan ketika biaya kesalahan tinggi: pembayaran dan upgrade paket, menghapus data atau akun, memberi izin, mengirim undangan ke pelanggan nyata, atau ekspor dan reset yang tidak bisa dibatalkan. Tujuannya bukan memperlambat orang. Tujuannya membuat konsekuensi terlihat sebelum klik.
Antarmuka yang membingungkan menciptakan biaya berulang:
Kejelasan berkaitan dengan apakah pengguna baru bisa menjawab tiga pertanyaan di setiap langkah:
Antarmuka bisa terlihat “bersih” secara visual namun gagal jika tidak membuat hasilnya dapat diprediksi.
Model mental adalah ekspektasi pengguna tentang bagaimana sesuatu bekerja berdasarkan aplikasi lain dan kebiasaan sehari‑hari.
Pendekatan standar: cocokkan ekspektasi umum (mis. “Save” menyimpan karya; “Delete” memberi peringatan atau dapat dibatalkan). Jika Anda harus melanggar ekspektasi, jelaskan dengan label dan umpan balik yang eksplisit agar orang tidak menebak.
Sebuah affordance adalah apa yang bisa dilakukan suatu elemen. Sebuah signifier adalah apa yang membuat tindakan itu jelas.
Contoh: tombol tetap bisa diklik walau tampilannya seperti teks biasa, tapi signifier melemah sehingga orang tak memperhatikannya. Perbaikan praktis: perbaiki signifier lewat label jelas, kontras, penempatan, dan perubahan status (pressed/loading/disabled).
Gunakan konsep ini sebagai diagnosis cepat:
Untuk menutup keduanya: buat tindakan berikutnya mudah ditemukan, dan buat hasilnya tidak salah tafsir.
Gunakan label yang berfokus pada hasil.
Tujuan: pengguna harus tahu konsekuensi sebelum klik.
Buat ON/OFF jelas dan jaga kebenaran sistem:
Hindari toggle yang terlihat menyala padahal fitur sebenarnya mati.
Aturan dasar: jika seseorang bisa bertanya “Apakah ini berhasil?”, UI Anda harus sudah menjawabnya.
Polanya:
Cegah kesalahan dengan membuat jalur aman menjadi yang termudah:
Untuk tindakan destruktif, konfirmasi dengan detail (apa yang akan dihapus, apa yang hilang, apakah bisa dibatalkan).
Jalankan loop validasi singkat sebelum rilis:
Jika Anda memakai Koder.ai, gunakan Planning Mode untuk mendefinisikan langkah dan status sebelum deploy.
