Riflettevo nell’ultimo periodo sulla sorte di questo blog, più che sulla sorte, forse, sulla sua linea editoriale (messa così fa un altro effetto ;)).
Sto lentamente cambiando pelle, professionalmente parlando, e a volte mi sembra che parlare solo di comunicazione sia in qualche modo riduttivo.
Mi sto appassionando ad argomenti nuovi, come la UX research e lo UX design e mi trovo anche a gestire progetti. Attività che a volte esulano dalla comunicazione in senso stretto, ma che richiedono comunque doti di buon comunicatore.
Quello su cui sto riflettendo, infatti, è che quando ci si trova ad aver a che fare con le persone è indispensabile usare tutte le nostre doti per comunicare con loro nel modo giusto.
Per questo ho deciso di inaugurare una specie di rubrica “Comunicare con cura con/per/cosa…” in cui cercherò di raccontare la mia personale esperienza, i miei errori e quello che, invece, imparo da ogni situazione. Come al solito cerco di fissare attraverso le parole i miei pensieri, ma nell’ottica del dono, spero veramente che la mia esperienza possa essere d’aiuto a qualcun’altro, perché io, se trovassi qualcuno che mi dà qualche dritta nell’affrontare situazioni, ruoli, esperienze che non conosco sarei veramente contenta :).
Saper
Credevo fosse un problema mio. Ho un caratterino, me ne rendo conto, e quando chiedo qualcosa pretendo che venga fatto nei tempi e nei modi stabiliti, perciò pensavo fosse questo mio atteggiamento esigente a crearmi qualche problema di relazione, ma ho scoperto, con piacere, che è un sentire diffuso.
Come UX specialist mi occupo di analizzare e recepire i bisogni dei clienti, lo faccio intervistandoli, passando giornate intere con loro mentre svolgono il loro lavoro, facendo dei test su prototipi. Una volta svolta questa fase di ricerca comincio a progettare come i loro bisogni possono diventare delle funzionalità di un’applicazione e, velocizzando e sintetizzando al massimo, arrivo al punto in cui devo confrontarmi con gli sviluppatori.
Intanto spieghiamo bene chi sono. Sono coloro che si occupano effettivamente di creare il prodotto per le nostre persone, quindi trattiamoli bene perché senza di loro, noi, non combiniamo nulla. Capita a volte che siano delle persone un po’ introverse, che non amino avere un rapporto diretto con il cliente, e che magari non abbiano nemmeno molto piacere a parlare con noi che vogliamo spiegargli come fare il loro lavoro. Altre volte, invece, sono persone molto socievoli, attente ai bisogni dell’utente, fantasiosi e aperte al confronto. E’ questione di fortuna.
Nella prima ipotesi le probabilità di fare o dire qualcosa di sgradito che indisponga il nostro interlocutore è maggiore. Quello che generalmente può succedere è che si inizino discussioni infinite in cui voi chiedete di semplificare una procedura o la navigazione per facilitare la vita all’utente, mentre il vostro sviluppatore rimanga fermo nelle sue posizioni dicendo che non si può fare, che è troppo complesso, che ci vuole troppo tempo. Bene, a questo punto avete due possibilità: continuare a discutere all’infinito sperando di raggiungere la vittoria per sfinimento dell’avversario, oppure cercare una mediazione.
Generalmente lo sviluppatore ha ben chiaro perché essere contrario alla vostra opinione, ma voi, sapete esattamente come sostenere la vostra argomentazione? A volte non basta dire “l’utente non può fare un’operazione così complessa”, bisogna aggiungere qualche dato oggettivo. Potrebbe essere la percentuale di abbandono di una procedura, il risultato di un test effettuato su un prototipo, il cambiamento di un pattern che è già riconosciuto e utilizzato in altre parti dell’applicazione e che richiederebbe uno sforzo cognitivo ulteriore all’utente.
Solitamente questo modo di sostenere le proprie idee mette in luce il problema da un altro punto di vista che non era stato considerato dallo sviluppatore e favorisce l’immedesimazione con l’utente. Inoltre portare dei dati oggettivi, citare delle fonti o delle evidenze (test con gli utenti) accresce la vostra autorevolezza sul tema ai suoi occhi, fa capire che siete preparati su un argomento e rende le sue tesi (è troppo complicato, ecc.) più deboli.
Quello che dobbiamo fare è lavorare e collaborare insieme verso uno scopo comune: far utilizzare la nostra applicazione, il nostro software, il nostro sito web dalle persone. È importantissimo spiegare questo obiettivo a tutte le persone con cui collaboriamo e non far vedere loro un pezzo del progetto.
Facciamo partecipare anche gli sviluppatori alle ricerche con gli utenti, o coinvolgiamoli subito raccontando quanto è emerso, prima di fare un report formale, solo così li faremo sentire veramente parte del progetto e non degli esecutori.
Ritorniamo perciò al concetto del dono. Cerchiamo di donare ogni giorno parte della nostra esperienza e delle nostre conoscenze alle persone con cui lavoriamo, solo così potremmo aspettarci che anche loro facciano lo stesso e si crei finalmente un clima di empatia laddove c’era, invece, una situazione difficile.
Comunicare con cura 