Verificare un prototipo con un compito concreto
Un esempio svolto su un documento mostra come assegnare un compito neutrale e tenere separate osservazione, interpretazione e modifica successiva.
Un test di prototipo richiede una domanda verificabile attraverso il comportamento. «Le piace il portale?» orienta poco. È più utile chiedersi se i clienti professionali trovino le condizioni di consegna attualmente approvate per il proprio account senza indicazioni sul percorso.
L’esempio è interamente ipotetico. Compito, documenti e note non provengono da uno studio con clienti realmente svolto.
Definire modello e successo prima del test
Il portale contiene il documento archiviato D-11 e la versione attuale approvata D-12. Il team conosce questo stato atteso. Il successo consiste nel trovare la versione attuale e spiegarne la correttezza tramite le informazioni mostrate.
Prepari il prototipo affinché il percorso sia davvero provabile. Collegamenti e stati pertinenti devono sostenere la domanda. Un modello che non apre il documento non dimostra il completamento del compito.
Assegnare un compito senza suggerire il percorso
Una possibile istruzione:
Sta preparando un ordine. Trovi le condizioni di consegna attualmente approvate per il Suo account cliente. Mostri come riconosce la versione valida.
Il compito indica l’obiettivo, senza menu o sequenza di clic. Scelga persone per cui il lavoro sia plausibile. Spieghi il test e la natura del modello. Non mostri prima il percorso.
Osservi le azioni effettive. Annoti domande e suggerimenti del moderatore. Trovare con aiuto è diverso dal riuscire autonomamente.
Separare osservazione e spiegazione
Le voci seguenti sono esempi inventati di analisi delle note.
Osservazione ipotizzata | Interpretazione possibile | Modifica o verifica successiva |
|---|---|---|
Apre la prima voce senza verificare l’approvazione | Lo stato potrebbe passare inosservato | Chiarire versione e approvazione, poi riprovare |
Il collegamento al documento non risponde nel modello | Qui il prototipo non supporta il compito | Aggiungere il collegamento o modificare esplicitamente l’ambito |
Trova il documento giusto solo dopo un suggerimento | Il completamento autonomo resta incerto | Riprovare il percorso modificato con un compito neutrale |
«La persona non capisce il portale» sarebbe già un’interpretazione ampia. Azioni concrete e stato esatto del modello sono più tracciabili. Un collegamento mancante è prima un problema del test, senza provare un errore dell’utente.
Ricavare il passo successivo
Decida quale incertezza deve risolvere la modifica. Provi poi la versione rivista con lo stesso obiettivo, senza suggerire la soluzione. Documenti persone, condizioni e parti del modello esaminate.
Un prototipo cliccabile non dimostra diritti reali, archiviazione persistente o prestazioni in produzione. Un compito riuscito non sostituisce neppure la verifica di accessibilità secondo standard. La prova può rispondere a domande precise; i limiti devono restare visibili nella decisione.
Fonti
Continuate a leggere
Tutti gli articoli
Design & UX con ASES
Esperienza utente, interfacce e immagine del marchio