Una tecnica pratica che ho imparato dal lavoro sbagliato ...

Anni fa, ho trascorso un periodo difficile della mia carriera come designer didattico, creando corsi per l'apprendimento online. E 'stata una brutta situazione e sono andata avanti felicemente, ma una parte di quel lavoro mi ha reso un designer UX migliore: obiettivi di apprendimento.

Gli obiettivi di apprendimento sono semplicemente ciò che vuoi che lo studente apprenda entro la fine della formazione. Se c'è un test, le domande del test dovrebbero essere basate su quegli obiettivi - altrimenti, qual è il punto del test?

Lo stesso approccio è utile per capire se un progetto ha superato o fallito un test di usabilità. Basta ricordare: è il design che viene testato, non i partecipanti.

Che cosa deve fare o dire il partecipante al test per farti sentire sicuro che il design ha avuto successo? Devono tracciare tre ore di tempo per un particolare progetto? Genera una fattura per un cliente in base a tale tempo tracciato? Invia la fattura? Questo è il tuo criterio di prova.

Ovviamente i test di usabilità riguardano l'osservazione del modo in cui gli utenti completano le attività, ma cosa farai loro, esattamente? La bellezza di questi criteri è che ti allontanano da vaghi obiettivi di test come "capire come funziona il monitoraggio del tempo". Come farai a sapere di averlo capito? Li ottieni per descriverlo. E una volta che l'hanno descritto in modo accurato, puoi dire che l'aspetto del design ha avuto successo.

I criteri di successo ti aiutano due volte: chiariscono se il tuo progetto ha davvero successo e rendono più facile la condivisione di questi risultati.

I verbi sono magici

Il libro che mi ha insegnato sugli obiettivi di apprendimento, di George Piskurich Rapido Design didattico , offre un utile elenco di comportamenti per avviare i criteri di successo.

Ad esempio, gli obiettivi per la comprensione potrebbero essere "descrivere" o "dimostrare". Ancora una volta, "capire" non va bene - hai bisogno che loro dicano (cioè descrivono) o facciano (cioè dimostra) qualcosa che ti dimostri di aver capito.

E poi, a un grado più alto di difficoltà, un partecipante potrebbe "spiegare" o "organizzare"; a un livello più alto ancora, potrebbero "creare" o "valutare".

Qualunque sia il verbo che si sceglie di avviare i criteri di successo, il punto è che è possibile osservare se un utente ha effettivamente detto o fatto qualsiasi cosa costituisca il successo dell'attività.

"Entro la fine di questa sessione ..."

Quindi, quando stai pianificando il tuo prossimo test di usabilità e stai lavorando alle attività, inizia chiedendo: "Che cosa dovrebbe fare un utente (o dire su) questo design?"

Quindi, potresti scrivere qualcosa come questo:

Entro la fine della sessione, il partecipante dovrebbe essere in grado di:

  • traccia tre ore di tempo per un particolare progetto;
  • generare una fattura per un cliente in base a tale tempo tracciato;
  • descrivere la differenza tra tempo di tracciamento e tempo di registrazione.

Ora hai tre criteri di successo e, in base a quelli, hai anche una chiara idea di quali compiti dovrai dare ai partecipanti.

Un avvertimento: i criteri di successo non sono esattamente gli stessi dei compiti. Le attività hanno più contesto; sono scritti per essere letti al partecipante e potrebbero includere alcuni contesti sull'attività, in particolare se li stai guidando per trovare qualcosa nel tuo prototipo. Per esempio:

Criteri di successo: generare una fattura per un cliente in base a tale tempo tracciato

Compito: "Ora che hai seguito tre ore sul progetto Atlas, mostrami come fatturare i Prodotti Acme per il tuo tempo."

Abbastanza simile, ovviamente, ma i criteri di successo sono per te e il tuo team; il compito è per il partecipante nel contesto della sessione di usabilità.

E noterai che uno dei criteri di successo sopra riguarda la descrizione di qualcosa, piuttosto che il completamento di un compito. Potrebbe essere una domanda successiva a un'attività. Sono utili per convalidare se il modello mentale del tuo progetto è chiaro per gli utenti. Ho visto gli utenti trovare la loro strada attraverso un compito, ma poi descrivermi un modello mentale dell'app che è in disaccordo con come è stato progettato. Questo è il successo del compito per un partecipante, ma soprattutto c'è un problema di fondo nel trovare corrispondenza con il modello mentale del partecipante.

Quindi, inizia con i tuoi criteri di successo, quindi scrivi i tuoi compiti e le domande di follow-up in base ai tuoi criteri.

Gli stakeholder amano i criteri di successo

Gli stakeholder non si preoccupano necessariamente del tuo processo, ma si preoccupano veramente dei risultati. E se la tua presentazione dei risultati è vaga, saranno giustamente irritati.

"L'utente è riuscito a tenere traccia di alcune ore, ma non eravamo sicuri se avesse capito che il tempo di tracciamento non è lo stesso che registrarlo su un client ..." Bene, perché non sei sicuro? Non è il tuo lavoro capirlo? Stai sprecando il loro tempo e non dando loro una chiara indicazione su come risolvere i problemi UX - che è anche il tuo lavoro, giusto?

I criteri di successo ti aiutano due volte: chiariscono se il tuo progetto ha davvero successo e rendono più facile la condivisione di questi risultati.

Abbiamo avuto un certo successo nel tracciare i criteri di successo in una tabella semplice e codificare a colori i risultati. Così:

puntamento

Produciamo una tabella di risultati con codice colore (verde = successo, rosso = fallimento) sulla nostra wiki. Nella riga in alto, elenchiamo i partecipanti; nella colonna di sinistra, elenchiamo i nostri criteri di successo. È brutto, ma veloce e utile.

È facile da analizzare, mostra chiaramente dove si trovano i problemi e fonda i risultati nelle esperienze dei partecipanti effettivi. Elenchiamo anche un riepilogo dei risultati in punti elenco e un elenco di problemi e raccomandazioni sull'usabilità appena sotto di esso. Ci concentreremo su quei problemi e proseguiremo fino a quando non crediamo che saranno risolti. Il tuo processo potrebbe essere un po 'diverso - forse sei un consulente che consegna un rapporto ad un cliente, ad esempio - ma i benefici sono gli stessi.