Progettare moduli di progetto con campi ed errori chiari
Un modulo progettato chiarisce dati obbligatori, etichette e messaggi di errore concreti. Le informazioni inserite restano durante la correzione.
Un lungo modulo di progetto si rivede meglio quando è chiaro il passo di lavoro successivo. Definisca prima quali dati servono davvero al team. Pianifichi poi insieme etichette, validazione e risposte.
Partire dal passo di lavoro successivo
Nel portale fittizio seguente, il team deve classificare una prima richiesta software e porre domande via e-mail. Titolo del progetto, obiettivo ed e-mail sono quindi obbligatori. Il telefono resta facoltativo. Indirizzo di fatturazione e numero cliente interno non sono richiesti per questa prima richiesta. È una scelta del percorso d’esempio.
W3C WAI raccomanda di chiedere soltanto i dati necessari al processo interessato. Ogni domanda rimasta deve avere uno scopo comprensibile.
Mantenere visibili i testi dei campi
Le etichette restano visibili durante la digitazione e sono associate tecnicamente ai campi. Un segnaposto nel campo vuoto non sostituisce l’etichetta: scompare quando si scrive. Scopo e facoltatività sono quindi indicati accanto al campo.
Campo | Prima | Previsto |
|---|---|---|
| Progetto | Titolo del progetto (obbligatorio) – Come chiama il team questa iniziativa? |
| Descrizione | Obiettivo del progetto (obbligatorio) – Quale attività deve facilitare il software? |
| Contatto | E-mail per chiarimenti (obbligatoria). |
| Telefono * | Numero di telefono (facoltativo). |
«Facoltativo» deve corrispondere alla validazione durante l’invio. Un campo telefono lasciato vuoto non deve causare errore in questo percorso.
Collegare l’errore alla situazione concreta
Per questo modulo la validazione è prevista all’invio. Dati mancanti, inserimenti incompleti e trasmissione non confermata ricevono risposte differenti.
Situazione | Messaggio previsto |
|---|---|
E-mail mancante | Inserisca un indirizzo e-mail per i chiarimenti. |
L’e-mail contiene | L’indirizzo e-mail è incompleto. Esempio: |
Trasmissione non confermata | La ricezione della richiesta non è ancora confermata. I dati inseriti restano qui. |
Il controllo del formato non conferma che la casella sia raggiungibile. Un problema di trasmissione non viene presentato come un campo e-mail compilato male.
Correggere senza perdere dati
Dopo un errore di inserimento, il progetto prevede un riepilogo che riceve il focus da tastiera e rimanda al campo interessato. Lo stesso testo comprensibile appare accanto al campo; anche le tecnologie assistive devono poterlo associare. Restano i valori già inseriti, compreso quello da correggere.
Il messaggio di successo segue soltanto la conferma di ricezione del server. Se l’esito è incerto, il percorso di reinvio deve chiarire come riconoscere una richiesta che potrebbe essere già arrivata.
Verificare un’attività completa
Faccia compilare la richiesta d’esempio senza telefono. Verifichi anche il percorso d’errore con un’e-mail incompleta: si trova il messaggio, si corregge l’indirizzo e si completa la richiesta mantenendo l’obiettivo del progetto? Includa tastiera, schermo stretto e tecnologie assistive usate. Annoti dove serve aiuto e se alla fine la ricezione è davvero confermata.
Fonti
Continuate a leggere
Tutti gli articoli
Design & UX con ASES
Esperienza utente, interfacce e immagine del marchio