Contenuto
- 1. Non contrassegnare i campi obbligatori
- 2. Non utilizzare spinner
- 3. Avere un solo tipo di pulsante o, meglio ancora, un solo pulsante per modulo
- 4. Campi di blocchi
- 5. Pensa perché stai chiedendo qualcosa e come ci si sente per l'utente
- 6. I datteri sono ragazzini che si dimenano
- 7. Moduli come sviluppatore artigianale
- 8. Non utilizzare colonne nei moduli
- 9. Non utilizzare due campi quando uno andrà bene
- 10. Sii gentile
Forme, non c'è niente che molti designer odiano più delle forme. Non portano necessariamente alla luce la creatività, o lo fanno? Forse è ora che guardiamo di nuovo i moduli e capiamo che un modulo, nella sua forma più elementare, è una conversazione tra l'utente e il software.
Dimentica punta e clicca, i moduli rappresentano l'interazione più ricca che noi designer digitali affronteremo. La prossima volta che arriva un modulo, non pensare che sia solo questione di applicare alcuni bei effetti CSS o aggiungere un bel tocco jQuery. C'è molta più profondità nella progettazione dei moduli.
Ho testato centinaia di moduli e progettato alcuni moduli complessi per compagnie assicurative, interazioni per la prenotazione di vacanze e molti altri. È probabile che tu abbia utilizzato uno dei miei moduli negli ultimi mesi.
Ecco le lezioni che avrei voluto imparare prima di iniziare a progettare i moduli.
1. Non contrassegnare i campi obbligatori
Hai presente il piccolo asterisco che denota un campo obbligatorio? L'ho visto fallire molte volte nei test degli utenti. In linea di principio, i campi obbligatori non hanno molto senso, non hanno equivalenti offline. Sono ottimi per gli sviluppatori perché offrono un piacevole approccio in bianco e nero al completamento. L'asterisco e il campo obbligatorio falliscono perché si tratta di un comportamento appreso. Il comportamento tipico che ho visto durante i test degli utenti è che l'utente completa il modulo in alto e lo termina quando c'è qualcosa che lo ferma o preme un pulsante.
La soluzione è semplice, contrassegnare i campi opzionali, contrassegnare il punto in cui il nostro simpatico utente deve fermarsi e pensare se ha bisogno di completare quel campo.
2. Non utilizzare spinner
HTML5 è geniale, vero? Offre un sacco di nuovi eccitanti strumenti brillanti con cui giocare. Dobbiamo pensare all'adeguatezza dei nostri nuovi giocattoli. Il campo del numero ora include piccole frecce su e giù per consentire all'utente di scorrere i numeri.
Ci sono due problemi qui. In primo luogo, la visualizzazione predefinita delle frecce nel browser le rende molto piccole. È molto complicato fare clic e le dita grasse tra di noi faranno fatica su un iPhone. Si chiama Legge di Fitt, più un oggetto è piccolo più è difficile cliccarci sopra.
Ma ti sento gridare, puoi semplicemente digitare il numero direttamente nel campo del numero. Sì, puoi, ma diamo un'occhiata alla visualizzazione del browser, le frecce di selezione su / giù assomigliano al nostro fidato amico, la casella di selezione. Un utente presentato con uno spinner per la prima volta presumerà, poiché assomiglia a una casella di selezione, di non poter digitare in esso.
Il mio consiglio è di stare alla larga fino a quando non diventano un luogo più comune o gli sviluppatori del browser non risolvono il design predefinito.
3. Avere un solo tipo di pulsante o, meglio ancora, un solo pulsante per modulo
C'è un principio di psicologia poco conosciuto chiamato Legge di Hick. La legge di Hick afferma che più opzioni ci vengono offerte più è difficile fare una scelta. Non scienza missilistica che conosco, ma una regola che vale la pena tenere a mente.
Puoi aiutare il tuo simpatico utente aiutandolo a fare una scelta. Rendendo tutti i pulsanti primari un colore e averne solo uno per pagina rende la scelta più facile. Qual è il pulsante che dovrei premere? Oh, è facile, è quello grande colorato.
4. Campi di blocchi
Ho studiato neuroscienze in una vita precedente e quindi ho studiato la psicologia della memoria, in particolare la memoria a breve termine o di lavoro. Ora prima che tu lo dica; no, la capacità di memoria a breve termine non è 7 +/- 2, 4 +/- 1 o nel linguaggio umano da tre a cinque blocchi. Come esseri umani siamo bravi a valutare gli stimoli visivi, il vincolo è che siamo migliori quando il numero è più piccolo. Suddividere un modulo in gruppi più piccoli semplifica la valutazione, poiché spesso ciò che l'utente deve inserire nel modulo proviene dalla sua memoria.
Assicurati che i tuoi gruppi di campi siano lunghi circa quattro.
5. Pensa perché stai chiedendo qualcosa e come ci si sente per l'utente
Questo è probabilmente il consiglio più diretto che do, ma spesso è il meno utilizzato.
Prendiamo quanto segue:
Metti in discussione ogni domanda che fai. È necessario? Come ci si sente a chiederlo?
Il più delle volte c'è la necessità aziendale di porre una domanda e noi designer possiamo discutere della necessità finché non siamo blu in faccia. La domanda deve essere posta. Nella comprensione delle esigenze aziendali di questi dati, spesso possiamo scendere a compromessi.
Possiamo aiutare dicendo al nostro simpatico utente perché dobbiamo porre questa domanda. Rassicurati sull'utilizzo e la condivisione di tali dati e in generale sii gentile.
Riprendendo il nostro esempio:
È ancora una domanda difficile, ma speriamo di aver addolcito la pillola.
6. I datteri sono ragazzini che si dimenano
Inserire le date può essere una vera sfida e ci sono alcune insidie che puoi evitare. Il problema più grande è affrontare gli errori.
L'approccio più semplice è avviare un calendario. Vale la pena notare che le settimane iniziano di lunedì nel Regno Unito e di domenica negli Stati Uniti. Se il tuo utente non è concentrato, potrebbe selezionare una domenica quando intendono un lunedì.
Vale anche la pena menzionare i formati di data internazionali. Gli Stati Uniti sono al primo posto del mese, in Giappone al primo dell'anno. Quindi una data come 4/5/12 potrebbe essere interpretata in tre modi.
Ecco perché è meglio utilizzare le caselle di selezione.
7. Moduli come sviluppatore artigianale
I moduli sono creati per sviluppatori e designer. Capire quali possibili errori potrebbero essere commessi con l'immissione dei dati e la progettazione del codice back-end per farcela è una sfida.
Eccone uno semplice. Immissione di un valore di valuta. I possibili errori che l'utente potrebbe fare sono enormi. Forzare i formati di dati che gli utenti devono soddisfare è frustrante per il tuo utente e, ammettiamolo, un po 'pigro da parte degli sviluppatori.
Quale sfida migliore per uno sviluppatore che costruire un modulo a prova di proiettile.
8. Non utilizzare colonne nei moduli
Il grosso problema nell'usare le colonne nei moduli è il flusso. Iniziamo un modulo in alto e finiamo in basso. Nell'introdurre colonne il flusso della forma può essere interrotto.
Non dare per scontato che gli utenti scorrano i moduli con la tabulazione, quindi l'elemento attivo è un modo per spostarsi nei moduli nelle colonne. È raro che l'abbia visto durante i test degli utenti. Il più delle volte vediamo inserire i dettagli, fare clic sul campo successivo con il mouse / trackpad / dito, quindi inserire i dettagli e così via.
9. Non utilizzare due campi quando uno andrà bene
La maggior parte delle persone non sono dattilografi. Nei test utente vediamo persone che guardano la tastiera mentre digitano.
Quando si immette un numero di telefono che divide il campo del modulo, ad esempio per aggiungere prefisso e numero, si verificano problemi reali. Gli utenti non vedono o ricordano che ci sono due campi, quindi inserisci il numero completo nel primo campo, peggio se il campo è limitato a un certo numero di caratteri.
Usa un solo campo per il numero di telefono, lo stesso vale per il numero civico / via: usa solo una casella di immissione di testo.
10. Sii gentile
Saresti sorpreso di quanti messaggi di errore piuttosto scortesi ci siano là fuori.
Ecco un esempio di uno che mi sono imbattuto di recente.
Il fatto stesso che ti suggeriscano di inserire volentieri una data nel futuro e poi una risposta piuttosto scherzosa, beh, non è molto carino.
Mettiti di nuovo al posto dell'utente, come ti sentiresti a vedere questo errore? Infastidito? Forse anche peggio. Essere gentili è facile.
Ho prodotto una culla scaricabile / cheat sheet per aiutarti a progettare moduli migliori. Include molti altri metodi di best practice per progettare moduli migliori.
