UX e HTML5: aiutiamo gli utenti a compilare il modulo mobile (parte 1)

I moduli sono una delle interazioni primarie più basilari che gli utenti avranno con i tuoi siti Web (e app mobili). Collegano le persone e lasciano che comunichino. Lasciano che commentino gli articoli e spieghino all'autore come sono fortemente in disaccordo con ciò che hanno scritto. Consentono alle persone di chattare direttamente su un'app di appuntamenti per incontrare "quello". Che si tratti di forum, ordini di prodotti, comunità online, creazione di account o pagamenti online, i moduli sono una parte importante della vita online degli utenti.

Siamo nel 2018 e abbiamo più utenti mobili che desktop in tutto il mondo . Tuttavia, trattiamo ancora quegli utenti come cittadini di seconda classe del web. Tutti scrivono e parlano continuamente dell'esperienza dell'utente. Quindi, perché, perché, perché così tanti siti Web e prodotti continuano a sbagliare. Perché la loro esperienza utente mobile è danneggiata per metà del mondo? Perché è ancora una seccatura, perché è ancora super difficile prenotare un volo e registrare un account in un modulo mobile oggi? Gli utenti si aspettano di meglio!

Letture consigliate : World Wide Web, Non Wealthy Western Web

Questa è la prima parte di una serie di due articoli. In questo, riassumerò alcune best practice essenziali per migliorare i tuoi moduli mobili, tra cui scansionabilità e leggibilità. Ti guiderò attraverso il posizionamento, la dimensione e l'ottimizzazione di etichette e input. Vedremo come scegliere il giusto elemento del modulo per ridurre i costi di interazione. Infine, imparerai come prevenire e gestire gli errori sui moduli mobili.

Nella seconda parte, darò un'occhiata più da vicino alle funzionalità mobili specifiche e agli elementi dei moduli HTML5 e andremo oltre i classici elementi dei moduli per creare applicazioni Web e siti Web unici e divertenti.

Nota : sebbene la maggior parte dei miglioramenti del codice in questo articolo siano relativi al Web (perché non conosco Swift o Java), le best practice di usabilità valgono per le applicazioni mobili .

Design del modulo 101: dare priorità alla scansione e alla leggibilità

"Un modulo è il nome, il valore, le coppie, in una struttura per la memorizzazione dei dati su un computer barrato come etichette e campi di input per l'essere umano." Questa è una citazione diretta di Luke Wroblewski a una conferenza. Come lui, credo che la maggior parte dei problemi di usabilità dei moduli derivi da questa tendenza a servire la struttura del database per gli utenti.

Architettura dell'informazione forte

Per creare moduli migliori, devi prima allontanarti di qualche passo dalla struttura del tuo database. Cerca di capire come gli utenti vogliono compilare i moduli. È qui che diventa utile eseguire alcuni test di usabilità e ricerche sugli utenti sui moduli. I modelli mentali dell'utente sono un concetto di UX che può aiutarti in questo. Nielsen Norman Group lo descrive come "ciò che l'utente crede del sistema in uso". Chiedi al tuo tester di pensare ad alta voce e dirti come compilerebbe il modulo. Quali passaggi si aspettano? Cosa viene prima? Quello che viene dopo? Questo ti darà un'idea migliore di come strutturare il tuo modulo in un modo più intuitivo.

Il raggruppamento visivo dei campi che appartengono insieme aiuterà anche gli utenti a compilare un modulo. Nel codice, usa il tag fieldset per raggrupparli a livello di codice. Aiuterà anche gli screen reader a comprendere la gerarchia.

Se il modulo è lungo, non esporre tutto per impostazione predefinita . Sii intelligente riguardo a ciò che mostri. Usa saggiamente la ramificazione per visualizzare solo i campi di cui le persone hanno bisogno. In un modulo di pagamento, ad esempio, non visualizzare tutti i campi dettagliati per tutte le opzioni di spedizione. Questo travolgerà l'utente. Mostra informazioni sufficienti per aiutarli a scegliere l'opzione di spedizione giusta. Quindi, visualizza solo i dettagli e i campi relativi a quella scelta.

Gli intervalli di attenzione degli utenti si riducono con il tempo: chiedi informazioni facoltative alla fine del modulo. Ad esempio, se il tuo modulo è un sondaggio sulla soddisfazione dei clienti, chiedi informazioni demografiche alla fine. Meglio ancora, riempili automaticamente, se possibile. Chiedi agli utenti solo ciò che è necessario.

Infine, pianifica in anticipo la localizzazione: cosa accadrà quando il tuo modulo verrà tradotto? Cosa accadrà, diciamo, per il tedesco? Il tuo design funzionerà ancora?

Posizionamento dell'etichetta e ottimizzazione dell'input

Il layout a colonna singola funziona meglio

A causa della mancanza di spazio, non hai infinite opzioni per posizionare etichette e campi sugli schermi dei dispositivi mobili:

• Presenta i campi in un layout a colonna singola . Non c'è spazio sul dispositivo mobile per più colonne. I moduli a più colonne non sono comunque una buona idea su desktop.
• In modalità verticale, è meglio posizionare l' etichetta sopra il campo in modo che gli utenti possano vedere cosa c'è nel campo durante la digitazione.

• In modalità orizzontale, l'altezza dello schermo è ridotta. Potresti voler mettere le etichette a sinistra e gli input a destra . Ma provalo per assicurarti che funzioni.

Per ulteriori informazioni sul posizionamento delle etichette, vedere "Utilità dei moduli mobili: posizionare le etichette sopra il campo" del Baymard Institute.

Le etichette devono essere chiare e visibili e funzionare senza contesto

Ricorda che non appena un campo viene messo a fuoco, la tastiera si apre e occuperà almeno un terzo dell'area dello schermo. Su piccoli schermi mobili, gli utenti dovranno anche scorrere per compilare il modulo. Ciò significa che perderanno parte del contesto durante la compilazione del modulo. Pianifica di conseguenza:

• Le tue etichette devono essere un testo chiaro e visibile che può essere letto e compreso senza contesto. L'utente dovrebbe essere in grado di completare ogni coppia di etichette e campi come un'attività separata, anche se perde il contesto.

• Evita il gergo, le abbreviazioni e il linguaggio specifico del settore ogni volta che puoi.
• Sii coerente. Se usi "cliente" in un'etichetta una volta, mantieni quella parola. Evita di utilizzare "client" in un secondo momento perché potrebbe confondere gli utenti.
• La dimensione del carattere dovrebbe essere abbastanza grande. Testa il tuo modulo su dispositivi reali il prima possibile e regola le dimensioni di conseguenza.
• Il testo tutto maiuscolo può essere difficile da leggere per alcuni utenti. Potresti voler evitare di usare il testo tutto maiuscolo sulle etichette.
• La copia dell'etichetta deve essere breve e scansionabile. Se un campo necessita di chiarimenti, non inserirlo in etichetta. Utilizzare invece una descrizione del campo.

Best practice per le dimensioni di input

Se possibile, la dimensione dell'elemento di input deve corrispondere alla dimensione del contenuto previsto . Questo aiuterà gli utenti a compilare rapidamente il modulo e capire cosa ci si aspetta.

Utilizzo di maschere per evitare di dividere gli input su dispositivi mobili

Non dividere gli input solo per motivi di formattazione . È particolarmente fastidioso sui dispositivi mobili, dove gli utenti non possono utilizzare la tastiera per navigare tra i campi. Richiede tocchi extra solo per passare al campo successivo per compilare il modulo. Potresti pensare: "Ma focalizzerò automaticamente l'attenzione sul campo successivo quando avrò il numero richiesto di caratteri in quel campo". Potrebbe funzionare. Ma avrai preso il controllo dell'interfaccia utente, che diventa imprevedibile per l'utente. Inoltre, sarebbe una seccatura se li mandassi automaticamente al campo successivo e dovessero correggere qualcosa nell'ultimo campo. Infine, è più complicato indovinare cosa è obbligatorio con gli input divisi. Quindi, smettiamo di giocare al gioco "Ma cosa succede se" e semplicemente non dividiamo gli input.

Ho capito: vuoi comunque essere in grado di formattare i dati dei tuoi utenti in piccoli pezzi per aiutarli a compilare i tuoi campi. E su questo hai perfettamente ragione. Per farlo, potresti usare le maschere . Invece di dividere un input, metti una maschera sopra di esso, per aiutare visivamente l'utente a riempirlo. Ecco un esempio video di come sarebbe una maschera per aiutare gli utenti a compilare un campo di carta di credito:

Le maschere aiutano a prevenire gli errori guidando gli utenti al formato corretto. Evita di rivelarli gradualmente: mostra direttamente il formato. Inoltre, evita di inserire valori falsi nella maschera . Gli utenti potrebbero pensare che sia già pieno. Ecco perché ho sostituito i numeri con una piccola "X" nella mia demo. Trova ciò che funziona meglio per il tuo tipo di input.

Infine, ricorda che alcuni dati possono variare tra i paesi e talvolta cambia anche il formato (numeri di telefono, ad esempio). Pianifica di conseguenza.

Descrizioni dei campi efficienti

La visualizzazione di descrizioni dei campi efficienti può fare la differenza tra un'esperienza di modulo senza interruzioni e una dolorosa.

A cosa servono le descrizioni?

Le descrizioni possono aiutare gli utenti in tanti modi. Ecco alcuni esempi.

• Cosa stai chiedendo esattamente?
  

  Per qualsiasi motivo relativo al database, alcune società di spedizioni richiedono i campi "Indirizzo 1" e "Indirizzo 2". Questo è molto confuso per gli utenti, ma potresti non avere scelta qui. Aggiungi campi di descrizione per aiutare gli utenti a capire cosa devono inserire in ogni campo.

  

  Lo stesso vale per acronimi e abbreviazioni. So di aver detto che dovresti evitarli, ma a volte non puoi. Ad esempio, se lavori su moduli complessi per un determinato settore, potrebbero avere il proprio set di abbreviazioni. Qualsiasi nuovo utente che deve compilare il modulo potrebbe non avere (ancora) familiarità con tali abbreviazioni. Avere una descrizione disponibile da qualche parte li aiuterà.

• Perché hai bisogno di questa informazione?
  Gli utenti potrebbero essere riluttanti a fornirti informazioni personali se non capiscono perché ne hai bisogno e cosa ne farai . Ma a volte è comunque necessario chiedere tali informazioni per motivi legali (come la data di nascita per un sito Web che vende alcolici). L'utilizzo delle descrizioni dei campi qui aiuterà gli utenti a capire perché questo tipo di informazioni è necessario.
  
  

  Sui siti di e-commerce, potresti voler chiedere il numero di telefono dell'utente nel caso in cui il corriere debba contattarlo. Questo è un motivo legittimo. Quindi, ancora una volta, usa le descrizioni per spiegare agli utenti di e-commerce perché hai bisogno del loro numero di telefono.

  

"Dove trovo le informazioni?"
Se i tuoi utenti hanno bisogno di trovare determinate informazioni da qualche altra parte per compilare un modulo, indica loro dove trovarlo. Ho lavorato su un'app mobile che consente all'utente di monitorare la propria casa. Gli utenti dovevano associare l'app al dispositivo di monitoraggio utilizzando un numero di serie. Non è molto facile trovare questo numero di serie sul dispositivo; richiede alcune istruzioni. Abbiamo aggiunto un po' ? pulsante accanto al campo del numero di serie. Il pulsante apre una modale che mostra un'immagine e alcune indicazioni per aiutare l'utente a capire dove trovare il numero di serie sul dispositivo di monitoraggio. I siti di e-commerce fanno lo stesso con i codici promozionali: forniscono indicatori che indicano agli utenti dove trovare i codici.



• "Come devo formattare le informazioni?"
  Alcuni campi richiedono un formato particolare . In questo caso, usa le descrizioni per far conoscere agli utenti le regole di formattazione in anticipo. Ecco alcuni esempi:
  • Numero di telefono: devo inserire il prefisso internazionale (+xx) davanti al campo?
  • C'è una lunghezza massima? Twitter sul cellulare fa un buon lavoro con quello.
  • Quando si tratta di importi monetari, il formato è con una virgola (come 10.000) o uno spazio (come 10.000)?
  • Che formato ti aspetti per le date? Ti farò controllare su Wikipedia che incubo è. La differenza tra GG MM AA e MM GG AA può causare *molti* problemi agli utenti al momento della prenotazione online.
  Nota che molti di questi problemi di formattazione possono essere risolti dalle maschere di input. Ci arriveremo più avanti nell'articolo (o puoi saltare direttamente se sei impaziente).

  

Come visualizzare le descrizioni

Negli esempi sopra, abbiamo visto alcuni modi per visualizzare le descrizioni dei campi. Ecco un riassunto di cosa fare:

• Le descrizioni in linea dovrebbero essere direttamente visibili e visualizzate accanto al campo.
• Se hai bisogno di descrizioni più approfondite con contenuti pesanti, puoi utilizzare descrizioni comandi o modali . Le descrizioni comandi vengono generalmente attivate al passaggio del mouse sul desktop e al tocco sui dispositivi mobili. Lo stesso vale per le modali: aprilo quando l'utente tocca l'icona della guida o il collegamento "vedi altro", ad esempio.

Fai attenzione con i segnaposto

Ho capito: si è tentati di rimuovere i campi sui dispositivi mobili per guadagnare spazio e utilizzare invece i segnaposto. Abbiamo tutti percorso quella strada. Ma per favore non farlo. La specifica HML5 è chiara al riguardo: "L'attributo segnaposto rappresenta un breve suggerimento (una parola o una breve frase) inteso ad aiutare l'utente con l'immissione di dati". Ed ecco perché:

• Il segnaposto scompare quando l'utente inizia a digitare. L'utente deve quindi fare affidamento sulla memoria a breve termine per ricordare cosa dovrebbe mettere in campo . Se non possono, dovranno svuotare il campo per vedere l'indicazione.
• È difficile per gli utenti ricontrollare i campi prima dell'invio perché i campi non hanno più indicazioni sull'etichetta.
• È difficile recuperare dagli errori una volta che un campo è stato inviato perché, ancora una volta, non esiste un'etichetta per aiutare l'utente.

Anche se utilizzi i segnaposto con le etichette, potresti comunque avere dei problemi. È difficile distinguere tra un campo riempito e un campo con un segnaposto . Sono un designer UX che scrive di design di moduli mobili e anche io sono stato ingannato la scorsa settimana da uno di quelli. Se succede a me, accadrà ai tuoi utenti: fidati di me su quello. Infine, la maggior parte dei segnaposto ha testo in grigio chiaro, quindi potresti avere anche alcuni problemi di contrasto.

Se vuoi approfondire questo argomento, c'è un ottimo articolo intitolato "L'attributo del segnaposto non è un'etichetta, e anche Joshua Winn e FeedbackGuru spiegano in dettaglio perché questa è una cattiva idea. Nielsen Norman Group ha anche scritto un pezzo sull'argomento, intitolato "I segnaposto nei campi di forma sono dannosi".

I segnaposto non sono obbligatori in HTML5 . Dal punto di vista dell'usabilità, sicuramente non hai bisogno di un segnaposto in ogni campo del tuo modulo. Ma con la massiccia adozione di Bootstrap e di altri framework, sembra che molte persone copi e incolli i componenti. Questi componenti hanno dei segnaposto, quindi immagino che le persone si sentano in qualche modo obbligate ad aggiungere qualcosa al segnaposto nel codice? Se i segnaposto del tuo modulo sembrano "Compila la tua - etichetta - qui", stai sbagliando.

Le etichette all'interno dei campi potrebbero, tuttavia, funzionare bene per moduli brevi in ​​cui i campi sono prevedibili . I moduli di accesso sono un buon candidato per questo. Ma per favore non usare il segnaposto HTML5 per codificare questo. Usa una vera etichetta nel codice e spostala con CSS e JavaScript.

Dal successo del design dei materiali di Android, un modello ha iniziato a emergere: l'etichetta fluttuante. Questa etichetta si trova all'interno del campo quando il campo non è compilato, quindi occupa un po' meno spazio verticale sul dispositivo mobile. Quando gli utenti iniziano a interagire con il campo, l'etichetta si sposta sopra il campo.

Questo sembra un modo interessante per guadagnare spazio, senza imbattersi nei problemi "segnaposto al posto delle etichette" citati sopra. Tuttavia, non risolve il problema degli utenti che potrebbero scambiare un segnaposto per contenuto compilato.

Riduzione dei costi di interazione per moduli di successo

La riduzione del costo di interazione (ad esempio il numero di tocchi, scorrimenti, ecc.) degli utenti che eseguono il proprio compito ti aiuterà a creare un'esperienza di modulo senza interruzioni. Ci sono diverse tecniche per ottenerlo. Diamo un'occhiata ad alcuni di loro in dettaglio.

Uno studio magico su Internet mi ha detto di ridurre il numero di campi

Più campi significano meno conversioni, giusto? Potresti aver riscontrato lo studio "abbiamo ridotto il nostro modulo di iscrizione da 11 a 4 campi e ha aumentato le conversioni del 160%". È un classico. E se guardi il loro modulo di contatto, ha senso. Perché gli utenti dovrebbero voler compilare 11 campi solo per contattare l'azienda? Non puoi chiedere un impegno così grande a persone che ti conoscono a malapena, giusto?

Inizia chiedendo solo informazioni utili. Perché hai bisogno del sesso di una persona per creare un account per loro? Perché hai due righe per l'indirizzo se il tuo modulo di iscrizione è per un servizio online?

Chiedi solo le informazioni di cui hai bisogno. E poi chiedere le informazioni nel contesto. Se hai un sito di e-commerce, gli utenti potrebbero essere più propensi a fornirti il ​​loro indirizzo nella sezione di spedizione del processo di checkout rispetto a quando si registrano. Renderà il tuo modulo di registrazione e-commerce molto più facile da compilare sul cellulare!

Inoltre, non fidarti ciecamente di ogni statistica e studio che trovi su Internet. Ricordi lo studio da 11 campi a 4? Ebbene un altro studio più recente ha mostrato che riducendo i campi da 9 a 6, le conversioni sono diminuite del 14%. Scioccante, non è vero? Come mai? Bene, hanno rimosso i campi più coinvolgenti. Per farla breve, sono poi tornati a 9 campi, hanno messo in cima i più importanti e voilà, le conversioni sono aumentate del 19,21%.

La linea di fondo è che mentre questi studi sono interessanti, quei siti web non sono il tuo sito web. Non fidarti ciecamente del primo studio che trovi su Internet.

Che cosa si può fare? Test. Test. E prova!

• Esegui alcuni test utente per vedere il tempo necessario per il completamento del modulo mobile.
• Misura gli abbandoni.
• Misura i problemi con determinati campi.
• Misura la frustrazione associata a determinati campi. Quanto sono disposti gli utenti a fornire tali informazioni? Quanto sono personali queste informazioni?

Ottimizzazione delle interazioni tattili

Rendere i controlli facili al tocco

Se i tuoi campi sono troppo piccoli o difficili da raggiungere, gli utenti commetteranno errori e avranno bisogno di interazioni extra per raggiungere i loro obiettivi. Ricordi la legge di Fitt? Puoi applicarlo anche al design mobile: rendi le etichette, i campi e i controlli dei moduli facili da toccare aumentando le dimensioni del target touch . Per le etichette sul web, un po' più di riempimento può aumentare l'area toccabile. A volte dovrai anche aggiungere dei margini tra gli elementi per evitare tocchi persi.

Inoltre, non dimenticare di collegare le etichette ai loro componenti accoppiando for valori e ID. In questo modo, se l'utente manca un tocco sull'etichetta, il campo corrispondente verrà comunque messo a fuoco.

Steven Hoober ha condotto alcune ricerche sugli utenti sulle aree tattili. Troverai un riepilogo in "Designing for Touch". Sulla base di ciò che ha scoperto, ha costruito un piccolo strumento di righello di plastica: il modello touch mobile. Lo strumento potrebbe aiutarti ad assicurarti che le tue aree touch siano sufficientemente grandi per i moduli mobili e, più in generale, per il design mobile.

Per saperne di più sulla progettazione per il tocco puoi leggere quanto segue:

• "Design a misura di dito: dimensioni target touchscreen mobili ideali"
• "The Thumb Zone: progettazione per utenti mobili"

Fornire feedback

Gli utenti mobili non hanno un mouse (non scherzo), quindi non ottengono il feedback "clic" che gli utenti desktop ottengono quando premono un pulsante. Gli utenti di moduli mobili necessitano di un feedback chiaro quando interagiscono con gli elementi:

• Fornire uno stato di attivazione per il campo del modulo con cui l'utente sta interagendo.
• Fornire feedback visivo quando l'utente interagisce con un pulsante .

Non sono un grande fan dell'effetto ondulato del design dei materiali sui pulsanti. Ma devo ammettere che le animazioni su Android forniscono un feedback chiaro quando l'utente interagisce con un pulsante.

Onora l'ordine del pulsante successivo e precedente

Infine, onora i pulsanti successivo e precedente sulle tastiere mobili. Gli utenti possono usarli per navigare rapidamente nei campi. L'ordine del tabindex deve corrispondere all'ordine visivo dei campi e dei componenti.

Evita i menu a discesa sui dispositivi mobili, se possibile

I menu a discesa (l'elemento di selezione HTML) sul Web richiedono molte schede e interazioni. Pertanto, come ha detto Luke Wroblewski, dovrebbero essere l'interfaccia utente di ultima istanza. Molti altri componenti dell'interfaccia utente funzionano meglio dei menu a discesa in molte situazioni.

I controlli dei segmenti e i pulsanti di opzione sono buone alternative ai menu a discesa se hai tra due e quattro opzioni. Perché nascondere le opzioni in un menu a discesa quando puoi mostrarle tutte direttamente su un'unica schermata? Si noti che, come i pulsanti di opzione, i controlli di segmento si escludono a vicenda.

Un elenco di paesi è un buon candidato per un componente. Un elenco a discesa di oltre cento paesi è un incubo di interazione sui dispositivi mobili. Va bene se stai cercando l'Afghanistan (all'inizio dell'elenco) o lo Zimbabwe (alla fine dell'elenco). Se stai cercando il Lussemburgo, ti ritroverai in un gioco di scorrimento per raggiungere il centro della lista, spingendo troppo oltre la lettera M, cercando di tornare alla L e così via.

I lunghi menu a discesa possono essere sostituiti da campi di input di testo predittivi . Quando l'utente inizia a digitare L, l'interfaccia propone nove paesi. Se aggiungono una U — voilà! — Lo è il Lussemburgo. Quattro interazioni invece di due, contro un massimo di sei o sette interazioni a scorrimento con il menu a discesa.

Se hai bisogno che gli utenti scelgano una data, dimentica di dividerla in un menu a discesa giorno, mese e anno come le persone sono abituate a fare sui moduli cartacei. Sostituisci più menu a discesa di date con un selettore di date . L'input HTML5 type=date funziona nella maggior parte dei casi. Ma potresti avere delle esigenze speciali e finire per creare il tuo selettore di date in JavaScript, specialmente se sei nel settore della prenotazione (hotel, auto, voli).

Nel suo articolo "Mobile DropDowns Revisited", Klaus Schaefers spiega come l'utilizzo di un selettore di date per le date di arrivo e partenza ha reso le interazioni del 60% più veloci.

Continuiamo con l'attività di prenotazione. Supponiamo che l'utente debba aggiungere più viaggiatori al proprio itinerario. Puoi **sostituire il menu a discesa * con uno * stepper** per selezionare il numero di passeggeri. Uno stepper è un controllo che consente all'utente di aumentare e diminuire i valori semplicemente toccando i pulsanti + e - . Questo tende ad essere più veloce quando devono essere aggiunte meno di sei persone. È anche più intuitivo. Di seguito è riportato un esempio di uno stepper utilizzato nell'app Airbnb nativa per Android per selezionare gli ospiti e sul sito Web ottimizzato per dispositivi mobili di Kayak per aggiungere passeggeri.

Un'ultima alternativa ai menu a discesa è la visualizzazione elenco. Le opzioni sarebbero elencate in una sottoview specifica, ad esempio come pulsanti di opzione. Questo è principalmente il modo in cui funzionano le impostazioni di Android.

Diventare intelligenti con il completamento automatico

Se vuoi ridurre il costo di interazione del tuo modulo, sii intelligente. Non chiedere informazioni che puoi rilevare automaticamente o indovinare sulla base di altre informazioni che gli utenti ti hanno fornito. Completa automaticamente e precompila il più possibile.

Luoghi e indirizzi

Se l'utente cerca un luogo o deve inserire un indirizzo, puoi offrire il completamento automatico per aiutarlo. Durante la digitazione, un'API inserirà il resto dell'indirizzo per loro. Questo riduce anche gli errori.

Potresti usare:

• API di Google Places
• Algolia Places, che si basa su OpenStreetMap

In Francia e in molti altri paesi, puoi indovinare la città in base al prefisso. Quindi, se un utente francese inserisce un prefisso, puoi completare automaticamente o almeno proporre la città. Il mio paese, il Lussemburgo, è piccolo (non prendermi in giro). Il mio prefisso è collegato alla mia via. Quindi, se inserisco il mio prefisso, il modulo dovrebbe anche essere in grado di suggerire la mia via.

Carte di credito

Un'altra area in cui il rilevamento automatico è facile sono le carte di credito. Non è necessario chiedere all'utente che tipo di carta di credito ha. Puoi rilevarlo automaticamente in base ai numeri iniziali che inseriscono. C'è anche una libreria che può fare il lavoro per te.

Utilizzo del completamento automatico HTML5 (riempimento automatico)

L'attributo di completamento automatico HTML può precompilare i campi in base agli input precedenti dell'utente. Questo attributo ha uno stato di attivazione e disattivazione. Alcune persone intelligenti hanno iniziato a lavorare su una specifica per renderlo più potente ed estendere l'attributo di completamento automatico per i campi del modulo. Il WHATWG ha anche un elenco interessante.

Chrome e altri browser mobili supportano già alcuni dei valori estesi per carte di credito e nomi. Ciò significa che gli utenti possono precompilare i moduli con il proprio nome e i dati della carta di credito che utilizzano su altri siti web.

In breve, quando devi scegliere tra diversi sistemi, conta il numero di interazioni che ciascuno richiederà.

Si verificano errori: gestione degli errori nei moduli mobili

L'ultimo passo del nostro viaggio verso moduli mobili migliori è la gestione di errori ed errori. Possiamo provare a ridurre gli errori per alleggerire il carico cognitivo dell'utente. Possiamo anche aiutarli a riprendersi dagli errori, perché non importa quanto sia grande il design del tuo modulo, gli errori accadono.

Come evitare errori durante la compilazione dei moduli

"Prevenire è meglio che curare", diceva mia madre. Questo vale anche per la progettazione dei moduli: la prevenzione degli errori migliorerà l'esperienza del modulo mobile.

Limitazione esplicita del formato

“Sii prudente in quello che fai. Sii liberale in ciò che accetti dagli altri”. Questo principio di robustezza può essere applicato anche ai campi dei moduli. Se possibile, lascia che l'utente inserisca i dati in qualsiasi formato.

Se pensi di dover limitare ciò che un utente può inserire nel campo, inizia chiedendoti “perché”. Nel campo dell'esperienza utente, abbiamo una tecnica chiamata "i tre perché". Se la risposta è "perché bla bla database", forse è il momento di cambiare le cose. Ad esempio, perché rifiuti caratteri speciali come e, a e o nel campo del nome utente? Ho scritto un articolo spiegando quanto siano maleducati i moduli per me quando provo a inserire "Stephanie" come nome utente. Sto ancora cercando di capire una buona ragione per questo (a parte i motivi del database).

Se hai una buona ragione per richiedere un formato specifico agli utenti, indicalo in anticipo . Puoi utilizzare i segnaposto HTML5 per dare agli utenti un suggerimento su come dovrebbero apparire i dati, ma ancora una volta, fai attenzione con quelli. Puoi anche utilizzare tutte le tecniche di descrizione dei campi spiegate all'inizio di questo articolo. Infine, le maschere di input possono guidare gli utenti verso il formato giusto.

Contrassegno dei campi obbligatori (e facoltativi)

Non aspettare che gli utenti inviino un modulo compilato a metà per informarli dei campi obbligatori. Se un campo è obbligatorio, gli utenti dovrebbero conoscerlo . Contrassegnare i campi obbligatori con un asterisco ( * ) e una legenda è diventato un modello standard per i moduli. Il bello è che non occupa molto spazio. Il problema è che non ha valore semantico, quindi può causare problemi di accessibilità se codificato male e se fai affidamento sulle abitudini delle persone con l'interazione dei moduli.

Potresti invece contrassegnare esplicitamente sia i campi obbligatori che quelli facoltativi con le parole “obbligatorio” (o “obbligatorio”) e “facoltativo”. Sia il Baymard Institute che Luke Wroblewski sono d'accordo su questo. Ciò evita l'ambiguità con i moduli lunghi sui dispositivi mobili, ad esempio quando si utilizza uno scroller, si procede con qualcos'altro, quindi si torna indietro e non si ricorda se i campi obbligatori sono stati contrassegnati con un asterisco o qualcos'altro.

Alla fine, la decisione su come contrassegnare quei campi dipenderà dal design e dalla lunghezza del campo e dal contesto. Il modo migliore per sapere se hai preso la decisione giusta è, ancora una volta, testare il modulo.

Default sensati

Prestare attenzione alle opzioni predefinite selezionate nei moduli . Quando ho fatto domanda per il mio precedente lavoro, c'era un modulo informativo. Lo stato civile era facoltativo. Hanno reso il primo elemento del menu a tendina, "divorziato", il campo predefinito. Quindi, non potevo rispondere (perché era un campo facoltativo) e lasciare che il sistema credesse che fossi divorziato, oppure correggerlo e rivelare il mio stato civile effettivo anche se non volevo.

Inoltre, fai attenzione al genere. Ancora una volta, hai un'opzione per le persone che non vogliono rivelarlo; chiarisci perché stai chiedendo il loro sesso; meglio ancora, chiedi i pronomi o non chiedere se non ne hai davvero bisogno. 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.

• Quando si accede
  In un modulo di accesso, un'opzione maschera/smaschera password migliorerebbe enormemente l'esperienza dell'utente.
  Amazon ha una storia interessante di iterazioni sulle password nel suo modulo di accesso. Aveva una versione in cui non si poteva vedere la password. L'iterazione successiva ha permesso agli utenti di rivelarlo. Quindi, la password è stata rivelata per impostazione predefinita e puoi nasconderla. Ecco come si presentava nel 2015:

  

  Amazon ha testato l'ultima versione e il 60% delle persone si è insospettito. Quindi, hanno sostituito la casella di controllo deselezionata "nascondi password" con una casella di controllo "mostra password". Questo mostrerebbe la password in caratteri più piccoli, sotto il campo, mentre l'utente ha digitato. Ecco come appare al momento della stesura di questo articolo:

  

  Come puoi vedere, c'è sempre spazio per migliorare.

Convalida in linea

Se hai familiarità con i principi di usabilità, potresti conoscere la legge di prossimità della Gestalt. Su dispositivo mobile, evita il riepilogo degli errori nella parte superiore della pagina, senza informazioni contestuali, dopo che l'utente ha toccato il pulsante di invio.

Invece, i messaggi di errore dovrebbero trovarsi vicino agli errori stessi .

Convalida in tempo reale

Inoltre, non è necessario attendere che gli utenti premono il pulsante di invio. Puoi convalidare i campi e visualizzare il feedback mentre l'utente li sta compilando .

Alcuni suggerimenti:

• Come accennato in precedenza, i campi della password trarrebbero vantaggio dalla convalida in tempo reale e dal feedback su ogni battitura.
• Potresti anche voler convalidare i nomi utente in tempo reale durante la creazione degli account, per assicurarti che siano disponibili. Twitter fa un buon lavoro in questo senso.
• Non convalidare ogni sequenza di tasti. Attendi che l'utente abbia finito di digitare. (Utilizza la blur JavaScript per i moduli Web o attendi qualche secondo per rilevare l'inattività.)

Nota : *Mihael Konjevic ha scritto un bell'articolo su "Inline Validation in Forms: Designing the Experience". Spiega il concetto di " ricompensa in anticipo, punisci in ritardo ".*

"Se l'utente sta inserendo i dati nel campo che era in uno stato valido , eseguire la convalida dopo l'immissione dei dati."

"Se l'utente sta inserendo i dati nel campo che era in uno stato non valido , eseguire la convalida durante l'immissione dei dati."

Il colore conta

Non sto dicendo che il colore sia importante solo a causa del mio attuale colore di capelli zenzero, rosa e viola. Il colore conta davvero nella progettazione della forma.

Ci sono alcune convenzioni sul web che non vuoi infrangere. Gli utenti non daltonici sanno che il rosso è per gli errori, il giallo è per gli avvisi e il verde è quasi sempre per la conferma o il successo. È meglio attenersi a questi tre colori. Il rosso può rendere le persone ansiose, però. L'utente potrebbe pensare di aver commesso un errore davvero grave. L'uso dell'arancione o del giallo per i messaggi di errore potrebbe causare meno panico. Il problema con il giallo e l'arancione è che è difficile trovarne tonalità compatibili con i daltonici.

A proposito di daltonismo: il colore non dovrebbe essere l'unico modo per trasmettere un messaggio di errore . Questo è un criterio di accessibilità.

Nell'esempio in basso a sinistra, il campo con un errore è di colore arancione e il campo che è stato corretto è diventato verde. Ho usato uno strumento di test daltonici per acquisire lo screenshot nel mezzo: non puoi più distinguere tra il bordo grigio predefinito e quello verde. L'aggiunta di alcune icone nell'ultimo screenshot assicura che i messaggi di errore vengano trasmessi alle persone daltoniche.

Recupero dagli errori: scrittura di messaggi di errore intuitivi

A questo punto, abbiamo fatto tutto il possibile per aiutare gli utenti a compilare i nostri moduli ed evitare errori. Ma a volte, nonostante i nostri migliori sforzi, accadono degli errori. È tempo di capire come aiutare gli utenti a riprendersi da quegli errori.

Innanzitutto, ricorda: non dirottare il controllo del sistema. Se un problema non è critico, l'utente dovrebbe essere in grado di continuare a interagire con la maggior parte possibile del resto dell'interfaccia. Evita quei messaggi di errore di avviso JavaScript e le modali che bloccano gli utenti quando possibile. Inoltre, se il tuo modulo necessita di un'autorizzazione, richiedilo nel flusso di utilizzo. Se l'autorizzazione non viene concessa, non considerare questo un errore perché non lo è. Fai attenzione alla copia che usi qui.

Non sei un robot e nemmeno i tuoi utenti

I robot sono fantastici, lo so. Ma tu non sei un robot, e nemmeno i tuoi utenti lo sono. Eppure così tanti messaggi di errore sono ancora scritti così male. Ecco alcuni suggerimenti quando si tratta di messaggi di errore a misura d'uomo:

• Non mostrare mai un messaggio di errore grezzo, come "Si è verificato un errore di tipo 2393. Il server non ha potuto completare l'operazione." Invece, spiega cosa è successo nel linguaggio umano e perché è successo .
• Non mostrare mai un messaggio di errore senza uscita, come "Si è verificato un errore". Invece suggerire modi per recuperare dall'errore . Scrivi una copia utilizzabile.
• Non mostrare mai un messaggio di errore vago, come "Impossibile trovare un server con il nome host specificato", con un pulsante "Riprova". Invece, rendi i messaggi di errore informativi e coerenti . Per favore, non suonare come un robot.
• Non dare per scontato che le persone conoscano il contesto di un messaggio. I tuoi utenti non sono fanatici della tecnologia. Invece, spiega loro in un linguaggio semplice, senza gergo tecnico, come recuperare da questo errore .

Fai attenzione alla lingua che usi nei messaggi

Qualunque cosa tu scriva, evita di far sentire le persone stupide per un errore. Se possibile, tralascia le parole negative ; tendono a spaventare le persone e renderle ancora più ansiose. Usa invece un tono cortese, positivo e affermativo.

Non incolpare gli utenti per gli errori ; incolpare invece il sistema. Il sistema non porterà rancore, lo prometto. Spostare l'attenzione dell'utente su come il sistema non è stato in grado di elaborare l'azione e spiegare loro come trovare una soluzione .

Un piccolo trucco è leggere il tuo messaggio ad alta voce. Ti aiuterà a capire se funziona o è troppo duro o troppo casuale, ecc.

Potresti anche essere creativo con messaggi di errore e incorporare immagini e umorismo per renderli meno minacciosi. Tuttavia, questo dipenderà davvero dall'identità e dal tono del tuo marchio.

Per aiutarti a scrivere un messaggio di errore migliore, ti suggerisco di leggere quanto segue:

• "Un elenco di controllo per la microcopia in 6 punti per i team di prodotto senza scrittori UX"
• "L'arte del messaggio di errore: scrivere una copia chiara e utile per quando le cose vanno male"

È ora di inviare il modulo

L'utente ha compilato il modulo, non ci sono più errori e tutto sembra a posto. Finalmente è il momento di inviare il modulo!

La prima regola è non mascherare il pulsante di invio . Sul serio! Mi chiedo quale mente contorta abbia avuto questa idea, ma l'ho vista in alcune forme. Il pulsante di invio verrebbe visualizzato solo dopo aver compilato tutti i campi obbligatori senza errori. È inquietante per l'utente chiedersi se qualcosa non va o se il pulsante del modulo non è stato caricato o se il sito Web è danneggiato e così via.

Se non desideri che gli utenti possano premere il pulsante di invio se mancano campi obbligatori o se sono presenti errori di convalida, utilizza l'attributo HTML disabled nell'input di submit . Dovrai riattivare il pulsante utilizzando JavaScript una volta che il modulo è valido e pronto per l'invio.

Se disponi di un invito all'azione principale e secondario, utilizza il colore, le dimensioni e lo stile per mostrare la gerarchia .

Se ti stai chiedendo se il pulsante di conferma dovrebbe venire prima o dopo il pulsante di annullamento, lo sono anch'io (e molte altre persone). Se stai creando un'app nativa, attieniti alle linee guida del sistema operativo. È diventato particolarmente divertente da quando Android ha cambiato le posizioni dei pulsanti nella sua quarta versione. Sul web è più complicato perché non ci sono delle vere linee guida. Indipendentemente dal sistema operativo, ecco alcune linee guida generali per i pulsanti di invio ottimizzati per dispositivi mobili:

• Dai all'invito all'azione verbi descrittivi e attuabili.
• Fornisci un feedback visivo quando l'utente lo tocca.
• Se hai due pulsanti, fai risaltare l'azione principale .
• A meno che tu non stia lavorando su un modulo aziendale di back-office molto specifico (in tal caso, dovrai affrontare molte sfide per l'ottimizzazione per dispositivi mobili), evita un pulsante di ripristino . Gli utenti potrebbero confonderlo con il pulsante di invio e perderanno tutti i loro dati per sbaglio.

Conclusione

In questa prima parte, ho discusso molte piccole tecniche per portare il modulo al livello successivo e aiutare gli utenti a compilarlo. Alcune di queste linee guida generali e best practice per dispositivi mobili potrebbero non funzionare il 100% delle volte: ecco il trucco con le migliori pratiche. Quindi, testa sempre i tuoi moduli su utenti reali e dispositivi reali e adatta le linee guida alle esigenze e all'esperienza specifiche dei tuoi utenti.

Inoltre, esegui un po' di regressione e test funzionali automatizzati, ancora una volta, su dispositivi reali. L'emulatore mobile di Chrome non sarà sufficiente per testare i moduli ottimizzati per il tocco. Lo dico perché avevo lanciato un sito di e-commerce con un modulo di ricerca che non funzionava su mobile. Abbiamo eseguito solo test automatizzati utilizzando un emulatore. Ecco cosa è successo. Il modulo di ricerca era nascosto sotto un'icona di ricerca. Puoi toccare il pulsante, che ha aperto una casella con il campo di ricerca. Ha funzionato emulando un passaggio del mouse come evento touch. Abbiamo provato a toccare il pulsante e ha aperto la scatola. Nessuno ha provato ad avviare una ricerca. Quindi, nessuno (nemmeno il cliente) ha visto che il campo di ricerca è scomparso non appena gli utenti hanno provato a interagire con esso. Quello che è successo? Quando l'elemento di input ha ottenuto lo stato attivo, il pulsante ha perso lo stato al passaggio del mouse, quindi ha chiuso la casella con il campo. I test automatici non sono stati in grado di rilevare questo perché l'input non stava perdendo la concentrazione. Quindi, abbiamo lanciato un sito di e-commerce senza funzionalità di ricerca sui dispositivi mobili. Non una super esperienza.

Nella seconda parte di questa serie, vedremo tecniche specifiche per dispositivi mobili più avanzate. Vedremo come utilizzare le fantastiche funzionalità HTML5 per formattare i campi e come utilizzare le funzionalità mobili per portare l'esperienza dell'utente mobile al livello successivo.