Premesse
Il manuale utente in PDF, scritto una volta al rilascio di una versione e mai più realmente aggiornato, è uno dei documenti aziendali con il tasso di consultazione più basso che conosca. Non perché le persone non ne abbiano bisogno, ma perché nel momento in cui serve davvero – un dubbio operativo mentre si sta usando una funzione specifica – nessuno ha voglia di interrompere il proprio lavoro per cercare in un file separato di centinaia di pagine.
La domanda tecnica interessante è: come si costruisce una guida che le persone consultano davvero, nel momento in cui gli serve, senza uscire dal contesto in cui si trovano?
Come funziona un pannello di aiuto che mostra sempre il contenuto pertinente al contesto in cui si trova l’utente?
Il meccanismo si basa su un collegamento esplicito tra ogni voce di menu o funzione dell’applicazione e il contenuto di guida che la riguarda, mantenuto come parte della configurazione del sistema, non come un’associazione statica scritta a mano una volta per tutte.
Quando l’utente naviga verso una determinata schermata, il pannello di aiuto – tipicamente un elemento persistente attivabile con un’icona sempre visibile – interroga questo collegamento e mostra automaticamente il contenuto pertinente a quel livello di menu o a quel compito specifico, seguendo l’ultima interazione dell’utente invece di richiedere una ricerca manuale ogni volta.
Questo approccio richiede che la struttura della guida rispecchi, almeno in parte, la struttura di navigazione dell’applicazione stessa: un contenuto per ogni funzione principale, organizzato gerarchicamente in modo coerente con i livelli di menu, così che l’associazione tra “dove sono” e “cosa mi serve sapere” resti sempre esplicita e mai lasciata a una ricerca testuale generica come unica via d’accesso.
Perché un editor WYSIWYG che salva contenuto in Markdown è una scelta tecnica sensata per chi scrive la documentazione?
Chi scrive la documentazione operativa di un sistema FM raramente è uno sviluppatore: è più spesso un formatore interno, un responsabile di prodotto, un consulente che conosce bene il dominio applicativo ma non necessariamente la sintassi di markup.
Un editor WYSIWYG (what you see is what you get) permette di scrivere e formattare il contenuto – titoli, elenchi, immagini ridimensionabili direttamente nell’editor, link interni verso altri argomenti della guida – con un’esperienza simile a un elaboratore di testi comune, mentre sotto il cofano il contenuto viene salvato in un formato testuale semplice come il Markdown.
Questa scelta tecnica non è casuale: il Markdown resta leggero, versionabile e facilmente esportabile o migrabile verso altri strumenti, evitando il lock-in tipico di un formato proprietario di editing, coerentemente con il principio di apertura di cui ho parlato più volte in questa serie. Un contenuto scritto in Markdown, inoltre, si presta naturalmente a essere indicizzato per la ricerca full-text, un requisito che vedremo tra poco.
Come si gestisce un contenuto di guida multilingua che resti sempre completo anche quando una traduzione manca?
Un’organizzazione internazionale, o anche solo con personale di provenienza diversa, ha bisogno che la guida sia disponibile in più lingue – un sistema maturo può coprire nativamente un numero significativo di lingue, tipicamente attorno a sette per coprire i contesti più comuni in ambito europeo e internazionale.
La sfida tecnica non è tanto memorizzare più traduzioni per ogni contenuto, quanto gestire con eleganza il caso, frequente nella pratica, in cui una traduzione specifica non è ancora stata prodotta: un meccanismo di fallback automatico dovrebbe mostrare la versione disponibile in un’altra lingua di riferimento invece di lasciare un vuoto o un errore, così che la copertura documentale resti sempre completa anche mentre le traduzioni vengono aggiunte progressivamente nel tempo.
Che valore ha questo approccio per la ditta esterna che deve formare rapidamente nuovi tecnici su un sistema che non conoscono?
Un global service che assume o assegna un nuovo tecnico a una commessa ha bisogno di un percorso di formazione rapido: un aiuto contestuale, sempre presente nell’interfaccia stessa, riduce drasticamente il tempo necessario perché un nuovo arrivato diventi autonomo, rispetto a un manuale separato che nessuno legge per intero prima di iniziare a lavorare. È un vantaggio che si misura direttamente in produttività nelle prime settimane di ogni nuovo inserimento, un costo che altrimenti ricadrebbe interamente sull’esperienza diretta e sugli errori commessi lungo il percorso.
Perché questo riduce anche il carico sul proprietario e sul building manager come “formatori informali” del sistema?
In molte organizzazioni, la formazione sul nuovo software finisce per gravare informalmente su chi lo conosce meglio – spesso il building manager stesso – che si ritrova a rispondere alle stesse domande operative più e più volte, sottraendo tempo al proprio lavoro. Una guida contestuale ben progettata, che risponde direttamente a queste domande nel momento in cui sorgono, riduce questo carico informale, lasciando al building manager il tempo per le questioni realmente specifiche della propria organizzazione, invece delle domande generiche su come funziona una funzione dell’interfaccia.
Conclusioni
Una guida che vive dentro l’interfaccia, contestuale, multilingua con fallback automatico, scritta con strumenti accessibili a chi non è uno sviluppatore, e mantenuta sincronizzata con l’evoluzione del prodotto anche nel materiale visivo, riduce l’onboarding da un progetto formativo separato a un’esperienza integrata nel lavoro quotidiano.
Con questo si chiude il capitolo dedicato a documenti e conoscenza: nei prossimi articoli affrontiamo un tema che nessuna organizzazione FM può più permettersi di trattare superficialmente: la sicurezza applicativa e la conformità alla Privacy (GDPR).
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui