Desain Form Input yang Cepat Diisi dan Minim Kesalahan

Desain form input yang baik membantu orang memasukkan data yang benar pada percobaan pertama, dan memperbaiki kesalahan tanpa mengetik ulang semuanya. Form bisa saja panjang. Yang membuatnya lambat adalah pertanyaan tanpa alasan yang jelas, format yang harus ditebak, isian yang hilang setelah gagal dikirim, dan pesan kesalahan yang tidak menjelaskan apa-apa.

Masalah ini terasa di banyak tempat: formulir pendaftaran siswa, input data jamaah di travel umrah, pencatatan pesanan oleh admin, atau laporan harian tim lapangan. Setiap data yang salah masuk akan berpindah ke laporan, tagihan, dan keputusan berikutnya. Biaya memperbaikinya jauh lebih besar daripada biaya merancang form dengan benar sejak awal.

Artikel ini menjelaskan prinsip yang bisa Anda pakai saat meninjau form yang sudah ada atau menyusun kebutuhan aplikasi baru bersama tim pengembang. Rujukannya adalah panduan W3C (WCAG 2.2), web.dev, MDN, OWASP, dan GOV.UK Design System.

Mulai dari data yang benar-benar dipakai

Sebelum memikirkan tampilan, periksa setiap kolom dengan tiga pertanyaan: siapa yang memakai data ini, untuk keputusan apa, dan kapan data itu dibutuhkan. Kolom yang tidak lolos pertanyaan pertama layak dihapus. Kolom yang baru dibutuhkan di tahap verifikasi tidak perlu diminta saat pendaftaran awal.

Cara ini sering memangkas form secara signifikan tanpa mengurangi data penting. Hasilnya juga lebih aman, karena data pribadi yang tidak diminta tidak perlu disimpan dan dijaga.

Pertanyaan berikutnya: apakah data ini sudah pernah diberikan pengguna? WCAG 2.2 punya kriteria khusus untuk hal ini, yaitu 3.3.7 Redundant Entry (level A). Informasi yang sudah dimasukkan dalam satu proses harus terisi otomatis atau bisa dipilih, bukan diketik ulang. Pengecualiannya terbatas, misalnya konfirmasi kata sandi baru demi keamanan. Contoh sederhana: alamat penagihan cukup dicentang "sama dengan alamat pengiriman".

Susun struktur form sesuai cara orang berpikir

Kelompokkan kolom berdasarkan topik yang dikenali pengguna: identitas, kontak, rincian transaksi, lalu dokumen. Urutannya mengikuti urutan dokumen sumber yang mereka pegang. Bila petugas menyalin data dari KTP atau formulir kertas, samakan urutan kolom dengan urutan di dokumen tersebut agar mata tidak bolak-balik.

Panduan desain form dari web.dev menyarankan tata letak satu kolom karena hanya ada satu arah yang harus diikuti mata. Pasangan kolom yang sangat berkaitan, seperti kota dan kode pos, masih bisa diletakkan berdampingan, tetapi jadikan itu pengecualian.

Form yang panjang boleh dipecah menjadi beberapa langkah dengan dua syarat:

• Pengguna tahu sedang berada di langkah ke berapa dan berapa langkah yang tersisa.
• Pengguna bisa kembali ke langkah sebelumnya tanpa kehilangan isian, dan sebaiknya bisa menyimpan draf untuk dilanjutkan nanti.

Pola alur ini sama pentingnya dengan isi form. Bila prosesnya masih tersebar di chat dan spreadsheet, petakan dulu alurnya seperti dibahas di artikel cara pindah dari WhatsApp dan spreadsheet ke sistem terpusat.

Label, petunjuk, dan format yang tidak perlu ditebak

WCAG 2.2 kriteria 3.3.2 Labels or Instructions (level A) menyatakan bahwa label atau instruksi harus tersedia ketika konten meminta input dari pengguna. Dalam praktik, artinya:

• Label selalu terlihat dan diletakkan di atas kolom. Placeholder hanya contoh isian, bukan pengganti label, karena placeholder hilang begitu pengguna mulai mengetik.
• Tandai wajib dan opsional secara konsisten. Bila sebagian besar kolom wajib, cukup beri keterangan "(opsional)" pada sisanya.
• Jelaskan format sebelum pengguna salah: format tanggal, panjang nomor induk, jenis dan ukuran maksimal berkas.
• Pakai pilihan terkontrol (dropdown, radio, pencarian dengan saran) untuk data yang harus seragam, seperti nama cabang, kelas, atau paket layanan. Ketik bebas di sini akan menghasilkan ejaan berbeda-beda yang menyulitkan laporan.
• Terima format yang wajar. GOV.UK Design System menyarankan sistem mengabaikan karakter yang tidak perlu, seperti spasi, tanda hubung, dan kurung pada nomor telepon, alih-alih menolaknya.

Percepat pengisian: keyboard, autofill, dan nilai bawaan

Untuk form yang diisi pelanggan lewat ponsel, jenis keyboard berpengaruh besar. Menurut MDN, atribut inputmode memberi petunjuk keyboard virtual yang tepat: numeric untuk angka saja, decimal untuk angka berkoma, tel untuk nomor telepon, dan email untuk alamat email. Untuk data yang bukan bilangan, seperti PIN, kode pos, atau nomor induk yang bisa diawali nol, kombinasi type="text" dan inputmode="numeric" biasanya lebih aman daripada type="number".

Atribut autocomplete membantu browser mengisi data yang sudah tersimpan. web.dev mencontohkan nilai seperti email, postal-code, new-password untuk pendaftaran, current-password untuk login, dan one-time-code untuk kode OTP. Matikan autofill hanya bila Anda yakin itu membantu pengguna.

Untuk form internal yang diisi admin puluhan kali sehari, kecepatan datang dari hal lain:

1. Urutan tombol Tab mengikuti urutan visual, sehingga seluruh form bisa diisi tanpa mouse.
2. Nilai bawaan yang masuk akal, misalnya tanggal hari ini atau cabang tempat petugas bertugas, tetapi tetap bisa diubah.
3. Pencarian dengan saran untuk data master seperti pelanggan atau produk, bukan dropdown berisi ratusan baris.
4. Fitur "simpan dan tambah baru" untuk input berulang.

Hal-hal kecil ini menentukan apakah aplikasi terasa membantu atau malah menambah pekerjaan. Kebutuhan seperti ini juga menjadi salah satu pertimbangan saat memilih antara software siap pakai atau aplikasi custom, karena form pada software siap pakai belum tentu bisa diatur sesuai alur kerja Anda.

Validasi dan pesan kesalahan yang membantu

WCAG 2.2 kriteria 3.3.1 Error Identification (level A) mensyaratkan bahwa bila kesalahan input terdeteksi otomatis, kolom yang salah ditunjukkan dan kesalahannya dijelaskan dalam teks. Warna merah atau ikon saja tidak cukup. Kriteria 3.3.3 Error Suggestion (level AA) menambahkan: bila cara memperbaikinya diketahui, sarankan kepada pengguna, kecuali hal itu membahayakan keamanan.

Bandingkan dua pesan ini:

• "Data tidak valid."
• "Tanggal berangkat harus setelah tanggal pendaftaran. Contoh: 15/03/2027."

Pesan kedua menyebut kolomnya, masalahnya, dan cara memperbaikinya. Panduan GOV.UK juga menekankan beberapa hal yang sering terlewat:

• Tampilkan ulang form dengan semua isian pengguna tetap utuh.
• Letakkan ringkasan kesalahan di atas form, lalu pesan rinci di dekat setiap kolom yang bermasalah.
• Jangan memvalidasi terlalu dini. GOV.UK menyarankan validasi saat pengguna menekan tombol lanjut, bukan saat mereka masih mengetik atau baru berpindah kolom, karena peringatan yang muncul terlalu cepat bisa mengganggu, terutama bagi orang yang mengetik pelan. Validasi langsung boleh ditambahkan bila hasil uji pengguna menunjukkan manfaatnya.

Validasi di browser tidak menggantikan validasi di server

OWASP Input Validation Cheat Sheet menegaskan bahwa validasi di sisi klien bisa dilewati, sehingga server tetap harus memeriksa field yang sama. OWASP membedakan dua lapisan: validasi sintaksis (tipe dan format sudah benar) dan validasi semantik (nilainya masuk akal untuk proses tersebut, misalnya tanggal selesai harus setelah tanggal mulai). Pastikan aturan di browser dan di server sama, agar pengguna tidak lolos di layar lalu ditolak tanpa penjelasan.

Cegah data ganda dan kesalahan yang mahal

Koneksi lambat sering membuat pengguna menekan tombol kirim dua kali. Di sisi tampilan, nonaktifkan tombol selama proses berjalan dan tampilkan status yang jelas. Di sisi server, perlu mekanisme pencegah duplikasi. MDN menjelaskan bahwa permintaan POST, yang biasa dipakai untuk mengirim form, tidak dijamin idempoten: dua permintaan yang sama bisa menghasilkan dua baris data. Karena itu tim pengembang perlu menyiapkan pengaman di server, misalnya kunci unik per pengiriman.

Bila koneksi terputus, beri tahu pengguna dengan jelas apakah data sudah tersimpan atau perlu dikirim ulang.

Untuk transaksi yang berdampak hukum atau keuangan, mengubah atau menghapus data, atau mengirim jawaban ujian, WCAG 2.2 kriteria 3.3.4 (level AA) meminta minimal satu dari tiga hal: pengiriman bisa dibatalkan, data diperiksa dan pengguna diberi kesempatan memperbaiki, atau ada halaman tinjauan untuk memeriksa dan mengoreksi sebelum final. Halaman ringkasan sebelum konfirmasi paling berguna untuk kesalahan yang formatnya benar tetapi isinya keliru, seperti tanggal yang salah pilih. Pola ini relevan untuk alur seperti pendaftaran PPDB online sekolah atau madrasah, tempat satu kesalahan data bisa memengaruhi proses seleksi.

Uji desain form input sebelum dipakai pengguna nyata

Checklist ini bisa Anda jalankan sendiri dalam satu sore:

1. Isi form memakai ponsel dengan koneksi yang lambat.
2. Isi seluruh form hanya dengan keyboard.
3. Sengaja buat kesalahan di setiap kolom wajib, lalu periksa apakah pesannya jelas dan isian lain tetap ada.
4. Tempel nomor telepon yang berisi spasi atau tanda hubung.
5. Tekan tombol kirim dua kali dengan cepat dan periksa apakah datanya tercatat ganda.
6. Minta dua atau tiga calon pengguna mengisi form sambil Anda amati tanpa membantu. Catat di mana mereka ragu.

Temuan dari langkah terakhir biasanya paling berharga, karena menunjukkan kebingungan yang tidak terlihat oleh tim yang membuat form.

Pertanyaan yang sering diajukan

Apakah form yang panjang selalu buruk?

Tidak. Form panjang bisa tetap nyaman bila setiap kolom punya alasan, dikelompokkan dengan jelas, dibagi menjadi langkah dengan penanda progres, dan isian tidak hilang saat pengguna kembali ke langkah sebelumnya.

Kapan sebaiknya validasi dijalankan?

Panduan GOV.UK menyarankan validasi saat pengguna mengirim atau lanjut ke langkah berikutnya. Validasi langsung saat mengetik bisa membantu untuk kasus tertentu, tetapi sebaiknya diputuskan berdasarkan uji pengguna. Apa pun pilihannya, validasi di server tetap wajib.

Bolehkah placeholder dipakai sebagai label?

Sebaiknya tidak. Placeholder hilang saat pengguna mulai mengetik, sehingga mereka bisa lupa kolom apa yang sedang diisi. Gunakan label yang selalu terlihat, lalu placeholder sebagai contoh format bila perlu.

Bagaimana mencegah data tersimpan dua kali?

Gabungkan pengaman di tampilan (tombol dinonaktifkan selama proses dan status yang jelas) dengan pengaman di server yang mengenali pengiriman berulang. Pengaman di tampilan saja tidak cukup karena bisa dilewati.

Bila tim Anda sering memperbaiki data yang salah input, masalahnya bisa jadi ada di desain form dan alur aplikasinya, bukan hanya di ketelitian petugas. Anaverse membantu merancang UI/UX dan membangun aplikasi web custom untuk bisnis, sekolah, dan travel umrah. Anda bisa mendiskusikan kebutuhan sistem melalui layanan konsultan IT dan aplikasi custom atau langsung menghubungi tim Anaverse.

Referensi

• W3C: Understanding SC 3.3.1 Error Identification
• W3C: Understanding SC 3.3.2 Labels or Instructions
• W3C: Understanding SC 3.3.3 Error Suggestion
• W3C: Understanding SC 3.3.4 Error Prevention (Legal, Financial, Data)
• W3C: Understanding SC 3.3.7 Redundant Entry
• web.dev: Dasar-dasar desain formulir
• web.dev: Help users avoid re-entering data in forms (autofill)
• MDN: atribut inputmode
• MDN: Idempotent
• OWASP: Input Validation Cheat Sheet
• GOV.UK Design System: Validation