Content model e team di progetto: perché serve una lingua comune tra chi progetta, scrive, sviluppa e misura

Sette mestieri, sette dialetti

Pensa a come nasce un contenuto in un progetto web: lo stesso contenuto passa per sette mestieri.

• l’architettura dell’informazione decide che cosa è;
• la SEO organizza gli argomenti;
• il marketing definisce il pubblico;
• la strategia disegna il percorso;
• il copy scrive il messaggio;
• lo sviluppo lo implementa;
• l’analisi ne misura i risultati.

Dove si spezza

Nessuno lavora male: ognuno difende il suo pezzo, giustamente. Il problema nasce nei passaggi. Capita che piano editoriale, schema e argomenti vengano decisi in un reparto senza confrontarsi con chi ha definito le personas, o con chi scriverà i testi. Non per cattiva volontà: perché manca un posto dove quelle decisioni si incontrano, e una lingua per farle incontrare.

Il quadro per chi coordina

Se coordini un progetto, questo problema lo conosci anche se non lo chiami così. Lo vedi:

• nelle riunioni che servono a tradurre invece che a decidere;
• nelle rilavorazioni che arrivano tardi, a contenuto già pianificato;
• nelle stime che saltano, perché un’informazione ha cambiato significato passando da un team all’altro.

Il dizionario vivente sei tu

Spesso chi ricorda cosa intendeva ciascuno, e lo ripete al successivo, è proprio chi coordina. La mia ipotesi è che una lingua comune sposti questo lavoro dall’inseguimento alla prevenzione. Non è una promessa: non l’ho ancora vista funzionare in un progetto completo. È un ragionamento.

Cosa cambierebbe per chi coordina

Tre conseguenze, con il loro perché:

• Meno ambiguità: ogni parola ha un significato solo, deciso all’inizio. Nessuno deve più tradurre l’altro.
• Rilavorazioni scoperte prima: se si dichiara prima di scrivere a chi parla un contenuto, le incoerenze emergono nel brief, non a sito pubblicato.
• Stime più solide: una struttura che si ripete si può contare. Si stimano cose note, non nuove ogni volta.

Una parola, due significati

Me ne sono accorto mentre costruivo il plugin che oggi fa girare questo sito. Partivo da due progetti per due clienti, e in entrambi esisteva qualcosa che si chiamava Topic:

• nel primo voleva dire il pubblico;
• nel secondo, le business unit dell’azienda.

Stesso nome, due concetti

Finché ogni progetto restava sul suo sito, nessuno se ne accorgeva. Il giorno in cui dovevano diventare uno solo, la domanda è stata inevitabile: Topic, esattamente, che cos’è? Se succede tra due progetti seguiti dalla stessa persona, immagina tra sette mestieri.

Un dizionario, non un altro strumento

Non propongo un software in più, ma un dizionario minimo: quattro coordinate che descrivono ogni contenuto prima che venga prodotto.

• Che cosa è: un articolo, un servizio, una case history.
• Di cosa parla: l’argomento principale e i suoi legami.
• A chi parla: la persona per cui è pensato.
• In quale momento: perché esiste adesso, e cosa deve ottenere.

Rispondere insieme, una volta

Sono domande a cui ognuno, nel suo mestiere, sa già rispondere. La differenza è rispondere insieme, all’inizio. Poi ognuno usa le stesse risposte con i suoi strumenti: lo sviluppo nella struttura, la SEO nei dati strutturati, l’analisi nei report. Lo chiamo Bebop Content Model, ma il nome conta poco.

Le riunioni cambierebbero domanda

Oggi una buona parte di una riunione va a riallinearsi: cosa intendevi, a chi era rivolto, perché proprio adesso. Con un dizionario comune credo che la domanda cambierebbe:

• da «cosa intendevi?»
• a «è coerente con quello che abbiamo deciso?»

Non una riunione in meno, forse: una riunione che decide invece di tradurre.