Share
Ho avuto un'interessante conversazione con un amico di un amico lo scorso fine settimana, discutendo sulla necessità di strumenti di flusso di lavoro pre-CMS (classico lad barter). Più specificamente, detto amico-amico stava contestando l'idea di disaccoppiare i sistemi di gestione dei contenuti: avere piattaforme separate dal CMS editoriale che si focalizzano esclusivamente sui flussi di lavoro editoriali e di produzione. Credeva che tu potessi fare tutto questo lavoro direttamente nel CMS.
Mentre questo è un punto giusto (almeno tecnicamente), da allora sono stato tormentato dagli argomenti che avrei potuto esprimere contro questa idea di fare tutto nel CMS.
All'epoca, ho solo criticato l'esperienza utente generale di scrivere e gestire la produzione di contenuti in un CMS e ho borbottato l'analogia di Karen McGrane sulle macchine da stampa (sulla difficoltà di avere uno strumento che tenta di fare tutto).
Da allora mi sono reso conto che la mia risposta non ha assolutamente affrontato il problema più evidente del suo punto: implica che la produzione di contenuti non richiede un processo dedicato.
La cosa divertente di questa conversazione era che l'uomo in realtà lavorava presso una società di consulenza UX; un luogo in cui il processo è ovviamente un grande affare.
Nel contesto di ricerche di design estreme, test degli utenti e valutazione aziendale, sembra un po 'matto suggerire che tutto ciò che circonda la creazione di contenuti può essere fatto semplicemente nel CMS. Un ripensamento, o almeno qualcosa che può essere eseguito in un vuoto (molto generale).
E quella sarebbe la mia risposta più considerata all'uomo: suggerendo che lo sviluppo dei contenuti può essere fatto nel CMS, penso che corriamo il pericolo di assegnare il contenuto come un ripensamento; sottintendendo che non richiede realmente un processo dedicato e (più seriamente) che non deve essere considerato un componente del design o del lavoro di UX.
Ecco alcuni altri motivi concreti per evitare un approccio centrato sul CMS nello sviluppo di contenuti:
Il tempo impiegato per la produzione di contenuti è spesso sottovalutato. Questo è ovviamente più probabile quando la pianificazione della produzione non viene eseguita in anticipo (è impossibile stimare le ore per un lavoro non definito).
"Abbiamo finito il tuo sito web, stiamo solo aspettando il contenuto" - il ragazzo
Non riuscendo a valutare correttamente i requisiti dei contenuti all'inizio di un progetto, o ad evitare una governance intorno alla produzione dei contenuti, non puoi davvero lamentarti quando le stime sono distorte e il tuo progetto è in ritardo.
Un approccio popolare consiste nell'eseguire workshop di pianificazione dei contenuti (con persone sia del lato client che dell'agenzia del progetto) all'inizio di un progetto. Questi possono funzionare davvero bene per coinvolgere tutti nel processo di produzione dei contenuti ...
Come risultato di questi workshop (sessioni di terapia di gruppo), tutti vedranno anche quanto lavoro è richiesto e le stime saranno più accurate.
Può essere utile concentrare il workshop sulla definizione delle fasi di produzione necessarie per ottenere un tipo di contenuto specifico dalla bozza alla pubblicazione. Potresti quindi esaminare i vari cicli di ricerca, redazione e revisione relativi all'ottenere una "pagina degli eventi" pubblicata (e tenerla aggiornata!).
Una volta che hai completato il processo, puoi calcolare il tempo necessario per completare il processo e quindi moltiplicarlo per la quantità di pagine nel tuo progetto. Le persone possono piangere.
Un risultato ovvio delle stime fallite è il mancato funzionamento entro il budget. Un ripensamento costoso.
Una volta che hai terminato il tuo workshop, puoi orientare molto chiaramente la produzione del contenuto al tuo budget in un modo che il cliente capirà. Hai gettato le basi per il lavoro e portato alla luce la necessità di un investimento nella produzione di contenuti.
Giornata del maiale: i contenuti di buona qualità richiedono tempo per essere prodotti. Quando non è dato il tempo, ricerca, pianificazione e considerazione merita, il risultato sarà contenuto che non coinvolge le persone. Questo è abbastanza pericoloso.
La creazione di contenuti efficaci, in alcune situazioni, può sicuramente finire per essere più dispendiosa in termini di tempo e complessa (almeno in termini di gestione) rispetto alla creazione della tecnologia e del design visivo per un progetto di sito Web.
Sicuramente sostieni che i disegni visivi si ripetono più facilmente usando le librerie di modelli e le guide di stile, creando una serie di regole ripetibili. Ci sono anche standard molto chiari e aspettative da parte degli utenti in merito all'architettura dell'informazione e alla progettazione strutturale dei siti web. È molto più ovvio quando questa UI o progettazione strutturale è incoerente o non funziona (il contenuto è un mezzo molto 'denso' e 'ambiguo' da testare).
Datti tempo. E definire un processo.
Avendo un processo dedicato attorno al contenuto (prima del CMS), diventa molto più semplice includere gli strumenti per aiutarti a creare contenuti che funzionino.
Dovresti dedicare un po 'di tempo prima a creare una guida di stile per aiutare le persone a creare contenuti che soddisfino i criteri del tuo progetto. Questo può sembrare un po 'scoraggiante, ma ci sono molti esempi che puoi usare come modelli per crearne uno tuo.
Puoi anche utilizzare strumenti di modifica online collaborativi come Google Docs, Draft, Penflip o GatherContent per ospitare la produzione di contenuti in un luogo centrale; semplificando la gestione del processo e rafforzando la guida allo stile.
Abbastanza prevedibilmente, questo argomento ci riconduce all'idea di un approccio content-first al web design. L'intero concetto di contenuto viene lasciato fino a quando il CMS suggerisce un approccio molto contenuto-ultimo. Suggerisce che la ricerca e il design avvengono, quindi il CMS è costruito e quindi si tratta solo di riempire gli spazi vuoti con il contenuto.
Questo è piuttosto retorico: prendi semplicemente decisioni di design con una conoscenza (e basata sul) contenuto. Addio, lorem ipsum.
Ci sono molte risorse recenti su wireframing e prototipazione con contenuti reali (Typecast è uno strumento utile per aiutarti).
I prototipi funzionanti di TypecastAnche se non è la bozza finale, ha senso usare i contenuti reali nei wireframe e nei primi progetti; per vedere se la tua comunicazione funziona davvero, in modo olistico.
Quando la progettazione e il contenuto sono disconnessi, l'intera esperienza dell'utente è a rischio. Quando consideriamo l'esperienza di qualcuno che utilizza un sito Web, dovremmo essere molto informati (e testare) il contenuto che stanno consumando. Testare semplicemente il viaggio di qualcuno verso il contenuto non mette alla prova l'esperienza. È come analizzare il viaggio di qualcuno al cinema, ma non prendere in considerazione ciò che pensavano del film.
C'è una tendenza per i test di usabilità a trascurare i contenuti. Se stai facendo test degli utenti, dovresti coinvolgere compiti e domande attorno alle informazioni tratte dalla sessione di soggetti. Cosa hanno estratto dal contenuto? È quello che ti aspettavi? Qualcosa di importante non è chiaro? C'è qualcosa di troppo importante che non dovrebbe essere? In che modo ha influito sulla loro esperienza.
Anche se non stai facendo test formali sull'esperienza utente, si tratta davvero di riconoscere che il contenuto sarà sempre una componente importante dell'esperienza di qualcuno sul web.
Quando il contenuto non riesce a soddisfare le esigenze dei tuoi utenti, è improbabile che i tuoi obiettivi di business vengano soddisfatti.
E quando i tuoi obiettivi di business non sono raggiunti ...
questo rende il progetto un fallimento.
E nessuno lo vuole.
Nessuno (ben poche persone) crede davvero che il contenuto possa essere lasciato all'ultimo minuto. L'intera campagna "il contenuto è importante" è finita da molto tempo; e il valore del contenuto e del contenuto di lavoro, in primo luogo, è stato sicuramente accolto.
Ma, mentre potremmo essere d'accordo sul fatto che il contenuto è strategicamente importante ... sembra esserci ancora una mancanza di investimenti in un processo di produzione per la creazione di questo contenuto. Ripetendo le parole di Karen McGrane:
"Un cliente mi ha chiesto una volta 'Il CMS è più simile a una macchina da stampa o più come uno strumento per il flusso di lavoro per gestire tutti i nostri processi di pubblicazione?' Per molte organizzazioni, il vero dolore è con i processi di produzione che avvengono al di fuori del sistema di pubblicazione ". - Karen McGrane
Quando si parla di componenti progettuali e tecnologici dei progetti web, sembra esserci un insieme così avanzato di processi che supportano lo sviluppo (e l'iterazione) di soluzioni ben ponderate. Il contenuto non sembra esistere nella stessa luce.
La credenza nel documento Word e nella produzione di contenuti CMS sembra sottolineare il problema, ed è per questo che continuerei a sostenere l'esistenza di strumenti, processi e metodologie pratiche che incoraggiano la governance intorno alla produzione e al testing di contenuti ben ponderati. Al di fuori del CMS.
Hai un processo di produzione per i contenuti? Mi piacerebbe sentire i tuoi pensieri nei commenti.
Accentsconagua