UX Dan HTML5: Mari Bantu Pengguna Mengisi Formulir Seluler Anda (Bagian 1)

Formulir adalah salah satu interaksi utama paling dasar yang akan dilakukan pengguna dengan situs web Anda (dan aplikasi seluler). Mereka menghubungkan orang bersama-sama dan membiarkan mereka berkomunikasi. Mereka membiarkan mereka mengomentari artikel dan menjelaskan kepada penulis bagaimana mereka sangat tidak setuju dengan apa yang mereka tulis. Mereka membiarkan orang mengobrol langsung di aplikasi kencan untuk bertemu "yang satu". Baik untuk forum, pesanan produk, komunitas online, pembuatan akun, atau pembayaran online, formulir adalah bagian besar dari kehidupan online pengguna.

Ini tahun 2018, dan kami memiliki lebih banyak pengguna seluler daripada desktop di seluruh dunia . Namun, kami masih memperlakukan pengguna tersebut sebagai warga web kelas dua. Semua orang menulis dan berbicara tentang pengalaman pengguna sepanjang waktu. Jadi, mengapa, mengapa, mengapa begitu banyak situs web dan produk masih melakukan kesalahan. Mengapa pengalaman pengguna seluler mereka rusak di separuh dunia? Mengapa masih sakit, mengapa masih sangat sulit untuk memesan penerbangan dan mendaftarkan akun dalam bentuk seluler hari ini? Pengguna berharap lebih baik!

Bacaan yang direkomendasikan : World Wide Web, Bukan Wealthy Western Web

Ini adalah bagian pertama dari rangkaian dua artikel. Dalam hal ini, saya akan merangkum beberapa praktik terbaik yang penting untuk meningkatkan formulir seluler Anda, termasuk kemampuan memindai dan keterbacaan. Saya akan memandu Anda melalui penempatan label dan input, ukuran dan pengoptimalan. Kita akan melihat bagaimana memilih elemen bentuk yang tepat untuk mengurangi biaya interaksi. Terakhir, Anda akan mempelajari cara mencegah dan menangani kesalahan pada formulir seluler.

Di bagian kedua, saya akan melihat lebih dekat kemampuan seluler tertentu dan elemen formulir HTML5, dan kami akan melampaui elemen formulir klasik untuk membuat aplikasi web dan situs web yang unik dan menyenangkan.

Catatan : Meskipun sebagian besar peningkatan kode dalam artikel ini terkait dengan web (karena saya tidak tahu Swift atau Java), praktik terbaik kegunaan berlaku untuk aplikasi seluler .

Desain Formulir 101: Memprioritaskan Keterbacaan dan Keterbacaan

“Bentuk adalah nama, nilai, pasangan, dalam struktur untuk menyimpan data di komputer yang dikeluarkan sebagai label dan bidang input untuk manusia.” Ini adalah kutipan langsung dari Luke Wroblewski di sebuah konferensi. Seperti dia, saya percaya bahwa sebagian besar masalah kegunaan bentuk berasal dari kecenderungan untuk menyajikan struktur database kepada pengguna.

Arsitektur Informasi yang Kuat

Untuk membangun formulir yang lebih baik, pertama-tama Anda perlu mengambil beberapa langkah dari struktur database Anda. Cobalah untuk memahami bagaimana pengguna ingin mengisi formulir. Di sinilah melakukan beberapa pengujian kegunaan dan penelitian pengguna pada formulir Anda menjadi berguna. Model mental pengguna adalah konsep UX yang dapat membantu Anda dengan itu. Nielsen Norman Group menggambarkannya sebagai "apa yang diyakini pengguna tentang sistem yang ada". Minta penguji Anda untuk berpikir keras dan memberi tahu Anda bagaimana mereka akan mengisi formulir. Langkah mana yang mereka harapkan? Apa yang datang lebih dulu? Apa yang terjadi selanjutnya? Ini akan memberi Anda ide yang lebih baik tentang bagaimana menyusun formulir Anda dengan cara yang lebih ramah pengguna.

Mengelompokkan bidang yang dimiliki bersama secara visual juga akan membantu pengguna mengisi formulir. Dalam kode, gunakan tag fieldset untuk mengelompokkannya secara terprogram. Ini juga akan membantu pembaca layar memahami hierarki.

Jika formulirnya panjang, jangan ekspos semuanya secara default . Jadilah cerdas tentang apa yang Anda tampilkan. Gunakan percabangan dengan bijak untuk menampilkan hanya bidang yang dibutuhkan orang. Dalam formulir checkout, misalnya, jangan tampilkan semua bidang mendetail untuk semua opsi pengiriman. Ini akan membanjiri pengguna. Tampilkan informasi yang cukup untuk membantu mereka memilih opsi pengiriman yang tepat. Kemudian, tampilkan hanya detail dan bidang yang terkait dengan pilihan itu.

Rentang perhatian pengguna semakin pendek seiring waktu: Mintalah hal-hal opsional di akhir formulir. Misalnya, jika formulir Anda adalah survei kepuasan pelanggan, mintalah informasi demografis di bagian akhir. Lebih baik lagi, isi otomatis, jika memungkinkan. Tanyakan pengguna hanya untuk apa yang diperlukan.

Terakhir, rencanakan ke depan untuk pelokalan: Apa yang akan terjadi ketika formulir Anda diterjemahkan? Apa yang akan terjadi, katakanlah, untuk Jerman? Apakah desain Anda akan tetap berfungsi?

Penempatan Label Dan Optimasi Input

Tata Letak Satu Kolom Berfungsi Terbaik

Karena kurangnya ruang, Anda tidak mendapatkan opsi tanpa akhir untuk menempatkan label dan bidang di layar seluler:

• Menampilkan bidang dalam tata letak satu kolom . Tidak ada ruang di ponsel untuk beberapa kolom. Formulir multi-kolom juga bukan ide bagus di desktop.
• Dalam mode potret, lebih baik menempatkan label di atas bidang sehingga pengguna dapat melihat apa yang ada di bidang saat mereka mengetik.

• Dalam mode lansekap, ketinggian layar dikurangi. Anda mungkin ingin meletakkan label di sebelah kiri dan input di sebelah kanan . Tetapi ujilah untuk memastikan itu berhasil.

Untuk lebih lanjut tentang penempatan label, lihat “Kegunaan Formulir Seluler: Tempatkan Label di Atas Bidang” dari Baymard Institute.

Label Harus Jelas Dan Terlihat Dan Bekerja Tanpa Konteks

Ingatlah bahwa segera setelah bidang mendapatkan fokus, keyboard akan terbuka dan akan mengambil setidaknya sepertiga dari area layar. Pada layar ponsel kecil, pengguna juga harus menggulir untuk mengisi formulir. Ini berarti bahwa mereka akan kehilangan bagian dari konteks saat mengisi formulir. Rencanakan sesuai:

• Label Anda harus berupa teks yang jelas dan terlihat yang dapat dibaca dan dipahami tanpa konteks. Pengguna harus dapat menyelesaikan setiap pasangan label dan bidang sebagai tugas terpisah, meskipun mereka kehilangan konteks.

• Hindari jargon, singkatan, dan bahasa khusus industri kapan pun Anda bisa.
• Konsisten. Jika Anda menggunakan "pelanggan" dalam label sekali, tetap gunakan kata itu. Hindari menggunakan "klien" nanti karena dapat membingungkan pengguna.
• Ukuran font harus cukup besar. Uji formulir Anda di perangkat nyata sesegera mungkin, dan sesuaikan ukurannya.
• Teks huruf besar semua mungkin sulit dibaca oleh sebagian pengguna. Anda mungkin ingin menghindari penggunaan teks huruf besar semua pada label.
• Salinan label harus pendek dan dapat dipindai. Jika bidang membutuhkan klarifikasi, jangan masukkan ke dalam label. Gunakan deskripsi bidang sebagai gantinya.

Praktik Terbaik Ukuran Input

Jika memungkinkan, ukuran elemen masukan harus sesuai dengan ukuran konten yang diharapkan . Ini akan membantu pengguna mengisi formulir dengan cepat dan memahami apa yang diharapkan.

Menggunakan Masker Untuk Menghindari Pemisahan Input Pada Seluler

Jangan membagi input hanya demi memformat . Ini sangat mengganggu di ponsel, di mana pengguna tidak dapat menggunakan keyboard untuk menavigasi antar bidang. Dibutuhkan ketukan ekstra hanya untuk pergi ke bidang berikutnya untuk mengisi formulir. Anda mungkin berpikir, "Tapi saya akan secara otomatis menempatkan fokus pada bidang berikutnya ketika saya mendapatkan jumlah karakter yang diperlukan di bidang itu". Itu bisa berhasil. Tetapi Anda akan mengambil kendali UI, yang menjadi tidak dapat diprediksi oleh pengguna. Juga, akan merepotkan jika Anda secara otomatis mengirim mereka ke bidang berikutnya dan mereka perlu memperbaiki sesuatu di bidang terakhir. Akhirnya, lebih rumit untuk menebak apa yang wajib dengan input terpisah. Jadi, mari kita berhenti memainkan game "Tapi bagaimana jika" dan tidak membagi input.

Saya mengerti: Anda masih ingin dapat memformat data pengguna Anda dalam potongan-potongan kecil untuk membantu mereka mengisi bidang Anda. Dan Anda benar sekali tentang itu. Untuk melakukannya, Anda bisa menggunakan masker . Alih-alih membagi input, cukup letakkan topeng di atasnya, untuk membantu pengguna mengisinya secara visual. Berikut adalah contoh video tentang tampilan topeng untuk membantu pengguna mengisi bidang kartu kredit:

Masker membantu mencegah kesalahan dengan memandu pengguna ke format yang benar. Hindari mengungkapkannya secara bertahap — tampilkan formatnya secara langsung. Juga, hindari menempatkan nilai palsu di topeng . Pengguna mungkin mengira itu sudah terisi. Itu sebabnya saya mengganti angka dengan sedikit "X" di demo saya. Temukan yang terbaik untuk jenis input Anda.

Terakhir, ingatlah bahwa beberapa data dapat bervariasi antar negara, dan terkadang formatnya juga berubah (nomor telepon, misalnya). Rencanakan sesuai.

Deskripsi Bidang yang Efisien

Menampilkan deskripsi bidang yang efisien dapat membuat perbedaan antara pengalaman formulir yang mulus dan menyakitkan.

Deskripsi Dapat Digunakan Untuk Apa?

Deskripsi dapat membantu pengguna dalam banyak cara. Berikut adalah beberapa contoh.

• Apa yang Sebenarnya Anda Minta?
  

  Untuk alasan apa pun yang terkait dengan basis data, beberapa perusahaan pengiriman meminta bidang "Alamat 1" dan "Alamat 2". Ini sangat membingungkan bagi pengguna, tetapi Anda mungkin tidak punya pilihan di sini. Tambahkan bidang deskripsi untuk membantu pengguna memahami apa yang mereka butuhkan untuk dimasukkan ke dalam setiap bidang.

  

  Hal yang sama berlaku untuk akronim dan singkatan. Saya tahu saya mengatakan bahwa Anda harus menghindarinya, tetapi terkadang Anda tidak bisa. Jika Anda mengerjakan formulir kompleks untuk industri tertentu, misalnya, mereka mungkin memiliki singkatan sendiri. Setiap pengguna baru yang perlu mengisi formulir mungkin tidak terbiasa (belum) dengan singkatan tersebut. Memiliki deskripsi yang tersedia di suatu tempat akan membantu mereka.

• Mengapa Anda Membutuhkan Informasi Ini?
  Pengguna mungkin enggan memberi Anda informasi pribadi jika mereka tidak mengerti mengapa Anda membutuhkannya dan apa yang akan Anda lakukan dengannya . Namun terkadang Anda masih perlu menanyakan informasi tersebut untuk alasan hukum (seperti tanggal lahir untuk situs web yang menjual alkohol). Menggunakan deskripsi lapangan di sini akan membantu pengguna memahami mengapa informasi semacam ini diperlukan.
  
  

  Di situs web e-niaga, Anda mungkin ingin menanyakan nomor telepon pengguna jika pengirim perlu menghubungi mereka. Ini adalah alasan yang sah. Jadi, sekali lagi, gunakan deskripsi untuk menjelaskan kepada pengguna e-commerce mengapa Anda memerlukan nomor telepon mereka.

  

“Di Mana Saya Menemukan Informasi?”
Jika pengguna Anda perlu menemukan informasi tertentu di tempat lain untuk mengisi formulir, beri tahu mereka di mana menemukannya. Saya bekerja pada aplikasi seluler yang memungkinkan pengguna melacak rumah mereka. Pengguna perlu memasangkan aplikasi ke perangkat pemantauan menggunakan nomor seri. Tidak mudah menemukan nomor seri ini di perangkat; itu membutuhkan beberapa instruksi. Kami menambahkan sedikit ? tombol di sebelah bidang nomor seri. Tombol membuka modal yang menunjukkan gambar dan beberapa indikasi untuk membantu pengguna memahami di mana menemukan nomor seri pada perangkat pemantauan. Situs web e-niaga melakukan hal yang sama dengan kode promo: Mereka memberikan indikator yang memberi tahu pengguna di mana menemukan kode tersebut.



• “Bagaimana Saya Memformat Informasi?”
  Beberapa bidang memerlukan format tertentu . Dalam hal ini, gunakan deskripsi untuk memberi tahu pengguna aturan pemformatan di awal. Berikut adalah beberapa contoh:
  • Nomor telepon: apakah saya perlu meletakkan kode panggilan internasional (+xx) di depan kolom?
  • Apakah ada panjang maksimum? Twitter di seluler melakukan pekerjaan yang baik dengan yang satu itu.
  • Saat berurusan dengan jumlah moneter, apakah formatnya dengan koma (seperti 10.000) atau spasi (seperti 10.000)?
  • Format apa yang Anda harapkan untuk tanggal? Saya akan membiarkan Anda memeriksa di Wikipedia apa mimpi buruk itu. Perbedaan antara DD MM YY dan MM DD YY dapat menyebabkan *banyak* masalah bagi pengguna saat melakukan pemesanan online.
  Perhatikan bahwa banyak dari masalah pemformatan tersebut dapat diselesaikan dengan masker input. Kami akan membahasnya nanti di artikel (atau Anda bisa langsung masuk jika Anda tidak sabar).

  

Cara Menampilkan Deskripsi

Dalam contoh di atas, kami melihat beberapa cara untuk menampilkan deskripsi bidang. Berikut ini ringkasan yang harus dilakukan:

• Deskripsi sebaris harus langsung terlihat dan ditampilkan di sebelah bidang.
• Jika Anda membutuhkan deskripsi yang lebih mendalam dengan konten yang berat, Anda dapat menggunakan tooltips atau modals . Tooltips umumnya dipicu saat mengarahkan kursor ke desktop dan saat mengetuk ponsel. Hal yang sama berlaku untuk modals: Buka ketika pengguna mengetuk ikon bantuan atau tautan "lihat lebih banyak", misalnya.

Hati-hati Dengan Placeholder

Saya mengerti: tergoda untuk menghapus bidang di seluler untuk mendapatkan ruang dan menggunakan placeholder sebagai gantinya. Kita semua pernah melalui jalan itu. Tapi tolong jangan. Spesifikasi HML5 jelas tentang ini: "Atribut placeholder mewakili petunjuk singkat (kata atau frasa pendek) yang dimaksudkan untuk membantu pengguna dengan entri data". Dan inilah alasannya:

• Placeholder menghilang saat pengguna mulai mengetik. Pengguna kemudian harus mengandalkan memori jangka pendek untuk mengingat apa yang seharusnya mereka masukkan ke dalam lapangan . Jika tidak bisa, mereka perlu mengosongkan kolom untuk melihat indikasi.
• Sulit bagi pengguna untuk memeriksa ulang bidang sebelum mengirimkan karena bidang tidak lagi memiliki indikasi label.
• Sulit untuk memulihkan dari kesalahan setelah bidang dikirimkan karena, sekali lagi, tidak ada label untuk membantu pengguna.

Meskipun Anda menggunakan placeholder dengan label, Anda mungkin masih memiliki beberapa masalah. Sulit untuk membedakan antara bidang yang diisi dan bidang dengan placeholder . Saya seorang desainer UX yang menulis tentang desain formulir seluler dan bahkan minggu lalu saya ditipu oleh salah satunya. Jika itu terjadi pada saya, itu akan terjadi pada pengguna Anda — percayalah pada saya. Terakhir, sebagian besar placeholder memiliki teks abu-abu terang, jadi Anda mungkin juga memiliki beberapa masalah kontras.

Jika Anda ingin membahas topik ini lebih dalam, ada artikel bagus berjudul “Atribut Placeholder Bukan Label, dan juga Joshua Winn dan FeedbackGuru menjelaskan secara rinci mengapa ini adalah ide yang buruk. Nielsen Norman Group juga menulis artikel tentang topik tersebut, berjudul “Placeholder di Bidang Formulir Berbahaya.”

Placeholder tidak wajib dalam HTML5 . Dari sudut pandang kegunaan, Anda tentu tidak memerlukan placeholder di setiap bidang formulir Anda. Tetapi dengan adopsi besar-besaran Bootstrap dan kerangka kerja lainnya, sepertinya banyak orang hanya menyalin dan menempelkan komponen. Komponen-komponen itu memiliki placeholder, jadi saya kira orang merasa berkewajiban untuk menambahkan sesuatu ke placeholder dalam kode? Jika placeholder formulir Anda terlihat seperti "Silakan isi — label Anda — di sini", Anda salah melakukannya.

Namun, label di dalam bidang dapat berfungsi dengan baik untuk formulir pendek yang bidangnya dapat diprediksi . Formulir login adalah kandidat yang baik untuk ini. Tapi tolong jangan gunakan placeholder HTML5 untuk mengkode ini. Gunakan label asli dalam kode dan pindahkan dengan CSS dan JavaScript.

Sejak kesuksesan desain material Android, sebuah pola mulai muncul: label mengambang. Label ini berada di dalam bidang ketika bidang tidak diisi, sehingga membutuhkan sedikit ruang vertikal di ponsel. Saat pengguna mulai berinteraksi dengan bidang, label bergerak di atas bidang.

Ini terlihat seperti cara yang menarik untuk mendapatkan beberapa ruang, tanpa mengalami masalah "placeholder di tempat label" yang dikutip di atas. Namun demikian, itu tidak menyelesaikan masalah pengguna yang mungkin salah mengira placeholder untuk konten yang diisi.

Pengurangan Biaya Interaksi Untuk Formulir yang Berhasil

Mengurangi biaya interaksi (yaitu jumlah ketukan, gesekan, dll.) dari pengguna yang mencapai tugas mereka akan membantu Anda membangun pengalaman formulir yang mulus. Ada berbagai teknik untuk mencapai itu. Mari kita lihat beberapa dari mereka secara rinci.

Sebuah Studi Ajaib Di Internet Memberitahu Saya Untuk Mengurangi Jumlah Bidang

Lebih banyak bidang berarti lebih sedikit konversi, bukan? Anda mungkin telah menemukan "kami mengurangi formulir langganan kami dari 11 menjadi 4 bidang, dan itu meningkatkan konversi sebesar 160%". Ini klasik. Dan jika Anda melihat formulir kontak mereka, itu masuk akal. Mengapa pengguna ingin mengisi 11 bidang hanya untuk menghubungi perusahaan? Anda tidak dapat meminta komitmen sebesar itu kepada orang-orang yang hampir tidak mengenal Anda, bukan?

Mulailah dengan hanya meminta informasi yang berguna. Mengapa Anda memerlukan jenis kelamin seseorang untuk membuat akun untuknya? Mengapa Anda memiliki dua baris untuk alamat jika formulir berlangganan Anda untuk layanan online?

Mintalah hanya informasi yang Anda butuhkan. Dan kemudian meminta informasi dalam konteks. Jika Anda memiliki situs web e-niaga, pengguna mungkin lebih cenderung memberi Anda alamat mereka di bagian pengiriman saat proses pembayaran daripada saat mereka mendaftar. Ini akan membuat formulir pendaftaran e-commerce Anda jadi lebih mudah untuk diisi di ponsel!

Juga, jangan percaya begitu saja setiap statistik dan studi yang Anda temukan di Internet. Ingat studi 11-bidang-ke-4? Studi lain yang lebih baru menunjukkan bahwa dengan mengurangi bidang dari 9 menjadi 6, konversi turun sebesar 14%. Mengejutkan, bukan? Mengapa? Yah, mereka menghapus bidang yang paling menarik. Singkat cerita, mereka kemudian kembali ke 9 bidang, menempatkan yang paling penting di atas, dan voila, konversi meningkat sebesar 19,21%.

Intinya adalah bahwa meskipun studi ini menarik, situs web tersebut bukanlah situs web Anda. Jangan membabi buta mempercayai studi pertama yang Anda temukan di Internet.

Jadi, apa yang bisa Anda lakukan? Uji. Uji. Dan uji!

• Lakukan beberapa pengujian pengguna untuk melihat waktu penyelesaian formulir seluler Anda.
• Mengukur drop out.
• Mengukur masalah dengan bidang tertentu.
• Ukur frustrasi yang terkait dengan bidang tertentu. Seberapa bersediakah pengguna memberikan informasi itu? Seberapa pribadikah informasi itu?

Mengoptimalkan Interaksi Sentuh

Membuat Kontrol Ramah Sentuh

Jika bidang Anda terlalu kecil atau sulit dijangkau, pengguna akan membuat kesalahan dan akan membutuhkan interaksi ekstra untuk mencapai tujuan mereka. Ingat hukum Fitt? Anda juga dapat menerapkannya pada desain seluler: Jadikan label, bidang, dan kontrol formulir Anda mudah diketuk dengan meningkatkan ukuran target sentuh . Untuk label di web, sedikit lebih banyak bantalan dapat meningkatkan area yang dapat disentuh. Terkadang Anda juga perlu menambahkan beberapa margin di antara elemen untuk menghindari ketukan yang terlewat.

Juga, jangan lupa untuk menautkan label dengan komponennya dengan memasangkan nilai for dan ID. Dengan begitu, jika pengguna melewatkan ketukan pada label, bidang yang sesuai akan tetap mendapatkan fokus.

Steven Hoober melakukan beberapa riset pengguna di area sentuh. Anda akan menemukan ringkasan di "Merancang untuk Sentuhan". Berdasarkan apa yang dia temukan, dia membuat alat penggaris plastik kecil: template sentuh seluler. Alat ini dapat membantu Anda memastikan area sentuh Anda cukup besar untuk formulir seluler dan lebih umum untuk desain seluler.

Untuk mempelajari lebih lanjut tentang mendesain untuk sentuhan, Anda dapat membaca yang berikut ini:

• “Desain Ramah Jari: Ukuran Target Layar Sentuh Seluler yang Ideal”
• “Zona Jempol: Mendesain untuk Pengguna Seluler”

Memberikan Umpan Balik

Pengguna seluler tidak memiliki mouse (tidak main-main), jadi mereka tidak mendapatkan umpan balik "klik" yang didapat pengguna desktop saat menekan tombol. Pengguna formulir seluler membutuhkan umpan balik yang jelas saat berinteraksi dengan elemen:

• Berikan status fokus untuk bidang formulir yang berinteraksi dengan pengguna.
• Berikan umpan balik visual saat pengguna berinteraksi dengan tombol .

Saya bukan penggemar berat efek riak desain material pada tombol. Tapi saya harus mengakui bahwa animasi di Android memberikan umpan balik yang jelas ketika pengguna berinteraksi dengan tombol.

Hormati Urutan Tombol Berikutnya Dan Sebelumnya

Terakhir, hormati tombol berikutnya dan sebelumnya pada keyboard seluler. Pengguna dapat menggunakannya untuk menavigasi bidang dengan cepat. Urutan tabindex harus sesuai dengan urutan visual bidang dan komponen.

Hindari Dropdown Di Ponsel Jika Memungkinkan

Dropdown (elemen pemilihan HTML) di web memerlukan banyak tab dan interaksi. Oleh karena itu, seperti yang dikatakan Luke Wroblewski, mereka harus menjadi UI pilihan terakhir. Banyak komponen UI lainnya bekerja lebih baik daripada dropdown dalam banyak situasi.

Kontrol segmen dan tombol radio adalah alternatif yang baik untuk dropdown jika Anda memiliki antara dua dan empat opsi. Mengapa menyembunyikan opsi di bawah dropdown ketika Anda dapat menampilkan semuanya secara langsung di satu layar? Perhatikan bahwa, seperti tombol radio, kontrol segmen saling eksklusif.

Daftar negara adalah kandidat yang baik untuk sebuah komponen. Dropdown lebih dari seratus negara adalah mimpi buruk interaksi di seluler. Tidak apa-apa jika Anda mencari Afghanistan (di awal daftar) atau Zimbabwe (di akhir daftar). Jika Anda mencari Luksemburg, Anda akan berakhir dalam permainan menggulir untuk mencapai bagian tengah daftar, melangkah terlalu jauh ke huruf M, mencoba kembali ke L, dan seterusnya.

Dropdown panjang dapat diganti dengan bidang input teks prediktif . Saat pengguna mulai mengetik L, antarmuka akan mengusulkan sembilan negara. Jika mereka menambahkan U — voila! - Luksemburg itu. Empat interaksi, bukan dua, versus sebanyak enam atau tujuh interaksi bergulir dengan tarik-turun.

Jika Anda membutuhkan pengguna untuk memilih tanggal, lupakan membaginya menjadi dropdown hari, bulan, dan tahun seperti yang biasa dilakukan orang pada formulir kertas. Ganti beberapa tarik-turun tanggal dengan pemilih tanggal . type=date berfungsi dalam banyak kasus. Tetapi Anda mungkin memiliki beberapa kebutuhan khusus dan akhirnya membangun pemilih tanggal Anda sendiri dalam JavaScript, terutama jika Anda berada dalam bisnis pemesanan (hotel, mobil, penerbangan).

Dalam artikelnya “Mobile DropDowns Revisited”, Klaus Schaefers menjelaskan bagaimana menggunakan pemilih tanggal untuk tanggal kedatangan dan keberangkatan membuat interaksi 60% lebih cepat.

Mari kita tetap dengan bisnis pemesanan. Misalkan pengguna perlu menambahkan beberapa pelancong ke rencana perjalanan mereka. Anda bisa **mengganti dropdown* dengan *stepper** untuk memilih jumlah penumpang. Stepper adalah kontrol yang memungkinkan pengguna untuk menambah dan mengurangi nilai hanya dengan mengetuk tombol + dan - . Itu cenderung lebih cepat ketika kurang dari enam orang harus ditambahkan. Ini juga lebih intuitif. Di bawah ini adalah contoh stepper yang digunakan di aplikasi Airbnb asli Android untuk memilih tamu, dan di situs web Kayak yang dioptimalkan untuk seluler untuk menambahkan penumpang.

Alternatif terakhir untuk dropdown adalah tampilan daftar. Opsi akan dicantumkan dalam subview tertentu, seperti tombol radio , misalnya. Ini sebagian besar cara kerja pengaturan Android.

Menjadi Cerdas Dengan Penyelesaian Otomatis

Jika Anda ingin mengurangi biaya interaksi formulir Anda, jadilah cerdas. Jangan meminta informasi yang dapat Anda deteksi atau tebak secara otomatis berdasarkan informasi lain yang diberikan pengguna kepada Anda. Pelengkapan otomatis dan isi ulang sebanyak yang Anda bisa.

Tempat dan Alamat

Jika pengguna mencari tempat atau perlu memasukkan alamat, Anda dapat menawarkan pelengkapan otomatis untuk membantu mereka. Saat mereka mengetik, API akan mengisi sisa alamat untuk mereka. Ini juga mengurangi kesalahan.

Anda dapat menggunakan:

• Google Places API
• Algolia Places, yang didasarkan pada OpenStreetMap

Di Prancis dan banyak negara lain, Anda dapat menebak kota berdasarkan kode area. Jadi, jika pengguna Prancis memasukkan kode area, Anda dapat secara otomatis melengkapi atau setidaknya mengusulkan kota. Negara saya, Luksemburg, kecil (jangan mengolok-olok saya). Kode area saya ditautkan ke jalan saya. Jadi, jika saya memasukkan kode area saya, formulir tersebut seharusnya dapat menyarankan jalan saya.

Kartu kredit

Area lain di mana deteksi otomatis mudah dilakukan adalah kartu kredit. Anda tidak perlu bertanya kepada pengguna jenis kartu kredit apa yang mereka miliki. Anda dapat mendeteksi ini secara otomatis berdasarkan nomor awal yang mereka masukkan. Bahkan ada perpustakaan yang dapat melakukan pekerjaan itu untuk Anda.

Menggunakan Pelengkapan Otomatis HTML5 (IsiOtomatis)

Atribut pelengkapan otomatis HTML dapat mengisi kolom sebelumnya berdasarkan input pengguna sebelumnya. Atribut ini memiliki status on dan off. Beberapa orang pintar telah mulai mengerjakan spesifikasi untuk membuatnya lebih kuat dan untuk memperluas atribut pelengkapan otomatis untuk bidang formulir. WHATWG juga memiliki daftar yang menarik.

Chrome dan browser seluler lainnya sudah mendukung beberapa nilai tambahan untuk kartu kredit dan nama. Ini berarti bahwa pengguna dapat mengisi formulir dengan nama dan data kartu kredit yang mereka gunakan di situs web lain.

Singkatnya, ketika Anda harus memilih di antara sistem yang berbeda, hitung jumlah interaksi yang akan dibutuhkan masing-masing sistem.

Kesalahan Terjadi: Menangani Kesalahan Dalam Formulir Seluler

Langkah terakhir dalam perjalanan kami menuju formulir seluler yang lebih baik adalah menangani kesalahan dan kesalahan. Kami dapat mencoba mengurangi kesalahan untuk meringankan beban kognitif pengguna. Kami juga dapat membantu mereka pulih dari kesalahan, karena tidak peduli seberapa bagus desain formulir Anda, kesalahan tetap terjadi.

Menghindari Kesalahan Saat Mengisi Formulir

“Mencegah lebih baik daripada mengobati,” kata ibu saya dulu. Itu juga berlaku untuk desain formulir: Mencegah kesalahan akan meningkatkan pengalaman formulir seluler Anda.

Batasan Format Eksplisit

“Jadilah konservatif dalam apa yang Anda lakukan. Jadilah liberal dalam apa yang Anda terima dari orang lain.” Prinsip kekokohan ini dapat diterapkan untuk membentuk bidang juga. Jika memungkinkan, biarkan pengguna memasukkan data dalam format apa pun.

Jika Anda merasa perlu membatasi apa yang dapat dimasukkan pengguna di lapangan, mulailah dengan bertanya pada diri sendiri “mengapa”. Di bidang pengalaman pengguna, kami memiliki teknik yang disebut "tiga mengapa". Jika jawabannya adalah “karena database bla bla”, mungkin sudah waktunya untuk mengubah keadaan. Misalnya, mengapa Anda menolak karakter khusus seperti e, a dan o di bidang nama pengguna? Saya menulis artikel yang menjelaskan betapa kasarnya formulir bagi saya ketika saya mencoba memasukkan "Stephanie" sebagai nama pengguna. Saya masih mencoba mencari alasan bagus untuk itu (terlepas dari alasan basis data).

Jika Anda memiliki alasan yang baik untuk meminta format tertentu dari pengguna, nyatakan ini di awal . Anda dapat menggunakan HTML5 placeholder s untuk memberi petunjuk kepada pengguna tentang seperti apa tampilan data, tetapi sekali lagi, berhati-hatilah dengan itu. Anda juga bisa menggunakan semua teknik deskripsi lapangan yang dijelaskan di awal artikel ini. Terakhir, masker input dapat memandu pengguna menuju format yang tepat.

Menandai Bidang Wajib (Dan Yang Opsional)

Jangan menunggu pengguna mengirimkan formulir setengah jadi untuk memberi tahu mereka tentang bidang yang wajib diisi. Jika suatu bidang wajib, pengguna harus mengetahuinya . Menandai bidang wajib dengan tanda bintang ( * ) dan legenda telah menjadi pola standar untuk formulir. Bagian yang baik adalah tidak memakan banyak ruang. Masalahnya adalah ia tidak memiliki nilai semantik, sehingga dapat menyebabkan masalah aksesibilitas jika dikodekan dengan buruk dan jika Anda mengandalkan kebiasaan orang dengan interaksi bentuk.

Sebagai gantinya, Anda dapat secara eksplisit menandai bidang wajib dan opsional dengan kata-kata "wajib" (atau "wajib") dan "opsional". Baik Baymard Institute dan Luke Wroblewski setuju akan hal itu. Ini menghindari ambiguitas dengan formulir panjang di ponsel, seperti saat menggunakan penggulung, melanjutkan dengan sesuatu yang lain, lalu kembali dan tidak mengingat apakah bidang wajib ditandai dengan tanda bintang atau yang lainnya.

Pada akhirnya, keputusan tentang cara menandai bidang tersebut akan bergantung pada desain dan panjang bidang serta konteksnya. Cara terbaik untuk mengetahui apakah Anda telah membuat keputusan yang tepat adalah, sekali lagi, dengan menguji formulir.

Default Masuk akal

Berhati-hatilah dengan opsi yang dipilih secara default dalam formulir . Ketika saya melamar pekerjaan saya sebelumnya, ada formulir informasi. Status pernikahan adalah opsional. Mereka membuat elemen pertama di dropdown, "bercerai", bidang default. Jadi, saya tidak dapat menjawab (karena ini adalah bidang opsional) dan membiarkan sistem percaya bahwa saya telah bercerai, atau memperbaikinya dan mengungkapkan status perkawinan saya yang sebenarnya bahkan jika saya tidak mau.

Juga, berhati-hatilah dengan jenis kelamin. Sekali lagi, memiliki pilihan untuk orang-orang yang tidak ingin mengungkapkannya; jelaskan mengapa Anda menanyakan jenis kelamin mereka; lebih baik lagi, minta kata ganti, atau jangan tanya jika Anda tidak benar-benar perlu. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• Saat Masuk
  Dalam formulir login, opsi kata sandi topeng/buka kedok akan sangat meningkatkan pengalaman pengguna.
  Amazon memiliki sejarah yang menarik tentang iterasi kata sandi dalam formulir loginnya. Dulu memiliki versi di mana Anda tidak dapat melihat kata sandinya. Iterasi berikutnya memungkinkan pengguna untuk mengungkapkannya. Kemudian, kata sandi terungkap secara default, dan Anda bisa menyembunyikannya. Inilah yang tampak pada tahun 2015:

  

  Amazon menguji versi terakhir, dan 60% orang curiga. Jadi, mereka mengganti kotak centang "sembunyikan kata sandi" yang tidak dicentang dengan kotak centang "tampilkan kata sandi". Ini akan menampilkan kata sandi dalam karakter yang lebih kecil, di bawah bidang, saat pengguna mengetik. Inilah yang terlihat pada saat menulis artikel ini:

  

  Seperti yang Anda lihat, selalu ada ruang untuk perbaikan.

Validasi Sebaris

Jika Anda terbiasa dengan prinsip kegunaan, Anda mungkin tahu hukum kedekatan Gestalt. Di seluler, hindari ringkasan kesalahan di bagian atas halaman, tanpa informasi kontekstual, setelah pengguna mengetuk tombol kirim.

Sebaliknya, pesan kesalahan harus ditempatkan dekat dengan kesalahan itu sendiri .

Validasi Waktu Nyata

Anda juga tidak perlu menunggu sampai pengguna menekan tombol kirim. Anda dapat memvalidasi bidang dan menampilkan umpan balik saat pengguna mengisinya .

Beberapa tips:

• Seperti disebutkan sebelumnya, bidang kata sandi akan mendapat manfaat dari validasi waktu nyata dan umpan balik pada setiap penekanan tombol.
• Anda mungkin juga ingin memvalidasi nama pengguna secara real time saat akun dibuat, untuk memastikan mereka tersedia. Twitter melakukan pekerjaan yang baik untuk itu.
• Jangan memvalidasi setiap penekanan tombol. Tunggu hingga pengguna selesai mengetik. (Gunakan blur JavaScript untuk formulir web, atau tunggu beberapa detik untuk mendeteksi ketidakaktifan.)

Catatan : *Mihael Konjevic telah menulis artikel bagus tentang “Validasi Sebaris dalam Formulir: Merancang Pengalaman.” Dia menjelaskan konsep “ hadiah awal, hukuman terlambat .”*

“Jika pengguna memasukkan data di bidang yang dalam keadaan valid , lakukan validasi setelah entri data.”

“Jika pengguna memasukkan data di bidang yang dalam keadaan tidak valid , lakukan validasi selama entri data.”

Warna Penting

Saya tidak mengatakan bahwa warna penting hanya karena warna rambut jahe, merah muda, dan ungu saya saat ini. Warna sangat penting dalam desain bentuk.

Ada beberapa konvensi di web yang tidak ingin Anda langgar. Pengguna yang tidak buta warna tahu bahwa merah untuk kesalahan, kuning untuk peringatan, dan hijau hampir selalu untuk konfirmasi atau keberhasilan. Yang terbaik adalah tetap dengan tiga warna ini. Namun, warna merah bisa membuat orang cemas. Pengguna mungkin berpikir mereka telah membuat kesalahan yang sangat serius. Menggunakan oranye atau kuning untuk pesan kesalahan dapat mengurangi kepanikan. Masalah dengan kuning dan oranye adalah sulit untuk menemukan warna ramah buta warna dari mereka.

Berbicara tentang buta warna: Warna seharusnya bukan satu-satunya cara untuk menyampaikan pesan kesalahan . Ini adalah kriteria aksesibilitas.

Pada contoh di bawah di sebelah kiri, bidang dengan kesalahan berwarna oranye, dan bidang yang telah diperbaiki telah berubah menjadi hijau. Saya menggunakan alat pengujian buta warna untuk mengambil tangkapan layar di tengah: Anda tidak dapat lagi membedakan antara batas abu-abu default dan batas hijau. Menambahkan beberapa ikon di tangkapan layar terakhir memastikan bahwa pesan kesalahan disampaikan kepada orang buta warna.

Memulihkan Dari Kesalahan: Menulis Pesan Kesalahan yang Mudah Digunakan

Pada titik ini, kami telah melakukan segala yang kami bisa untuk membantu pengguna mengisi formulir kami dan menghindari kesalahan. Namun terkadang, terlepas dari upaya terbaik kita, kesalahan terjadi. Saatnya mencari cara untuk membantu pengguna pulih dari kesalahan tersebut.

Pertama, ingat: Jangan membajak kontrol sistem. Jika masalah tidak kritis, pengguna harus dapat terus berinteraksi dengan sebanyak mungkin antarmuka lainnya. Hindari pesan kesalahan peringatan JavaScript dan modal yang memblokir pengguna bila memungkinkan. Juga, jika formulir Anda memerlukan izin, mintalah dalam alur penggunaan. Jika izin tidak diberikan, jangan anggap ini sebagai kesalahan karena memang tidak demikian. Berhati-hatilah dengan salinan yang Anda gunakan di sini.

Anda Bukan Robot, Begitu Juga Pengguna Anda

Robot itu keren, saya tahu. Tapi Anda bukan robot, begitu pula pengguna Anda. Namun begitu banyak pesan kesalahan yang masih ditulis dengan sangat buruk. Berikut adalah beberapa tip dalam hal pesan kesalahan yang ramah manusia:

• Jangan pernah tampilkan pesan kesalahan mentah, seperti “Terjadi kesalahan tipe 2393. Server tidak dapat menyelesaikan operasi.” Sebaliknya, jelaskan apa yang terjadi dalam bahasa manusia dan mengapa itu terjadi .
• Jangan pernah menampilkan pesan kesalahan buntu, seperti "Terjadi kesalahan". Sebaliknya menyarankan cara untuk memulihkan dari kesalahan . Tulis salinan yang dapat ditindaklanjuti.
• Jangan pernah menampilkan pesan kesalahan yang tidak jelas, seperti "Server dengan nama host yang ditentukan tidak dapat ditemukan", dengan tombol "Coba lagi". Sebaliknya, buat pesan kesalahan informatif dan konsisten . Tolong jangan terdengar seperti robot.
• Jangan berasumsi bahwa orang tahu konteks pesan. Pengguna Anda bukan geek yang paham teknologi. Sebaliknya, jelaskan kepada mereka dalam bahasa sederhana, tanpa jargon teknis, bagaimana memulihkan dari kesalahan ini .

Hati-hati Bahasa yang Anda Gunakan Dalam Pesan

Apa pun yang Anda tulis, hindari membuat orang merasa bodoh tentang suatu kesalahan. Jika memungkinkan, tinggalkan kata-kata negatif ; mereka cenderung menakut-nakuti orang dan membuat mereka semakin cemas. Gunakan nada yang sopan, positif, dan tegas.

Jangan salahkan pengguna untuk kesalahan ; menyalahkan sistem sebagai gantinya. Sistem tidak akan menyimpan dendam, aku janji. Alihkan perhatian pengguna pada bagaimana sistem tidak dapat memproses tindakan, dan jelaskan kepada mereka bagaimana menemukan solusi .

Trik kecil adalah membaca pesan Anda sendiri dengan keras. Ini akan membantu Anda mendengar apakah itu berhasil atau terlalu keras atau terlalu santai, dll.

Anda juga bisa berkreasi dengan pesan kesalahan dan menggabungkan citra dan humor agar tidak terlalu mengancam. Ini akan sangat bergantung pada identitas dan nada merek Anda.

Untuk membantu Anda menulis pesan kesalahan yang lebih baik, saya sarankan Anda membaca yang berikut ini:

• “Daftar Periksa Mikrokopi 6 Poin Untuk Tim Produk Tanpa Penulis UX”
• “Seni dari Pesan Kesalahan: Menulis Salinan yang Jelas dan Bermanfaat Saat Terjadi Kesalahan”

Saatnya Menyerahkan Formulir

Pengguna telah mengisi formulir, tidak ada lagi kesalahan, dan semuanya terlihat baik. Akhirnya, saatnya mengirimkan formulir!

Aturan pertama adalah, jangan menutupi tombol kirim . Dengan serius! Saya bertanya-tanya pikiran bengkok apa yang muncul dengan ide ini, tetapi saya telah melihatnya dalam beberapa bentuk. Tombol kirim hanya akan ditampilkan setelah semua bidang wajib diisi tanpa kesalahan. Sangat mengganggu bagi pengguna untuk bertanya-tanya apakah ada yang salah atau tombol formulir belum dimuat atau situs web rusak dan sebagainya.

Jika Anda tidak ingin pengguna dapat menekan tombol kirim jika ada bidang wajib yang hilang atau ada kesalahan validasi, gunakan atribut HTML yang disabled pada input submit . Anda perlu mengaktifkan kembali tombol menggunakan JavaScript setelah formulir valid dan siap untuk dikirim.

Jika Anda memiliki ajakan bertindak utama dan sekunder, gunakan warna, ukuran, dan gaya untuk menampilkan hierarki .

Jika bertanya-tanya apakah tombol konfirmasi harus muncul sebelum atau sesudah tombol pembatalan, saya juga (dan banyak orang lainnya). Jika Anda membuat aplikasi asli, patuhi pedoman OS. Ini menjadi sangat menyenangkan karena Android mengubah posisi tombol di versi keempatnya. Di web, ini lebih rumit karena tidak ada pedoman nyata. Terlepas dari OSnya, berikut adalah beberapa panduan umum untuk tombol kirim yang dioptimalkan untuk seluler:

• Berikan ajakan untuk bertindak deskriptif, kata kerja yang dapat ditindaklanjuti.
• Berikan umpan balik visual saat pengguna mengetuknya.
• Jika Anda memiliki dua tombol, buat tindakan utama menonjol .
• Kecuali Anda sedang mengerjakan formulir perusahaan back-office yang sangat spesifik (dalam hal ini, Anda akan menghadapi banyak tantangan dalam mengoptimalkan seluler), hindari tombol reset . Pengguna mungkin bingung dengan tombol kirim dan akan kehilangan semua data mereka secara tidak sengaja.

Kesimpulan

Di bagian pertama ini, saya telah membahas banyak teknik kecil untuk membawa formulir Anda ke tingkat berikutnya dan membantu pengguna mengisinya. Beberapa pedoman umum dan praktik terbaik seluler ini mungkin tidak berfungsi 100% sepanjang waktu — itulah masalahnya dengan praktik terbaik. Jadi, selalu uji formulir Anda pada pengguna nyata dan perangkat nyata, dan sesuaikan panduan dengan kebutuhan dan pengalaman khusus pengguna Anda.

Juga, lakukan beberapa regresi dan pengujian fungsional otomatis — sekali lagi, pada perangkat nyata. Emulator seluler Chrome tidak akan cukup untuk menguji formulir yang dioptimalkan untuk sentuhan. Saya mengatakan ini karena saya telah meluncurkan situs web e-niaga dengan formulir pencarian yang tidak berfungsi di seluler. Kami hanya melakukan pengujian otomatis menggunakan emulator. Inilah yang terjadi. Formulir pencarian disembunyikan di bawah ikon pencarian. Anda dapat mengetuk tombol, yang membuka kotak dengan bidang pencarian. Ini bekerja dengan meniru kursor mouse sebagai acara sentuh. Kami menguji mengetuk tombol, dan itu membuka kotak. Tidak ada yang mencoba meluncurkan pencarian. Jadi, tidak ada seorang pun (bahkan klien) yang melihat bahwa bidang pencarian menghilang begitu pengguna mencoba berinteraksi dengannya. Apa yang terjadi? Ketika elemen input mendapat fokus, tombol kehilangan status hover, sehingga menutup kotak dengan bidang. Pengujian otomatis tidak dapat menangkap ini karena input tidak kehilangan fokus. Jadi, kami meluncurkan situs web e-niaga tanpa fungsi pencarian di ponsel. Bukan pengalaman yang luar biasa.

Di bagian kedua dari seri ini, kita akan melihat teknik khusus seluler yang lebih canggih. Kita akan melihat cara menggunakan fitur HTML5 keren untuk memformat bidang dan cara menggunakan kemampuan seluler untuk membawa pengalaman pengguna seluler ke tingkat berikutnya.