Approfondimenti preziosi al momento giusto: determinazione del livello ideale di fedeltà della progettazione per i test degli utenti

In Intercom, uno dei nostri principi di sviluppo prodotto è pensare in grande, iniziare in piccolo, imparare velocemente.

Uno dei modi in cui impariamo velocemente è condurre una ricerca valutativa per creare fiducia nella direzione di progettazione del prodotto che stiamo perseguendo. Spesso miriamo a presentare i concetti di prodotto agli utenti molto presto nel processo di sviluppo del prodotto, molto prima che il codice sia stato scritto.

Questo approccio al test degli utenti pone una domanda importante e continua: qual è il giusto livello di fedeltà del design da presentare ai partecipanti alla ricerca? Quanto devono essere vicini al progetto finale quei concetti per ottenere spunti precisi da coloro che li stanno testando? Come trovi il giusto equilibrio tra “grezzo ma presto” da un lato e “lucido ma in ritardo” dall'altro? Quale livello di astrazione del design colpisce il punto debole?

"Abbiamo riscontrato che è utile evitare di usare il termine ' design' quando si parla internamente di cosa mostrare ai partecipanti: preferiamo usare ' stimolo di ricerca'"

Le parole contano

Prima di tutto, sebbene si parli di fedeltà alla progettazione, abbiamo riscontrato che è utile evitare di usare il termine “design” quando si parla internamente di cosa mostrare ai partecipanti durante i test degli utenti – preferiamo usare “stimolo della ricerca”. Termini come "stimolo di ricerca" o "artefatto di provocazione", anche se suonano un po' traballanti, aiutano a comunicare che la cosa che mostrerai a un partecipante è uno strumento per ottenere approfondimenti su un concetto generale, piuttosto che su caratteristiche specifiche del design.

Identifica il problema

Può essere allettante utilizzare i file di progettazione più recenti e raffinati disponibili durante la creazione dello stimolo di ricerca, ma ciò comporta alcuni costi che devono essere considerati. I partecipanti presteranno attenzione al più alto livello di fedeltà che fornisci: se sei interessato a sapere se un concetto ha valore, è probabile che ascoltare i commenti dei partecipanti sulla microcopia su un CTA aggiunga rumore al feedback che stai cercando.

Invece, abbiamo riscontrato che è utile iniziare con il problema - ciò che stiamo cercando di conoscere - e abbinarlo alla fedeltà di ciò che mostriamo ai partecipanti alla ricerca durante i test degli utenti.

Quindi, per determinare la corretta fedeltà di progettazione, è necessario identificare quale dei seguenti problemi stai cercando di risolvere:

• Concetti di verifica: questa idea ha valore?
• Progettazione del sistema di test: gli utenti possono formarsi una comprensione "abbastanza buona" di questo sistema?
• Testare l'usabilità: le persone possono usare questo prodotto?

Una volta stabilito il problema che stai cercando di risolvere, ciò ti aiuterà a determinare quale livello di fedeltà progettuale è richiesto dal tuo stimolo di ricerca.

Essere chiari sul problema in anticipo aiuta anche a creare allineamento con i tuoi partner interfunzionali in termini di progettazione, prodotto e ingegneria, tanto più importante perché creare uno stimolo di ricerca è uno sforzo collaborativo e uno in cui la proprietà può non essere chiara.

“Nelle prime fasi, non sei interessato a come interagirebbero con esso. Ti interessa sapere se sarebbe prezioso per loro"

Concetti di verifica: questa idea ha valore?

A questo punto, il tuo problema è capire "Questa idea ha valore?" Nello specifico, i clienti pensano che questa idea li aiuterà a risolvere i problemi con cui stanno lottando? Nelle prime fasi, non sei interessato a come interagirebbero con esso. Ti interessa sapere se sarebbe prezioso per loro.

Durante il test stesso, vorrai confermare che il partecipante sperimenta effettivamente il problema che stai cercando di risolvere, mostrare loro il concetto e valutare se si aspettano che risolva il problema in modo valido.

Il tuo stimolo di prova non ha bisogno di sembrare un'interfaccia a questo punto. In effetti, probabilmente è meglio se non lo fa: se scegli di presentare i concetti come un'interfaccia, tieni presente che i tuoi partecipanti potrebbero saltare avanti pensando a come interagirebbero con esso, come si collegherebbe al resto di il tuo prodotto e cosa pensano del design visivo. Questo tipo di feedback è più facile da dare, quindi i partecipanti graviteranno naturalmente verso di esso invece di pensare profondamente al concetto stesso e a come potrebbe affrontare il problema che stanno vivendo. Il tuo stimolo di ricerca deve solo comunicare l'idea che stai testando e poco altro.

Descrizioni di testo veloci, storyboard, modelli di landing page, diagrammi in Presentazioni Google o doodle in stile lavagna sono tutte opzioni legittime. Mantienilo semplice e mirato sfocando la copia non necessaria e utilizzando ovvi grafici segnaposto.

Progettazione del sistema di test: gli utenti possono formarsi una comprensione "abbastanza buona" di questo sistema?

A volte, un team di prodotto può lavorare alla creazione di un intero sistema , piuttosto che di interfacce o flussi. Quando si effettuano ricerche in questa fase, probabilmente la domanda è se, sulla base di ciò che il team ha concepito finora, i tuoi utenti possono formare modelli mentali funzionali che consentiranno loro di utilizzare il prodotto senza essere bloccati o confusi. La migliore prova di ciò è se gli utenti possono fare previsioni accurate su come svolgerebbero attività rappresentative all'interno del tuo sistema.

Mentre potresti semplicemente mostrare diagrammi astratti del sistema e chiedere agli utenti come si aspetterebbero di interagire con esso, questo non ha molta validità ecologica; in realtà mostrare stimoli che assomigliano più a un'interfaccia utente rende la ricerca più realistica. Ancora una volta, però, abbiamo scoperto che chiedere a un partecipante di utilizzare effettivamente un prototipo rende quasi impossibile non distogliere la sua attenzione dall'interaction design, e probabilmente non stai ancora risolvendo.

Considera di dare loro problemi realistici e di chiedere loro di spiegarti come si aspetterebbero di affrontarli usando le tue interfacce simulate, mentre condividi lo schermo e ti occupi delle interazioni specifiche che li muovono attraverso il prodotto. Ciò ti farà risparmiare la creazione di prototipi completamente interattivi prima di avere fiducia nella direzione del design o il rischio di frustrare i partecipanti con interazioni che sai essere ancora janky.

Testare l'usabilità: le persone possono usare questo prodotto?

In questa fase vorrai sapere se un utente può interagire con il tuo prodotto con un livello di supporto realistico (ad es. non più onboarding di quello che probabilmente fornirai nel prodotto finale) ed eseguire attività che rappresentano il problema che tu stai risolvendo.

Esistono molti tipi di test di usabilità e in tutti il ​​design dell'interazione diventa più importante. Puoi testare l'usabilità con prototipi di vari livelli di fedeltà, una volta che sei chiaro e specifico sui compiti che vuoi che i tuoi partecipanti svolgano e testino e le interazioni necessarie per abilitarli sono supportate nel prototipo.

In sintesi

Le linee tra queste fasi sono sfocate e può essere difficile atterrare sul protocollo giusto per la tua situazione. Preparati a modificare sia lo stimolo della ricerca che le domande che poni di sessione in sessione.

Infine, non c'è nulla di male nel chiedere ai partecipanti come hanno trovato la sessione di ricerca stessa, piuttosto che gli stimoli di ricerca. Confusione o frustrazione sono un segno che hai ancora del lavoro da fare. E se rimani bloccato, ricorda di iniziare con il problema: cosa stai cercando di ottenere esattamente dalla sessione di test degli utenti?

Vuoi saperne di più su come lavorare con il nostro team? Leggi i nostri valori, il modo in cui lavoriamo e i nostri ruoli aperti qui.