per una nuova cultura della comunicazione
 

 
   

 

Problem solving strategico e technical writing: come mettersi nei panni dell'utente e parlare il suo linguaggio
di Umberto Santucci

Diceva un mio amico che i manuali tecnici di un prodotto, di un apparecchio, di un software, sembrano spesso scritti dalla concorrenza per renderne impossibile l'uso.
Donald Norman sarebbe ancor più radicale, perché direbbe che se apparecchi e applicativi fossero disegnati bene non ci sarebbe neanche bisogno di istruzioni.
Tra due prodotti a parità di prezzo e funzionalità, vince il prodotto con l'interfaccia più comprensibile e la documentazione migliore.
Il problem solving strategico, sviluppatosi in ambito psicoterapeutico, ha fornito tecniche e metodi per risolvere problemi, raggiungere obiettivi, realizzare cambiamenti migliorativi nei comportamenti normali, nei rapporti capo/collaboratore, nelle organizzazioni e aziende, nella comunicazione.
Il testo più famoso è "Pragmatica della comunicazione umana" di Watzlawick, Beavin, Jackson, del MRI (Mental Research Institute) di Palo Alto. In Italia il MRI è rappresentato dalla Scuola di Problem Solving Strategico di Arezzo di Giorgio Nardone, che svolge da molti anni attività clinica e consulenziali.
Il redattore tecnico spesso parla con il linguaggio degli ingegneri o del produttore o del marketing, più che con quello dell'utente. Come fare a cambiare punto di vista, e a cambiare linguaggio? Il problem solving strategico propone tecniche di ascolto, di osservazione, di ricalco, di riformulazione, di combinazione fra linguaggio che parla alla parte sinistra del cervello e linguaggio che parla alla parte destra. Il tutto per ottenere una comunicazione più efficace e orientata al destinatario.

Chi è e che cosa fa un technical writer?
Il technical writer, o redattore tecnico, è il "ponte" tra progettisti e utilizzatori di un prodotto o di un servizio, dall’alta alla bassa tecnologia.
Produce il libretto di istruzioni per un elettrodomestico, la guida alla manutenzione di una macchina, il manuale utente di un programma software, il manuale API per gli sviluppatori, la quick reference guide per avviare e usare immediatamente la stampante, l'help online contestuale all'applicazione, la newsletter che informa sulle novità del prodotto, i contenuti del sito per la presentazione delle novità della release software.
Si occupa di prodotti editoriali come brochure, presentazioni, cataloghi, articoli, materiale fieristico, schede prodotto, case study, pagine pubblicitarie, fino ad arrivare al naming e alla copy strategy del prodotto.
Gestisce i contenuti di siti web e di prodotti multimediali.
Il redattore tecnico ha a che fare con i dirigenti dell’azienda, con i direttori commerciali, di marketing, del personale, con gli ingegneri e i tecnici che hanno progettato e costruito il prodotto, con i collaudatori, le forze di vendita, gli utenti finali, i manutentori, i media.

Cambio del punto di vista
Proprio perché ha a che fare con queste persone così diverse per competenze tecniche, per interessi, per livello culturale e sociale, il redattore tecnico deve essere capace di ascoltare, di comprendere, di riformulare, di spiegare, di persuadere.
Deve sapersi spostare da un punto di vista all’altro, perché non esiste un punto di vista migliore degli altri, e perché lo stesso problema si presenta in modo del tutto diverso se si cambia il punto di vista.
Per esempio, quando si parla con un responsabile della produzione, egli tende spesso a descrivere il "che cos'è" e il "come è fatto" invece del "cosa serve", e del "quando si usa" e del "cosa fare se"... Esattamente ciò che invece interessa a chi lo comprerà.
E’ molto difficile assumere il punto di vista dell’amministratore delegato, del progettista, del marketing manager, del rivenditore, dell’utente evoluto, dell’utente medio/basso. Spetta proprio al technical writer fare da interprete fra un punto di vista e l’altro.
Uno degli esercizi che deve affrontare un consulente di problem solving strategico è la capacità di considerare un problema almeno da cinque punti di vista diversi. Ci si basa sul fatto che non esistono teorie forti, principi incrollabili, realtà oggettive. La realtà è costruita da ognuno di noi, secondo il proprio punto di vista.
Per un programmatore sarà molto importante riscrivere un codice in modo elegante. Per un responsabile del marketing l’eleganza del codice è irrilevante, l’unica cosa che conta è il time to market, la rapidità con cui si riesce a mettere il nuovo prodotto sul mercato. Per un grafico sarà importante l’eleganza di un carattere e lo stile di una pagina, per un ergonomo sarà importante solo la leggibilità, l’accessibilità, l’usabilità della pagina.

Mappe cognitive
Ognuno di noi si costruisce una sua mappa cognitiva di un certo argomento. Se la mia mappa ha qualche somiglianza con quella del mio interlocutore, è possibile che ci capiamo. Se le mappe sono diverse non ci capiremo mai.
Per alcuni la mappa cognitiva della vacanza prevede stare sdraiati senza far nulla. Per altri prevede fare attività fisica fino a sentirsi stanchi. Le cose che impegnano e fanno stancare saranno evitate dal primo e ricercate dal secondo, per le stesse caratteristiche intrinseche.
La mappa cognitiva di un ingegnere elettronico è fatalmente diversa da quella di un giurista, che ha solo bisogno di un buon data base per accedere alla giurisprudenza nel modo più rapido.
E’ il technical writer che deve cercare di interpretare le diverse mappe cognitive, e deve trovare i punti di somiglianza in modo da stabilire una base di comprensione. Oppure deve trasformare la mappa cognitiva di un ingegnere in quella di un utente medio.

Ricalco linguistico e comunicativo
Dice il saggio cinese che si può parlare di poesia solo al poeta, di spada solo al maestro di scherma.
Il redattore tecnico cercherà di parlare il linguaggio del suo destinatario. Se prepara un testo per un tecnico, un rivenditore specializzato, un esperto del settore, potrà usare un linguaggio adeguato al livello di quelle persone. Un linguaggio troppo divulgativo e semplificato potrebbe essere ritenuto banalizzante, e risultare sgradito.
Se invece prepara un manuale d’uso, un tutorial, un comunicato stampa per un giornale di massa, deve usare un linguaggio piano, comune, esente da tecnicismi.

Tecnica delle domande – briefing e definizione del problema
Il problem solving strategico pone molta cura nella tecnica delle domande.
Le domande devono essere strategiche, ovvero devono avere uno scopo, devono servire a raccogliere determinate informazioni.
La tecnica principale è la domanda ad alternative, allo scopo di eliminare la parte che non serve, e di condurre l’interlocutore a dirci quello che ci interessa sapere.
Una domanda aperta non è strategica, perché spinge l’interlocutore a dilagare nella risposta, a divagare, a presentare in modo confuso elementi essenziali e marginali.
Per esempio, se chiedo all’ingegnere progettista di spiegarmi il suo prodotto, mi dirà tante cose che non mi interessano. Se invece gli chied “l’utente installa il prodotto da solo o ha bisogno di un tecnico?” gli pongo un’alternativa essenziale. Nel primo caso devo preparare le istruzioni per l’utente finale, nel secondo devo rivolgermi al tecnico.
Dopo aver fatto due o tre domande posso riformulare ciò che mi ha detto il mio interlocutore, per mostrargli di averlo ascoltato e compreso, o per verificare se ho capito male qualcosa. La riformulazione viene fatta così: “Se ho capito bene, ma correggimi se sbaglio, mi stai dicendo che questo prodotto può essere installato solo da un tecnico, e che il tecnico dovete mandarlo voi”.
Dopo aver fatto una serie di domande e di riformulazioni, si arriva alla corretta definizione del problema di comunicazione, o dell’obiettivo da perseguire. “Dobbiamo fare un manuale di installazione per un tecnico specializzato, che gli serva durante l’installazione presso il cliente, che abbia una scheda riassuntiva su una sola pagina, che funzioni anche on line”.
Una volta definiti bene gli obiettivi si può procedere in modo strategico.
Il processo strategico infatti consiste nel muoversi in una direzione ben definita, non in modo confuso e contraddittorio.

Tentate soluzioni – testi precedenti
Nel modello strategico, se c’è un problema da risolvere o un obiettivo da raggiungere, vuol dire che tutto quello che si è fatto finora non è servito a risolvere il problema o a raggiungere l’obiettivo.
Perciò è importante analizzare che cosa si è fatto, per vedere se ha funzionato o no, e per capire dove e come non ha funzionato.
Ciò serve a cambiare il modo di comportarsi, a non insistere negli stessi errori, a non fare sempre di più quello che finora non ha funzionato bene.
Nel caso di un problema di redazione di testi, le tentate soluzioni che non hanno funzionato sono le modalità comunicative e i testi precedenti. Un test può essere il tipo di domande FAQ. Se certe domande ricorrono, evidentemente la cosa non è stata spiegata bene.

Visualizzazione, metafore, ricodifica (linguaggio analogico)
Come ha insegnato Watzlawick, ci sono due tipi di linguaggio, il digitale e l’analogico. Il primo comunica con l’emisfero sinistro del cervello e con la coscienza, e usa lettere dell’alfabeto, numeri, costruzioni grammaticali e sintattiche. Il secondo comunica con l’emisfero destro e con l’inconscio, e usa immagini, metafore, similitudini, toni di voce suasivi, suggestioni evocative.
Il technical writer dovrà saper usare ambedue i linguaggi. Se si rivolge ad esperti, a professionisti, a tecnici, a power users, userà il linguaggio digitale e razionale, cercherà di essere essenziale, preciso, chiaro.
Se si rivolge ad un pubblico meno esperto, dovrà ricorrere ad un linguaggio più suggestivo, a visualizzazioni, a metafore, a ricodifiche nel linguaggio del destinatario.
La stessa progettazione di interfacce per software applicativi si basa su linguaggi analogici. Il cestino per buttare materiali con la possibilità di recuperarli, la freccetta del mouse che infila gli oggetti e li sposta da una parte all’altra del monitor, le icone con le forbici per tagliare via una parte del materiale che vogliamo eliminare, o con la stampante per stampare il nostro documento, sono tutte comunicazioni analogiche.
Certi effetti sonori, o finestre che appaiono improvvise, fanno appello alla nostra emotività per spingerci a fare qualcosa per evitare inconvenienti.
Tuttavia i messaggi analogici spesso hanno un alto livello di ambiguità. Le interfacce grafiche hanno preso atto del problema, perché in rollover sull’icona fanno apparire una didascalia verbale che spiega a che cosa serve quell’icona.
Quindi la comunicazione più efficace combina linguaggi analogici (suggestione) e digitali (precisione).

Verifica
Una volta concluso l’intervento di comunicazione, ne va verificata l’efficacia.
E’ stato compreso? L’obiettivo è stato raggiunto?
Proprio perché il problem solving strategico non si basa su teorie forti e su pregiudizi, ha bisogno di andare a vedere se in pratica tutto ha funzionato secondo i desideri.
Se ha funzionato si continua così, altrimenti si cambia.

Umberto Santucci
www.umbertosantucci.it

Centro di terapia strategica
www.problemsolvingstrategico.it

http://www.mestierediscrivere.com/testi/technicalwriting.htm
intervista di Luisa Carrada a Vilma Zamboli, presidente di Society for Technical Communication, Transalpine Charter. Da questa intervista ho tratto le definizioni del mestiere di technical writer, che ho inserito all’inizio di questo articolo.
http://www.stc-transalpine.org/tac/
http://www.writec.com Il gruppo di Vilma Zamboli
http://www.mestierediscrivere.com/testi/articolotecnico.htm Come fare un articolo tecnico, di Alberto Falossi
http://www.bazzoli.it/ita/pHcostit.htm Una società che produce articoli, manuali e disegni tecnici
http://www.fcomolli.it/index.html Il sito di Fabrizio Comolli, esperto di ergonomia e traduttore di Home Page, il famoso libro di Jacob Nielsen
http://www.cs.unibo.it/~etl95/tonfoni/
Una pagina su Graziella Tonfoni, esperta di scrittura multimediale
Alessandro Lucchini, Business writing. Scrivere nell'era di Internet, Sperling & Kupfer, 2001.

 

home | chi siamo | rivista | libri | corsi | archivio | blog | scrivici

 

© Copyright 2005 Comunico sas - Tutti i diritti riservati Web hosting e web design by Graffiti2000.com