Nella UX la ricerca non basta

Leave a comment
Experience design / Teoria
portrait-661997_640

Gli UX designer sono soliti dire che senza ricerca non esiste UX. Vero, ma il più delle volte la ricerca non basta e questo nessuno ce lo dice. Affronteremo l’importanza di coinvolgere gli stakeholder nel processo e gli step per progettare al meglio questa partecipazione.

Siete reduci dalle interviste con i clienti condotte sull’utilizzo della app che state progettando. Non è stato facile convincere il committente dell’utilità della ricerca, ma ci siete riusciti (bravi!). Ora state per presentare i risultati al team con i relativi interventi e…. nei mesi successivi non succede nulla di quello auspicato: l’IT continua con le sue convinzioni, il marketing procede con i suoi banner e l’AD con la certezza che i clienti non fanno la differenza sul mercato.

worksho di codesign

Lavorare e riflettere insieme aiuta a trovare soluzioni condivise all’interno del team

Cosa non ha funzionato?

Non ha funzionato il modo in cui la ricerca è stata introdotta nel progetto. Fare ricerca nel processo di user experience significa accompagnare le scelte da un coinvolgimento regolare e continuo nel tempo di tutti gli stakeholder interni.

Nel caso accennato sopra il problema chiave consiste nel fatto che gli interessi delle persone coinvolte nel progetto potrebbero essere diversi dai nostri.

Gli sviluppatori pensano che la tua idea sia interessante, ma è tecnicamente difficile e non hanno il tempo di sperimentare nuove soluzioni. L’amministratore delegato ha alcune idee che pensa vadano attuate subito e riguardano un target diverso da quello su cui ci siamo concentrati. Le persone di marketing stanno dicendo che hanno già fatto ricerche di marketing sui diversi gruppi target e non sono convinti che l’audience ristretta su cui abbiamo lavorato sia quella appropriata.

Una disfatta.

Siete un ufficiale in zona di guerra che ha conquistato la posizione nemica senza sapere che la strategia del comando era cambiata.

Il coinvolgimento degli stakeholder può essere un compito complesso se si lavora su un grande progetto per una grande impresa.
Proviamo a vedere quali sono i passaggi chiave che supportano il percorso di UX design che conducono cioè alla ricerca sui clienti finali e ai suoi risultati senza il pericolo di incappare in pericolosi loop involutivi.

Quello che vedremo vale meno per mini progetti o piccole imprese o startup, dove coinvolgere le parti interessate può essere un’attività più facile che richiede meno formalizzazione dei passaggi. In questo caso, è possibile ignorare alcuni degli step descritti di seguito, ma conoscerli aiuterà comunque ad assicurarci consenso e accordo nel processo.
Quindi, vediamo cosa fare prima di iniziare a eseguire la ricerca degli utenti.

Chi sono gli stakeholder?

Se sei uno UX designer, interno o esterno, devi assicurarti che gli obiettivi della ricerca siano chiari e condivisi con il resto dell’organizzazione, ma soprattutto di avere il consenso con i principali stakeholder del progetto.

Lo stakeholder è in generale una persona che detiene una partecipazione o abbia un qualche interesse nel progetto. Anche se gli utenti di un prodotto o un servizio hanno ovviamente un ruolo, usiamo solitamente il termine stakeholder per fare riferimento a persone chiave di una azienda coinvolta in un nuovo prodotto. Questo include spesso clienti, manager, capi dipartimento, esperti di settore e, a volte, rappresentanti dell’utente.
Facciamo un esempio concreto: in un progetto che sviluppa un’applicazione di monitoraggio delle performance per un ospedale, i soggetti interessati includeranno: dirigenti ospedalieri, responsabili dipartimento, un responsabile IT e medici e infermieri che rappresentano anche gli interessi dell’utente finale.

workshop interni alle aziende

Coinvolgere gli stakeholder aiuta tutto il processo di progettazione dall’inizio alla fine.

Il Project Management Istitute definisce gli stakeholder come: “un individuo, un gruppo o un’organizzazione che possa influenzare, essere influenzato o percepito tale da una decisione, un’attività o un risultato che il progetto mette in atto“.

In altre parole una gamma di persone, più o meno ampia.

L’individuazione degli stakeholder più importanti dipende ovviamente dallo scenario progettuale. Quindi, prima di avviare la ricerca sui clienti finali, vale la pena fare ricerca interna per individuare i principali stakeholder del progetto. Se siamo consulenti esterni, probabilmente abbiamo bisogno di un riferimento interno, una persona che ci supporti nell’identificazione dei principali stakeholder del progetto.

In piccoli progetti o piccole aziende è più facile: possiamo avere solo un paio di persone interessate e, in questo caso, coinvolgere gli stakeholder diventa più fluido e veloce. Possiamo identificarli direttamente con i referenti o con chi ha commissionato il lavoro, pertanto, domande e risposte diventa uno step molto rapido.

Nei progetti più grandi o nelle aziende, è possibile avere molte differenti persone interessate a vario titolo e ottenere una panoramica necessita tempo e lavoro.
Nel libro It’s Our Research Tomer Sharon, divide gli stakeholder nella ricerca UX in tre categorie generali:

  1. business
  2. engineering
  3. UX people.

1. Il business si riferisce a persone come i manager apicali, i responsabili di prodotti, il marketing e le vendite. Tutti questi profili ci garantiscono che la ricerca sia in linea con gli obiettivi aziendali in corso. Il supporto della direzione è prezioso per assicurarci di avere il tempo e le risorse necessarie per la tua ricerca e la sicurezza che l’azienda investirà in qualsiasi cambiamento di progetto che conseguente alla ricerca.

2. Gli stakeholder engineering sono IT come sviluppatori, programmatori o specialisti della sicurezza, persone addette alla qualità e al supporto tecnico interno o esterno.
Gli stakeholder tecnici possono fornire informazioni sulle limitazioni tecnologiche e sulla fattibilità tecnica. Oltre al fatto che gli sviluppatori sono quelli che devono implementare qualsiasi cambiamento che potrebbe provenire dal progetto di ricerca.

3. Gli stakeholder UX sono tutti coloro che lavorano in collegamento più o meno stretto con i clienti finali: altri designer, ricercatori, responsabili del customer care e della customer experience, addetti ai punti vendita e alla comunicazione.

Gli stakeholder sono gli esperti

Gli stakeholder sono i primi esperti d’ambito

Sono tutti quelli che hanno bisogno anche dei risultati della ricerca e con i quali non possiamo avere contrasti rispetto la direzione del progettazione del progetto. Gli stakeholder UX potranno fornire maggiori conoscenze sul tuo progetto e con diverse angolazioni sull’esperienza utente.

In Italia, soprattutto per le grandi aziende è necessario aggiungere la categoria “varie ed eventuali” (o pout pourri se preferite 🙂 dove ci sono tutti quei profili senza il coinvolgimento dei quali il progetto rischia il blocco: area legale, area amministrativa, sindacati, HR, e così via. In alcuni casi possono rappresentare scelte politiche ma, si sa, la politica ha il suo peso 🙂

Qual è la differenza tra clienti e stakeholder?

A volte le persone usano i termini “clienti” e “stakeholder” come sinonimi.

I clienti sono sempre anche stakeholder altrimenti non ci avrebbero commissionato il lavoro, ma definiamo stakeholder tutti coloro che possono contribuire attivamente alle decisioni attraverso il loro knowhow.
Nello specifico caso del processo UXd lo stakeholder è qualcuno interessato e coinvolgibile, l’AD di una multinazionale potrebbe essere potenzialmente interessato, ma difficilmente coinvolgibile, il manager dell’amministrazione può non essere interessato ad essere coinvolto e così via.

Perché coinvolgiamo gli stakeholder?

Ci sono diversi motivi per iniziare un progetto con la ricerca degli stakeholder.

Per raccogliere informazioni
Perché è necessario iniziare un progetto con una buona conoscenza dello scenario in cui andiamo ad operare: temi chiave, obiettivi di progetto, requisiti, criticità e target su cui puntare. Gli stakeholder sono gli esperti di dominio: le persone migliori con cui parlare per raccogliere tutte le informazioni iniziali.

Chiarire
A volte gli obiettivi sono chiari altre volte no.  Possono già esistere e un documento di specifiche rappresenta un ottimo inizio, ma, a volte, non esiste o non basta a spiegare molti aspetti. Allora diventa importante confrontarsi sugli obiettivi per chiarire il loro significato e capire le ragioni profonde e implicite.
Ad esempio, se gli obiettivi o le richieste descrivono caratteristiche specifiche, è fondamentale anche conoscere le ragioni dietro tali richieste al fine di acquisirle e portarle nella ricerca con i clienti finali o abbandonarle se prive di senso.

Ottenere il consenso
Forse questo è l’elemento più importante. Anche se già esistono requisiti o altri documenti di definizione del progetto, non si può essere sicuri che tutti li abbiano letti o che siano stati d’accordo. Quindi uno scopo della ricerca con gli stakeholder è quello di discutere apertamente gli obiettivi e le esigenze per assicurare che tutti i principali soggetti interessati siano d’accordo su di essi. Ciò aiuta a evitare inesattezze di base e disaccordi in seguito che possano far deragliare il progetto.

Prepararsi per la ricerca degli utenti

Gli stakeholder sono la nostra prima risorsa per raccogliere informazioni iniziali sugli utenti e i loro compiti, ma la ricerca con le parti interessate non è esaustiva: non assolve la necessità di condurre ricerche sugli utenti.
La ricerca con gli stakeholder fornisce un inizio di pianificazione riguardo la tipologia di utenti, i compiti e le situazioni da approfondire o gli argomenti da discutere.
Rappresenta anche il primo contatto tra stakeholder e utenti finali riguardo la ricerca, quello in cui coinvolgiamo attivamente le persone interne all’azienda nel processo di esplorazione sui loro clienti.

La raccolta delle informazioni iniziali


La portata della ricerca con gli stakeholder dipende dalla dimensione del progetto, se grande può essere necessario organizzare più di un incontro. Ogni progetto è unico, ma ci sono alcuni elementi che ritroviamo in maniera generale, per qualsiasi progetto abbiamo bisogno di conoscere:

  •   i motivi reali e profondi
  •   la storia pregressa
  •   gli obiettivi espliciti e impliciti
  •   le aspettative e gli ostacoli
  •   i clienti target e le loro caratteristiche
  •   le interazioni che i clienti eseguiranno
  • i contesti di utilizzo e i touchpoint
  •   gli obiettivi e le aspettative riguardo la ricerca sui clienti

A questi argomenti aggiungeremo eventuali peculiarità riguardo le cose da conoscere del progetto.

sessione di codesign

Lavorare in gruppi aiuta a rimuovere gli ostacoli

Raccolta pre-kickoff

Alcune informazioni possono essere raccolte prima della riunione di kickoff.
Chi di noi non legge in anticipo tutta la documentazione esistente, magari approfondendo con alcune figure chiave: ad esempio i venditori, il responsabile di progetto o chiunque sia coinvolto a  vario titolo nel progetto. E’ importante conoscere prima se il progetto assegna risorse e tempo alle attività di ricerca degli stakeholder.
In genere il primissimo studio è proprio online, quello che ci preparare ad un elenco di domande che proprio nel kickoff e nelle successive riunioni troveranno risposta.

L’incontro di kickoff

La riunione di kickoff normalmente fornisce un quadro generale, la panoramica di un progetto. È possibile porre domande iniziali e ottenere una demo di base di qualsiasi sistema attuale. Ma la riunione di solito non è mai abbastanza lunga per ottenere tutte le informazioni necessarie e potrebbe non includere tutte le persone con cui dobbiamo parlare. Tuttavia, su progetti più piccoli, questa potrebbe essere la nostra unica possibilità di parlare con gli stakeholder, quindi sfruttiamo al meglio l’opportunità.

La revisione della documentazione esistente

Dopo il kickoff  il primo passo consiste nel richiedere e rivedere tutte le informazioni già esistenti sul progetto, sul prodotto o sugli utenti. Ciò include la documentazione di prodotto, le precedenti ricerche sugli utenti, le analisi, le richieste di supporto, i feedback degli utenti, le presentazioni o altri materiali.

Le demo e le schermate dei sistemi

Per applicazioni più complesse, è utile ottenere una panoramica completa da un esperto dell’applicazione. Anche con una demo di base durante la riunione di kickoff, potrebbero essere necessari incontri per passare in dettaglio tutti gli aspetti del sistema.
Attività come i cognitive walkthrough o sessioni di apprendistato aiutano ad esplorare ambienti e sistemi nuovi.
In questi casi raccogliamo schermate e elaboriamo, guidati dallo stakeholder, un inventario ragionato delle interazioni del sistema.

Condurre la ricerca degli stakeholder

Tra i metodi principali per fare ricerca con gli stakeholder ci sono le interviste individuali o di gruppo e i workshop esplorativi.

Scegliere tra interviste e workshop

  • Le interviste esplorano e permettono di far emergere molta dell’esperienza personale.
  • I workshop fanno emergere molti aspetti attraverso attività pratiche che svelano anche temi meno espliciti.

I vantaggi delle interviste

Possiamo scegliere le interviste individuali con gli stakeholder per i seguenti motivi:

  • generare un confronto più approfondito e dettagliato con ogni persona
  • ascoltare la vera prospettiva e le opinioni di ogni persona senza che altri li influenzino
  • sentire le opinioni di persone più timide o meno inclini alle attività gruppo (es. senior, top manager, etc.).

Attraverso più sessioni, impareremo dalla ripetizione, potremo valutare quello che abbiamo imparato e avere l’opportunità approfondire negli incontri successivi.
Le interviste individuali sono più facili da controllare rispetto alle dinamiche e all’interazione delle sessioni di gruppo.

I vantaggi dei workshop

I workshop presentano i seguenti vantaggi:

  • generare una visione complessa e completa. Quando si riuniscono differenti stakeholder – con diversi di ruoli – nascono scenari sfaccettati che combinano molte visioni.
  • produrre consenso. Le attività di gruppo possono far emergere disaccordi, ma aiutano anche le persone a raggiungere consenso attraverso l’operatività, entrambi essenziali per procedere su un progetto.

Poiché i workshop richiedono in genere meno tempo rispetto alla conduzione di numerose interviste individuali, sono un modo efficiente per raccogliere rapidamente informazioni.

Il numero dei workshop da condurre

Se decidete di condurre i workshop, la pianificazione è essenziale. Il risultato dipende da molti fattori primi fra tutti tempo e risorse a disposizione. Le risorse disponibili possono determinare il numero di workshop da condurre. Su progetti piccoli possiamo avere il tempo di condurre anche un unico workshop con tutti coloro che sono coinvolti nel progetto. Nei progetti grandi, dobbiamo avere  tempo per valutare bene chi coinvolgere e  per condurre più workshop.

progettare i workshop

Ad ogni gruppo la corretta attività, chiediamoci sempre con chi stiamo progettando

La dimensione e la complessità del progetto

Sui progetti più grandi e più complessi, probabilmente avremo anche troppe persone interessate e molto confronto in ogni singola sessione. Le persone partecipano sempre volentieri se ascoltate, gli offrite attività innovative e se comprendono obiettivi e percorso. Ma le persone si stancano anche molto durante le attività, motivo per il quale la progettazione dei workshop deve essere condotta al millimetro.

Il numero degli stakeholder da includere

Il numero dipende dalla dimestichezza che avete nel facilitare i gruppi. Quando si tratta di  esponenti apicali dell’azienda è necessario mantenere un numero controllato di partecipanti (max 12). Mettere troppi manager insieme in un workshop rischia di indebolire l’obiettivo da conseguire.

I gruppi dovrebbero essere misti, ma è necessario valutare l’impatto che può avere mettere a collaborare manager apicali con funzionari o tecnici: potrebbero verificarsi rigidità o difficoltà generate dai ruoli. Se i partecipanti sono operativi possiamo spaziare ma a patto di non essere da soli a gestire l’attività. Nel caso di numeri consistenti si possono gestire più sessioni in più giorni. In quest’ultimo caso è bene progettare  un sistema di raccolta del materiale efficace tra una sessione e l’altra.

La durata del workshop

La durata può variare dagli scenari. In una azienda medio-grande con poca dimestichezza riguardo questo approccio possiamo prevedere sessioni da massimo 3 ore. Se l’azienda è abituata a sessioni di codesign allora si può lavorare anche 8 ore.

Per essere operativi su 3 ore ne dovete sempre calcolare almeno 4, se dovete coinvolgere i top manager dovete progettare sessioni da meno di 3 ore: meglio infatti tenere la loro attenzione per un’ora e mezza che avere sessioni più lunghe con persone che entrano e escono dalla sala per rispondere al telefono. Se il contributo dei manager è indispensabile e i temi sono tanti spezzate il workshop a metà, elaborate i risultati del primo workshop e metteteli in condizione di lavorare in un secondo incontro.

La logistica

Cosa fare insieme alle persone dipende molto anche dalla logistica che abbiamo a disposizione. Poter vedere la sala a disposizione aiuta molto una corretta progettazione, ma se questo non è possibile fatevi inviare delle foto. Chiedete che venga fotografata la sala nel suo insieme, i tavoli, le sedie, le pareti nel dettaglio, sembrerebbe superfluo, ma appena avrò modo pubblicherò un elenco di situazioni surreali che mi sono capitate nel tempo 🙂
Non dimenticate di portare con voi qualsiasi cosa che vi permetta di trasformare una sala d’aspetto in una sala per workshop (anche un trapano se necessario :).

Bene, abbiamo visto perché è importante coinvolgere gli stakeholder nella progettazione e tutte le cose a cui dobbiamo prestare attenzione per progettare correttamente questo coinvolgimento. Se gli stakeholder si sentono ascoltati e coinvolti difficilmente ostacoleranno le scelte perché le sentiranno proprie. Tale senso di appartenenza va costruito e mantenuto per tutto l’arco del progetto: la differenza rispetto al passato consiste nel divario tra un approccio univoco, elaborativo, monolitico e uno bidirezionale, collaborativo e generativo.
A voi e ai vostri stakeholder la scelta di quale direzione prendere 🙂

__________________________________

Volete imparare in pratica a coinvolgere i committenti di progetto?

Venite alla UX University

 

Condividi suShare on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Lascia un commento