Come fare ricerca utente nel software enterprise quando non puoi raggiungere gli utenti?

Abbiamo seguito la progettazione di un software senza poter aver accesso diretto agli utenti. Ci siamo riusciti coinvolgendo gli stakeholder in interviste e attività di workshop.

Autore

Sara Fazzini

⚠️ Disclaimer (proprio come sulle confezioni dei medicinali)

Belka sconsiglia di progettare prodotti senza coinvolgere gli utenti. Questo è il racconto di come abbiamo cercato di affrontare comunque i problemi, ma niente batte una buona ricerca iniziale che coinvolga gli utilizzatori finali. Consulta il tuo esperto di UX prima di intraprendere azioni di redesign in assenza di utenti.

Abbiamo comunque deciso di condividere la nostra esperienza in questo progetto perché ci sembra utile, nel caso qualcun altro si trovi in situazioni analoghe.

Che fine han fatto gli utenti?

Lo scenario è la riprogettazione di un software finanziario per un settore molto specifico dove i clienti sono pochi e poco accessibili a causa della compliance.

L’azienda con cui abbiamo lavorato non ha un approccio design driven. Abbiamo capito presto che non avremmo potuto coinvolgere direttamente gli utenti. Come designer ci siamo sentiti spaesati e bloccati.

Confused dogs

Come si può portare valore in queste situazioni?

Abbiamo valutato diversi approcci per affrontare la situazione: non avevamo intenzione di progettare affidandoci alle nostre intuizioni, e nemmeno rinunciare al progetto. Volevamo portare il nostro contributo e accompagnare a piccoli passi l’azienda a conoscere il valore del design.

Abbiamo puntato sullo spunto più promettente: ripartire dai 3 stakeholder principalmente coinvolti nel progetto

Perché proprio gli stakeholder

Gli stakeholder sono persone interne o esterne all’azienda coinvolte con diversi gradi e interesse nella realizzazione e nell’uso del prodotto. Gli stakeholder interni all’azienda possono essere ad esempio:

  • manager
  • sviluppatori
  • responsabili del marketing
  • responsabili del customer service

È fondamentale capire quali sono le persone chiave da coinvolgere, che responsabilità e che ruolo hanno nel progetto.

Nel nostro caso gli stakeholder con cui ci confrontiamo sono persone dell’area IT con un impatto diretto sul progetto: si occupano del mantenimento del software e di soddisfare le richieste degli utenti che arrivano dall’assistenza. Ci hanno saputo aiutare in quattro aspetti.

one two three four

Conoscono il contesto. Tu, molto probabilmente, non ancora. Quando si progetta in ambito enterprise è fondamentale conoscere il dominio del prodotto. Gli stakeholder possono spiegarti il linguaggio del settore, i concetti e i flussi di lavoro esistenti.

Hanno visto i bisogni dell’utente. Spesso gli stakeholder lavorano a fianco degli utenti, o sono stati utenti a loro volta. Hanno una visione d’insieme sulle tipologie di utente che la utilizzano, e i loro bisogni principali. Un esempio: ci siamo confrontati con l’assistenza clienti per individuare i problemi d’uso emersi esplicitamente.

Sanno quali saranno le funzionalità core del prodotto. Ci confrontiamo con gli stakeholder per capire quali funzionalità saranno necessarie nel software, e quali invece non fanno parte della value proposition del prodotto.

Possono chiarire i limiti tecnici. Gli stakeholder sanno quali sono i vincoli tecnici del software e quali sono i requisiti dal punto di vista di compliance del settore.

Parlarsi non basta

Abbiamo iniziato le attività con dei meeting per il team al completo (4 stakeholder e 2 designer), ma ci siamo accorti presto di alcuni problemi. Gli incontri erano lunghi e dispersivi. Spesso la conversazione era monopolizzata da una persona, con gli altri ad approvare passivamente.

Sono aspetti che di frequente accompagnano l’attività di brainstorming di gruppo; inoltre come confermato da molte ricerche, le idee prodotte in attività di questo tipo sono meno efficaci rispetto a quelle di brainstorming individuali. Ci siamo resi conto che non era la modalità giusta di procedere.

Avevamo bisogno di valorizzare al meglio il contributo di ogni stakeholder e di poter approfondire gli argomenti.

Per risolvere questi problemi di comunicazione abbiamo deciso di coinvolgere gli stakeholder in due momenti diversi:

  • Interviste individuali, per capire meglio il contesto d’uso del software, assorbire il massimo delle informazioni senza però esserne sopraffatti, e individuare più facilmente eventuali incongruenze.
  • Sessioni di workshop in plenaria da remoto.

Le interviste

Prima di iniziare qualsiasi attività di ricerca solitamente ci diamo degli obiettivi ben chiari. Nel nostro caso erano questi:

  • Avere chiari i requisiti tecnici e di business
  • Identificare il task
  • Comprendere in cosa consiste il task e i principali contesti d’uso
  • Capire perché l’utente ha bisogno di quel task e come si articola

Per raggiungere questi obiettivi abbiamo incentrato le domande sul task, chiedendo agli stakeholder di focalizzarsi

  • sull’obiettivo di quell’attività,
  • sulle azioni che deve compiere l’utente e
  • su quali problemi incontra nel farlo.

Non sapevamo nulla sui software attuali, quindi abbiamo chiesto chiarimenti anche sugli aspetti più basilari e scontati agli occhi del nostro cliente. Meglio una domanda in più che una in meno in questa fase!

Attraverso ambienti demo dei programmi attuali e la possibilità di condividere lo schermo abbiamo ottenuto le risposte che cercavamo.

Dog with an idea

Come non mettere le soluzioni davanti ai problemi

Padroneggiare il dominio e mantenere gli stakeholder concentrati sul problema sono stati i due aspetti più sfidanti di questo percorso.

Strutturare i confronti

Per comprendere al meglio un contesto così specifico abbiamo coinvolto regolarmente gli stakeholder durante tutto il percorso progettuale, per chiarire dubbi o validare le assunzioni.

Abbiamo affiancato alle interviste delle sessioni di workshop in cui mappare con loro i vari elementi con cui interagiscono gli utenti. Per farlo ci siamo basati su un approccio chiamato Object Oriented UX.

Saltare alle soluzioni prima di chiarire i problemi

Gli stakeholder si sono sentiti coinvolti e partecipi, spesso propensi a presentarci già delle soluzioni a quelli che riconoscevano essere i problemi dei prodotti attuali. Il nostro sforzo in quanto designer è stato limitare il brainstorming di soluzioni e cercare di concentrarci sul far emergere tutti i problemi presenti.

Prima di iniziare qualsiasi attività, che sia un workshop o un’intervista, chiarisci gli obiettivi e in che modo è chiesto agli stakeholder di partecipare. Se la conversazione devia in modo sterile, interrompi gentilmente la discussione, ricordando esplicitamente cosa state facendo e perché.

Sappiamo che un problema ben formulato apre la strada ad una soluzione funzionale, e non vogliamo anticipare o mescolare le fasi progettuali senza motivo.

Lezioni imparate

Da questo progetto stiamo raccogliendo spunti e conferme interessanti:

  • Non esiste il metodo perfetto che vale per tutti i progetti, ma esiste il metodo che ti permette di imparare meglio nel contesto in cui ti trovi. Nel nostro caso, senza accesso agli utenti, rivolgerci agli stakeholder è stata la scelta metodologica vincente.
  • Il nostro lavoro di designer è sempre anche un lavoro di educazione, in cui chiediamo agli altri di allenare lo sguardo critico e di seguire con noi un processo. Sappiamo quanto sia cruciale e difficile parlare di scelte progettuali con gli stakeholder, perciò crediamo che sia una competenza che un buon designer deve saper maturare.
  • Non possiamo prescindere da buone relazioni di collaborazione con gli stakeholder. Un gruppo di lavoro che collabora con piacere e coinvolgimento è un gruppo che darà buoni risultati; manteniamo le relazioni con cura, mostriamo interesse verso le opinioni di ciascuno.
  • Capire il contesto è una fase complicata, spesso la più ardua nei progetti enterprise: facciamoci aiutare da chi lo conosce bene.
  • Pianificare il processo di progettazione è parte attiva del lavoro del designer. Il tuo ruolo è proprio quello di trovare le metodologie più corrette per portare il progetto al successo. Le scelte metodologiche influenzano molto l’output che puoi produrre.

Riferimenti

Autore

Sara Fazzini

Resta in contatto con noi!

Ci piace condividere quello che impariamo.
Resta aggiornato iscrivendoti alla nostra newsletter.

Iscrivendoti accetti di ricevere la nostra newsletter periodica. Useremo il tuo indirizzo e-mail unicamente per inviarti aggiornamenti sulle nostre attività.
Leggi l’informativa completa.