Cara Mendesain Form yang Bisa Dipahami Manusia dan Agent

Form sering dianggap bagian paling membosankan dari website.

Sampai suatu hari form itu harus diisi bukan hanya oleh manusia, tetapi juga oleh AI agent.

Bayangkan seorang calon klien ingin meminta proposal. Ia memberi instruksi ke agent: cari layanan yang cocok, buka halaman kontak, isi data perusahaan, masukkan kebutuhan singkat, lalu berhenti sebelum submit.

Agent tiba di form.

Field pertama hanya menampilkan placeholder “Your info”.

Field kedua punya ikon telepon tanpa label.

Ada dropdown custom bertuliskan “Choose”.

Kolom budget meminta angka, tetapi tidak menjelaskan mata uang.

Checkbox consent menggunakan kalimat panjang yang juga menjadi link.

Tombol terakhir hanya bertuliskan “Go”.

Manusia mungkin masih bisa menebak dengan melihat layout. Agent harus mengandalkan struktur, label, state, dan konteks yang tersedia.

Di sinilah desain form menjadi jauh lebih strategis daripada urusan UI polish.

Form yang mudah dipahami manusia biasanya juga lebih robust untuk software

Kabar baiknya, kita tidak perlu menciptakan “form khusus AI”.

Banyak fondasinya sudah lama ada dalam praktik accessibility dan semantic web.

W3C Web Accessibility Initiative menyarankan form control memiliki label yang dapat mengidentifikasi tujuannya. Instruksi juga perlu menjelaskan field wajib, format data, atau informasi relevan lain. Accessible name membantu assistive technology memahami input atau button.

Semua itu awalnya dibuat untuk manusia.

Efek samping positifnya: interface menjadi lebih eksplisit secara programatik.

Kalau field punya label “Email kerja”, agent tidak perlu menebak dari posisi visual.

Kalau checkbox punya nama “Saya setuju dihubungi terkait permintaan proposal”, tujuannya lebih jelas.

Kalau error berkata “Nomor telepon harus berisi 10–15 digit”, sistem mendapat informasi yang dapat ditindaklanjuti.

Accessibility bukan hack untuk agent. Tetapi semantic clarity yang baik membantu keduanya.

Mulai dari satu pertanyaan sederhana: field ini sebenarnya meminta apa?

Di banyak organisasi, form tumbuh tanpa governance.

Marketing menambah satu field.

Sales minta dua field lagi.

Legal menambahkan consent.

Developer membuat dropdown custom.

Lima tahun kemudian, form contact berisi 17 pertanyaan dan tidak ada yang yakin mana yang benar-benar diperlukan.

Sebelum bicara AI agent, audit dulu setiap field.

Apa tujuan field ini?

Siapa yang memakai datanya?

Apakah wajib?

Apa format validnya?

Apakah pilihan nilainya jelas?

Apakah data sensitif?

Apakah bisa diambil dari konteks lain?

Apakah user tahu kenapa diminta?

Kalau tim internal saja sulit menjawab, jangan berharap agent memahami form secara konsisten.

Form yang agent-readable dimulai dari business clarity.

Label visible tetap penting

Ada godaan membuat interface superminimalis: tidak ada label, hanya placeholder di dalam input.

Kelihatannya bersih.

Begitu user mulai mengetik, placeholder hilang.

Manusia bisa lupa field itu meminta apa.

Agent dan assistive technology juga bisa menghadapi ambiguity jika implementasinya tidak menyediakan accessible name yang benar.

Praktik yang lebih kuat adalah menyediakan label yang jelas dan menghubungkannya secara programatik ke control.

Contoh:

Nama lengkap

Email kerja

Nomor telepon

Nama perusahaan

Jumlah karyawan

Kebutuhan utama

Budget estimasi

Label tidak harus panjang. Yang penting spesifik.

“Name” lebih lemah daripada “Nama lengkap”.

“Phone” masih cukup jelas, tetapi “Nomor WhatsApp” berbeda makna jika bisnis memang meminta channel tersebut.

“Company size” perlu didefinisikan apakah jumlah karyawan, omzet, atau ukuran lain.

Semakin penting konsekuensi data, semakin sedikit ruang untuk interpretasi.

Placeholder adalah bantuan, bukan identitas field

Placeholder berguna untuk contoh.

Misalnya:

Email kerja
nama@perusahaan.com

Atau:

Nomor NPWP
contoh format sesuai kebutuhan sistem

Tetapi placeholder tidak seharusnya menjadi satu-satunya petunjuk tentang fungsi control.

Ia bisa hilang saat user mengetik. Contrast-nya sering lebih rendah. Dan pada form kompleks, contoh bukan pengganti label.

Buat manusia, prinsipnya sederhana: user tidak perlu mengingat apa yang baru saja menghilang.

Buat agent, struktur yang eksplisit mengurangi ketergantungan pada inferensi visual.

Instruksi harus muncul sebelum error

Form jelek sering memberi aturan setelah user salah.

Password ternyata harus punya format tertentu.

Tanggal harus DD/MM/YYYY.

Nomor telepon tidak boleh memakai spasi.

File maksimal ukuran tertentu.

Budget harus angka bulat.

Semua baru dijelaskan setelah submit.

Ini membuat manusia kesal dan agent melakukan trial-and-error yang tidak perlu.

Kalau format penting, jelaskan sebelum input.

W3C WAI juga menekankan pentingnya memberikan instruksi yang membantu user memahami cara mengisi form, termasuk field required, optional, dan format data.

Contoh:

“Masukkan estimasi budget bulanan dalam rupiah, tanpa titik atau koma.”

“Pilih satu kategori yang paling dekat dengan kebutuhan utama.”

“File PDF maksimal 10 MB.”

“Field bertanda * wajib diisi.”

Instruksi seperti itu membuat task lebih deterministic.

Agent tidak perlu bereksperimen untuk menemukan validator.

Error message harus actionable

“Invalid input.”

Itu bukan bantuan.

“Ada yang salah.”

Juga tidak.

Error yang baik menjawab tiga hal:

field mana yang bermasalah,

apa masalahnya,

bagaimana memperbaikinya.

Misalnya:

“Email kerja belum valid. Gunakan format nama@domain.com.”

“Pilih tanggal setelah 10 Agustus 2026.”

“File terlalu besar. Maksimal 10 MB.”

“Nomor telepon hanya boleh berisi angka dan tanda +.”

Kalau error muncul setelah submit, fokus juga sebaiknya diarahkan ke area yang bermasalah dan state error dapat dikenali secara programatik.

Buat agent, error bukan sekadar pesan kegagalan. Itu instruction untuk recovery.

Kalau recovery path jelas, agent dapat memperbaiki.

Kalau error ambigu, agent bisa mengulang input yang sama, menebak-nebak, atau berhenti.

Jangan membuat dropdown seperti puzzle

Custom select sering menjadi sumber masalah.

Secara visual, ia terlihat seperti dropdown.

Secara DOM, kadang hanya kumpulan div dengan event handler.

Keyboard navigation tidak konsisten.

State selected tidak jelas.

Label tidak terhubung.

Option list muncul di tempat berbeda.

Manusia dengan mouse mungkin berhasil.

Software atau assistive technology bisa kesulitan.

Gunakan native controls ketika cukup. Kalau memang membutuhkan custom component, implementasikan pattern accessibility yang benar: role, state, focus management, keyboard behavior, label, dan announcement yang sesuai.

Ini bukan berarti semua UI harus terlihat jadul.

Semantic robustness dan visual design tidak bertentangan.

Yang harus dihindari adalah komponen cantik yang maknanya hanya ada di CSS dan posisi layar.

Radio button dan checkbox harus menjelaskan pilihan, bukan hanya bentuk

Form pricing sering punya kartu pilihan:

Basic

Pro

Enterprise

User klik seluruh kartu.

Untuk manusia itu nyaman.

Agent perlu tahu control mana yang selectable, option mana yang aktif, dan apakah hanya satu pilihan yang boleh dipilih.

Gunakan state yang benar.

Radio untuk pilihan eksklusif.

Checkbox untuk pilihan independen.

Jangan menyembunyikan relationship hanya dalam styling.

Hal yang sama berlaku pada consent.

Jangan membuat satu checkbox ambigu:

“Saya setuju.”

Setuju apa?

Lebih jelas:

“Saya setuju menerima komunikasi terkait permintaan demo.”

Kalau ada beberapa tujuan penggunaan data, jangan diam-diam menggabungkan semuanya menjadi satu consent.

Semantik yang baik juga governance yang baik.

Required dan optional jangan dibuat misterius

Ada dua pola yang sama-sama bisa bekerja:

tandai semua required,

atau tandai field optional.

Yang penting konsisten.

Agent perlu tahu mana yang harus diisi agar workflow bisa lanjut.

Kalau field wajib hanya ditandai warna merah tanpa state atau teks yang benar, ambiguity meningkat.

Color-only communication memang sudah lama bermasalah untuk accessibility. Agentic workflow memberikan alasan tambahan untuk memperbaikinya.

Gunakan indikator programatik seperti required state, label yang jelas, dan validation yang konsisten.

Autofill perlu dirancang dengan hati-hati

Agent dan browser dapat membantu mengisi data dari profile atau context.

Ini bagus untuk nama, email, alamat, dan field repetitif.

Tetapi autofill juga bisa membawa risiko.

Alamat rumah masuk ke form kantor.

Nomor pribadi masuk ke vendor portal.

Email lama terisi.

Data tenant A terbawa ke tenant B.

Karena itu form tidak boleh menganggap autofilled value pasti benar.

Untuk data penting, tampilkan value secara jelas sebelum submit.

Untuk field sensitif, pertimbangkan apakah autofill memang layak.

Dan jangan menambahkan hidden field yang mengumpulkan data tidak relevan hanya karena bisa.

Agentic convenience tidak membatalkan data minimization.

Draft state sangat berguna

Untuk form panjang, buat state sebelum submit.

Bayangkan agent mengisi 20 field untuk aplikasi enterprise.

User seharusnya bisa melihat ringkasan:

Perusahaan: ABC.

Kontak: Rina.

Paket: Enterprise.

Budget: Rp100 juta–Rp250 juta.

Kebutuhan: integrasi CRM dan WhatsApp.

File: proposal.pdf.

Belum dikirim.

Kata terakhir penting.

“Belum dikirim.”

Agent dapat melakukan banyak pekerjaan tanpa mengeksekusi action final.

Draft membantu memisahkan data entry dari authorization.

Ini sangat cocok untuk Human-in-the-Loop.

Agent mengerjakan repetisi.

Manusia memeriksa consequence.

Lalu submit terjadi setelah approval.

Tombol harus mengatakan apa yang akan terjadi

“Go.”

“Next.”

“OK.”

“Continue.”

Kadang cukup. Kadang terlalu ambigu.

Pada multi-step form, tombol sebaiknya mencerminkan action.

“Lanjut ke ringkasan.”

“Upload dokumen.”

“Kirim permintaan demo.”

“Buat akun.”

“Konfirmasi booking.”

“Bayar Rp1.250.000.”

W3C WAI membahas accessible name sebagai nama yang diasosiasikan dengan elemen seperti button atau input. Untuk interaction yang kompleks, nama control yang jelas membantu manusia dan teknologi memahami purpose.

Kata pada button juga punya efek psikologis.

User berhak tahu apakah klik berikutnya sekadar pindah langkah atau melakukan transaksi.

Agent juga.

Jangan gunakan satu form untuk lima intent berbeda

Salah satu antipattern marketing adalah form generik:

“Contact us.”

User bisa ingin sales.

Support.

Partnership.

Press.

Career.

Billing.

Agent harus menebak routing dari free text.

Lebih baik website memberi intent selector yang jelas.

“Saya ingin:”

Minta demo.

Minta proposal.

Tanya layanan.

Hubungi support.

Partnership.

Media inquiry.

Sekarang workflow downstream lebih rapi.

Agent tahu tujuan.

Tim internal tahu routing.

Analytics lebih meaningful.

Form menjadi action surface, bukan kotak pesan.

Uji form tanpa mengandalkan mata

Salah satu tes yang sangat berguna: minta tim mengevaluasi form seolah mereka tidak boleh menggunakan tebakan visual.

Apakah label masih jelas?

Apakah urutan field masuk akal?

Apakah option punya nama?

Apakah required state diketahui?

Apakah error dapat dipahami?

Apakah success state eksplisit?

Apakah tombol akhir menjelaskan consequence?

Apakah value yang dipilih dapat dibaca kembali?

Apakah keyboard dapat menyelesaikan flow?

Apakah perubahan dinamis diumumkan?

Lalu tes dengan screen reader dan keyboard, bukan hanya browser agent. Accessibility tetap tujuan manusia yang penting, bukan sekadar proxy untuk AI compatibility.

Agentic Web tidak boleh mengambil movement accessibility lalu membingkainya seolah semua praktik itu baru berguna setelah AI datang.

Justru sebaliknya: banyak hal yang membuat agent lebih mampu berinteraksi adalah hal yang sudah lama dibutuhkan manusia.

Success message jangan hilang dalam konfeti

Setelah form berhasil dikirim, website perlu memberi receipt.

“Permintaan demo berhasil dikirim.”

“Nomor referensi: ABC-123.”

“Tim kami biasanya merespons melalui email.”

“File yang diterima: proposal.pdf.”

Kalau submission gagal, jangan menampilkan animation yang terlihat success lalu error kecil di bawah.

State harus tegas.

Agent perlu tahu apakah task selesai atau harus mencoba recovery.

Manusia juga tidak ingin mengirim form dua kali karena ragu.

Desain form terbaik terasa membosankan dalam arti yang positif

Form yang bagus jarang membuat orang berkata, “Wow, experience input nomor teleponnya revolusioner.”

Mereka cuma mengisi dan selesai.

Tidak bingung.

Tidak salah format tiga kali.

Tidak bertanya field ini untuk apa.

Tidak takut tombol terakhir mengirim sesuatu yang belum siap.

Agent juga membutuhkan hal yang sama.

Jadi ketika tim bertanya bagaimana membuat form “AI-ready”, jangan mulai dari tool baru.

Mulai dari boring fundamentals:

label jelas,

instruction jelas,

semantic control,

state jelas,

validation jelas,

error actionable,

permission proporsional,

preview sebelum action sensitif,

dan confirmation yang mengatakan apa yang benar-benar akan terjadi.

Form yang baik tidak memaksa manusia atau mesin membaca pikiran designer.

Itulah benchmark yang jauh lebih berguna daripada sekadar terlihat futuristik.