Lavorare con user researcher esterni: parte II

Nella prima parte di Lavorare con user researcher esterni, abbiamo esplorato le ragioni per le quali potreste assumere uno user researcher a contratto e cose utili da sapere per sceglierne uno. Questa volta, parliamo del fare effettivamente il lavoro.

L’articolo prosegue sotto

Avete assunto uno user researcher per il vostro progetto. Congratulazioni! Sulla carta, questa persona (o gruppo di persone) ha tutto ciò di cui avete bisogno e altro ancora. Potreste pensare che la parte più difficile del vostro progetto sia completa e che da questo momento possiate evitare di metterci il becco. Ma il vero lavoro non è ancora iniziato. Assumere il ricercatore è solo l’inizio del viaggio.

Ricapitoliamo cosa intendiamo per user researcher esterno. Assumere uno user researcher esterno a contratto significa che la persona o il team vengono assunti per la durata di un contratto per condurre delle ricerche.

Questa situazione si trova più comunemente in:

  • organizzazioni senza ricercatori nello staff;
  • organizzazioni il cui personale di ricerca è al massimo
  • e organizzazioni che necessitano di competenze specifiche.

In altre parole, gli user researcher esterni esistono per aiutarvi a ottenere degli insight dai vostri utenti quando assumerne uno a tempo pieno non è un’opzione. Guardate la Parte I per saperne di più su come trovare degli user researcher esterni, i tipi di progetti che vi daranno più valore per i vostri soldi, scrivere una request for proposal e, infine, negoziare il pagamento.

Lavorare insieme#section1

Ricordatevi perché avete assunto un ricercatore esterno#section2

Nessun progetto o relazione di lavoro è perfetta. Prima di immergerci in linee guida più specifiche su come lavorare bene insieme, ricordatevi le ragioni per cui avete deciso di assumere un ricercatore esterno (e questo nello specifico) per il vostro progetto. Tenerle a mente mentre lavorate assieme vi aiuterà a tenere in ordine le vostre priorità.

I ricercatori esterni sono ottimi per portare una prospettiva oggettiva e fresca#section3

Potreste chiedere al vostro designer full-time, il quale ha anche delle skill di ricerca, di indossare quel cappello. Non è inconsueto. Ma un designer non avrà la stessa profondità e ampiezza di esperienza di un ricercatore dedicato. Inoltre, probabilmente finiranno a fare ricerca sul proprio lavoro di design, cosa che renderebbe molto difficile per loro rimanere obiettivi.

A volte ai product manager piace essere proattivi e condurre qualche forma di guerrilla user research, ma questa è un’idea ancora più rischiosa. Per esempio, solitamente non sono addestrati a porre domande non allusive, quindi tendono solo ad ascoltare quel feedback che valida le loro idee.

Non è un segreto ma vale davvero la pena ricordare che i partecipanti alla ricerca tendono ad essere più a proprio agio a condividere feedback critico con qualcuno che non lavora per il prodotto che si sta testando.

Comincia il vero lavoro#section4

Nella nostra esperienza il lavoro più importante comincia una volta che il ricercatore è assunto. Ecco alcune considerazioni chiave per l’impostazione loro e del vostro team di progetto per il successo.

Siate smart nell’iniziale passaggio di conoscenze#section5

Condividete i materiali di background che forniscono un contesto importane e impediscono che si faccia lavoro ridondante. È probabile che alcuni insight siano già noti su un argomento che verrà ricercato, quindi è importante condividere questa conoscenza con il vostro ricercatore, così che possa concentrarsi su nuove aree di indagine. Fornite cose come template di report per essere sicuri che il ricercatore presenti quello che ha appreso in un modo che sia consistente con la cultura unica della vostra organizzazione. Già che ci siete, considerate di mostrare loro dove trovare documentazione o tutorial sul vostro prodotto o su gergo specifico del settore.

Assicuratevi che le persone sappiano chi sono#section6

Fate un kick-off meeting di progetto con il ricercatore esterno e con i vostri stakeholder interni. L’influenza è spesso parzialmente un fattore di fiducia e per questo motivo è a volte facile per gli stakeholder interni porre domande o trascurare progetti condotti da consulenti di ricerca, specialmente se sono in disaccordo con gli insight e le raccomandazioni della ricerca. (Chi è questa persona che non conosco che cerca di dirmi cosa è meglio per il mio prodotto?)

Fate un kick-off meeting con il team più ampio#section7

Un ottimo modo per prevenire questo potenziale respingimento è di condurre un kick-off meeting di progetto con il ricercatore esterno e gli stakeholder interni importanti o i consumatori della ricerca. Un tale meeting potrebbe includere attività come:

  • presentazioni del team.
  • Una discussione sulle domande della ricerca, incluso un esercizio per assegnare le priorità alle domande. Specialmente con i progetti dati a contratto, è comune che i team di progetto siano tentati di aggiungere più domande – “question creep” – che è il motivo per cui è importare avere delle priorità chiare fin dall’inizio.
  • Un riassunto di quello che esula dallo scopo della ricerca. Questo è un altro task importante nell’impostare limiti saldi attorno alle priorità di progetto fin dall’inizio, così il progetto viene completato in tempo e all’interno del budget.
  • Un riassunto di ogni ipotesi in ingresso che potrebbe avere il team di progetto. In altre parole, quelle che pensano possano essere le risposte alle domande della ricerca. Questo può essere un esercizio di particolare impatto per ricordare agli stakeholder come il loro pensiero iniziale è cambiato in risposta ai risultati dello studio che si sta completando.
  • Una revisione delle fasi del progetto e della sua timeline e qualunque minaccia che possa mettersi sulla strada verso la fine per tempo del progetto.
  • Una revisione della ricerca precedente e cosa si sa già, se è disponibile. Questo è importante sia per il ricercatore esterno e maggiormente importante per i consumatori interni della ricerca, dato che spesso il team di progetto più ampio potrebbe non essere cosciente della ricerca precedente e perché certe domande a cui è già stata data risposta non vengono gestite nel progetto attuale.

Usate un “buddy system”#section8

Nominate una risorsa interna che possa rispondere alle domande che indubbiamente verranno sollevate durante il progetto. Questo potrebbe includere domande su come usare un laboratorio interno, domande su chi invitare a una riunione critica o domande chiarificatrici riguardanti le priorità di progetto. Inoltre, questa costituisce un’opportunità per creare fiducia e un buon rapporto tra il vostro team di progetto e il ricercatore esterno.

Condurre la ricerca#section9

Sebbene un ricercatore esterno o un’agenzia possano aiutarvi a pianificare e condurre uno studio per voi, non aspettatevi che siano esperti del vostro prodotto o della vostra cultura aziendale. È come assumere un architetto per costruire la vostra casa o un designer per arredare una stanza: dovete fornire una guida presto e spesso, o il risultato finale potrebbe non essere quello che vi aspettate. Ecco alcune cose da considerare per rendere più efficace l’impegno.

Siate disponibili#section10

Un buon libero professionista che si occupa di ricerca farà molte domande per essere sicuro di aver compreso dettagli importanti, come le vostre priorità e le domande di ricerca e di collezionare feedback sul piano di studio e sul report di ricerca. Sebbene a volte possa sembrare più efficiente gestire la maggior parte di questo tipo di domande via email, l’email può spesso risultare in fraintendimenti. A volte è più rapido parlare nel caso di domande che richiedono molti dettagli e contesto piuttosto che scrivere una risposta. Prendete in considerazione di stabilire uno status check settimanale, da remoto o di persona, per discutere le domande aperte e le cose su cui agire.

Siate presenti#section11

Se le sessioni moderate fanno parte della ricerca, pianificate di osservarne quante più possibile. Sebbene dovreste aspettarvi un report finale dall’agenzia di ricerca, non dovreste aspettarvi che conoscano quali insight hanno maggior impatto sul vostro progetto. Non hanno il background derivante dalla riunioni interne, dalle decisioni precedenti e dalle discussioni riguardanti le direzioni future del prodotto che invece ha uno stakeholder interno. Molte delle scoperte più perspicaci vengono da conversazioni che si tengono immediatamente dopo una sessione con un partecipante alla ricerca. Il moderatore della ricerca e il contatto del cliente possono condividere le proprie prospettive su quello che il partecipante ha appena fatto e detto durante la loro sessione.

Siate proattivi#section12

Prima che il ricercatore faccia la bozza del proprio report finale, fissate una riunione fra lui e i vostri stakeholder interni per fare brainstorming sui risultati principali della ricerca. Questo aiuterà il ricercatore ad identificare più insight e opportunità che riflettano le priorità e i limiti interni. Inoltre, aiuta gli stakeholder a creare fiducia nei risultati della ricerca.

In altre parole, è un perdita di tempo per tutti se il report finale viene consegnato e vengono sollevate dagli stakeholder delle domande di base che avrebbero potuto essere gestite coinvolgendoli prima. Si tratta anche di una buona opportunità per avere un feedback dagli stakeholder, che potrebbero avere un’influenza diversa (ma altrettanto importante) sul successo del progetto.

Siate ragionevoli#section13

Non trattate il collaboratore esterno come un fantino di PowerPoint. Cambiare font e colori a vostro piacimento va bene, ma solo fino a un certo punto. Il vostro ricercatore dovrebbe fornirvi un report ricercato, senza errori e in un formato professionale, ma i piccoli cambiamenti non sono un uso costruttivo di tempo e soldi. Concentratevi di più sulle decisioni e sulle raccomandazioni piuttosto che sull’estetica dei deliverable. Potete prevenire questo tipo di situazione fornendo tutti i template che volete usare nel vostro iniziale “brain dump”, così che i risultati non debbano essere riversati nel “giusto” formato per la presentazione.

Quando è tutto finito#section14

Solo perché il progetto è stato completato e tutti i deliverable concordati sono stati ricevuti, non significa che dovreste chiudere la porta a qualsiasi altra opportunità di apprendimento aggiuntiva, sia per il cliente sia per il ricercatore. Alla fine del progetto, identificate cosa ha funzionato e cercate dei modi per far aumentare il buy-in per le loro raccomandazioni.

Dite loro cosa è successo#section15

Cercate di identificare dei punti di check-in nel futuro (come due settimane o mesi) per far sapere al ricercatore cosa è successo per via della ricerca: che decisioni sono state prese, che problemi sono stati risolti o altri cambiamenti nel design. Sebbene non possiate aspettarvi che il vostro ricercatore sia perpetuamente disponibile, se incontrate dei problemi con il buy-in, potrebbero essere in grado di fornirvi delle rapide raccomandazioni.

Mantenere una relazione#section16

Sebbene sia tipico per i venditori offrire una cena o da bere ai propri clienti, non abbiate paura di invitare il vostro ricercatore esterno al vostro happy hour o a un evento con il vostro staff. Il successo del vostro progetto successivo potrebbe dipendere dall’avere il ricercatore giusto e vorrete che siano felici di rendersi disponibili ad aiutarvi quando ne avrete di nuovo bisogno.

Sull’autore

Chelsey Glasson

Chelsey Glasson è una user experience researcher le cui skill hanno informato una gran varietà di imprese e consumer product in aziende grandi e piccole.

Cory Lebson

Cory Lebson è stato uno UX consultant per più di due decenni e attraverso la sua azienda, Lebsontech LLC, si concentra sulla user research and evaluation, sull'accessibilità, sullo UX training e sul mentoring. È l'autore di The UX Careers Handbook, è un istruttore di LinkedIn Learning/Lynda.com e in passato è stato presidente di UXPA International.

Jeff Sauro

Jeff Sauro è il founding principal of MeasuringU, un'azienda di UX research a Denver. È l'autore di sei libri, incluso l'imminente “Benchmarking the User Experience”. Jeff ha un PhD in Research Methods & Statistics e scrive un articolo alla settimana online su MeasuringU.com.

Nessun commento

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altro da ALA

Webwaste

In questo estratto da World Wide Waste, Gerry McGovern esamina l'impatto ambientale di siti web pieni zeppi di asset inutili. Digital is physical. Sembra economico e gratis ma non lo è: ci costa la Terra.
Industry