Share
Am avut o conversație interesantă cu un prieten de-un-prieten în weekend-ul trecut, discutând despre necesitatea unor instrumente de flux de lucru pentru conținutul pre-CMS. Mai exact, prietenul prieten a declarat că contestă ideea decuplării sistemelor de gestionare a conținutului: având platforme separate de CMS-ul de publicare care se concentrează exclusiv pe fluxurile de lucru editoriale și de producție. El credea că puteți face toate aceste lucruri direct în CMS.
Deși acest lucru este un punct corect (cel puțin din punct de vedere tehnic), de atunci am fost afectat de argumentele pe care le-am putut da împotriva acestei idei de a face totul în CMS.
În acel moment, am criticat experiența generală a utilizatorilor de a scrie și a gestiona producția de conținut într-un CMS și mormăi analogia lui Karen McGrane despre prese de tipărire (despre dificultățile de a avea un instrument care încearcă să facă totul).
De atunci am realizat că răspunsul meu nu a reușit să se confrunte cu cea mai flagrantă problemă cu punctul său de vedere: implică faptul că producția de conținut nu necesită un proces dedicat.
Lucru amuzant în legătură cu această conversație a fost că omul a lucrat de fapt la o consultanță UX; un loc în care procesul este evident o afacere uriașă.
În contextul cercetării extreme a designului, al testării utilizatorilor și al evaluării afacerii, pare puțin cam supărat să sugerăm că tot ceea ce înconjoară crearea conținutului poate fi pur și simplu făcut în CMS. O gândire ulterioară sau cel puțin ceva care poate fi executat într-un vid (foarte general).
Și acesta ar fi răspunsul meu mult mai considerat la om: că sugerând că dezvoltarea conținutului poate fi făcută în CMS, cred că suntem în pericolul de a atribui conținutul ca o gândire ulterioară; ceea ce înseamnă că nu necesită într-adevăr un proces dedicat și (mai serios) că nu trebuie considerat o componentă a proiectului sau a lucrării UX.
Iată câteva motive mai tangibile pentru a evita o abordare centrată pe CMS în dezvoltarea conținutului:
Timpul necesar producției de conținut este deseori subestimat. Acest lucru este evident mai probabil atunci când planificarea producției nu este făcută în față (este imposibil să se estimeze orele pentru munca nedefinită).
"Am terminat site-ul dvs., așteptăm doar conținutul" - tipul
Dacă nu evaluezi în mod corespunzător cerințele privind conținutul la începutul unui proiect sau dacă eviți orice guvernare în jurul producției de conținut, nu te poți plânge când eșecurile sunt înclinate și proiectul tău este întârziat.
O abordare populară este de a organiza ateliere de planificare a conținutului (cu persoane atât din partea clientului, cât și din partea agenției proiectului) la începutul unui proiect. Acestea pot funcționa foarte bine pentru a face pe toată lumea la bord cu procesul de producere a conținutului ...
Ca urmare a acestor ateliere (/ sesiuni de terapie de grup), toată lumea va vedea, de asemenea, cât de mult este implicată munca și estimările vor fi mai exacte.
Poate fi bine să vă concentrați atelierul asupra definirii etapelor de producție implicate în obținerea unui anumit tip de conținut de la proiect la publicat. Așadar, puteți privi diferitele cicluri de cercetare, redactare și revizuire implicate în publicarea unei pagini de evenimente (și, de asemenea, să o actualizați!).
Odată ce ați parcurs procesul, puteți calcula timpul implicat pentru finalizarea procesului, apoi multiplicați acest lucru cu numărul de pagini din proiect. Oamenii pot plânge.
Un rezultat evident al estimărilor eșuate constă în incapacitatea de a lucra în cadrul bugetului. O gândire scumpă.
Odată ce ați terminat atelierul dvs., puteți obține în mod clar conținut de conținut în bugetul dvs. într-un mod pe care clientul dvs. îl va înțelege. Ați stabilit munca la sol și ați scos în evidență necesitatea unei investiții în producția de conținut.
Ziua la pământ: conținutul de bună calitate necesită timp pentru a produce. Când nu i se dă timp, cercetare, planificare și considerație merită, rezultatul va fi conținut care nu reușește să angajeze oameni. E destul de periculos.
Crearea unui conținut eficient, în anumite situații, poate fi cu siguranță mai mult consumator de timp și mai complex (cel puțin în ceea ce privește managementul) decât crearea tehnologiei și designul vizual al unui proiect de site web.
Cu siguranta argumentati ca desenele vizuale sunt repetate mai usor folosind biblioteci de modele si ghiduri de stil, creand un set de reguli repetabile. Există, de asemenea, standarde foarte clare și așteptări ale utilizatorilor în ceea ce privește arhitectura informațională și designul structural al site-urilor web. Este mult mai evident atunci când acest UI sau design structural este inconsistent sau nu funcționează (conținutul este un mediu foarte "dens" și "ambiguu" pentru a testa).
Dă-ți timp. Și definiți un proces.
Prin faptul că aveți un proces special dedicat conținutului (înainte de CMS), devine mult mai ușor să factorizați în instrumente pentru a vă ajuta să creați conținut care funcționează.
Ar trebui să dedicați un timp în avans pentru a crea un ghid de stil pentru a ajuta oamenii să creeze conținut care să îndeplinească criteriile proiectului. Acest lucru se poate simți puțin cam descurajant, dar există o mulțime de exemple pe care le puteți utiliza ca șabloane pentru a crea propriile dvs..
De asemenea, puteți utiliza instrumente de editare online, cum ar fi Google Docs, Draft, Penflip sau GatherContent, pentru a găzdui producția dvs. de conținut într-un loc central; simplificându-vă gestionarea procesului și aplicând ghidul de stil.
În mod destul de previzibil, acest argument ne conduce înapoi la ideea unei abordări bazate pe conținut în primul rând asupra designului web. Întregul concept de conținut rămânând până când CMS sugerează o foarte mare conținut - ultima abordare. Acesta sugerează că cercetarea și designul au loc, apoi CMS-ul este construit, și apoi este doar o chestiune de completare a golurilor cu conținutul.
Acest lucru este destul de retoric: pur și simplu faceți deciziile de proiectare cu o cunoaștere a (și pe baza) conținutului. Adio, lorem ipsum.
Există o mulțime de resurse recente pe sincronizare și prototipuri cu conținut real (Typecast este un instrument frumos pentru a ajuta cu asta).
Protocoalele de lucru ale lui TypecastChiar dacă nu este proiectul final, este pur și simplu logic să folosiți conținut real în schemele dvs. wireframes și design-urile timpurii; pentru a vedea dacă comunicarea ta funcționează, în mod holistic.
Când designul și conținutul sunt deconectate, întreaga experiență a utilizatorului este în pericol. Când analizăm experiența cuiva folosind un site web, ar trebui să fim foarte informați (și testați) conținutul pe care îl consumă. Pur și simplu testarea călătoriei cuiva către conținut nu testează cu adevărat experiența. Este ca și cum ați analiza călătoria cuiva în cinematografie, dar nu ați luat în considerare ce credeau despre film.
Există o tendință de testare a utilizabilității pentru a neglija conținutul. Dacă faceți teste de utilizator, trebuie să implicați sarcini și întrebări în jurul informațiilor preluate din sesiunea de subiecte. Ce au extras din conținut? Ați așteptat asta? Este important ceva neclar? Este ceva prea proeminent care nu ar trebui să fie? Cum a afectat aceasta experiența lor.
Chiar dacă nu faceți o testare formală a experienței utilizatorilor, se ajunge cu adevărat la recunoașterea faptului că conținutul va fi întotdeauna o componentă masivă a experienței unui utilizator pe web.
Atunci când conținutul nu reușește să răspundă nevoilor utilizatorilor dvs., este puțin probabil ca obiectivele dvs. de afaceri să fie îndeplinite.
Și când obiectivele dvs. de afaceri nu sunt îndeplinite ...
acest lucru face ca proiectul să fie eșuat.
Și nimeni nu vrea asta.
Nimeni (foarte puțini oameni) crede cu adevărat că conținutul poate fi lăsat în ultimul moment. Întreaga campanie "de conținut este importantă" este bine de atunci; și valoarea conținutului și a conținutului de lucru - mai întâi a fost cu siguranță îmbrățișată.
Dar, deși am putea fi de acord că conținutul este de o importanță strategică ... există încă o lipsă de investiții într-un proces de producție pentru crearea acestui conținut. Repetarea cuvintelor lui Karen McGrane:
"Am avut un client să mă întrebi odată" Este CMS mai mult ca o imprimantă sau mai mult ca un instrument de flux de lucru pentru a gestiona toate procesele noastre de publicare? " Pentru multe organizații, durerea reală este legată de procesele de producție care se produc în afara sistemului de publicare. " - Karen McGrane
Când vine vorba de proiectarea și componentele tehnologice ale proiectelor web, se pare că există un set atât de avansat de procese care susțin dezvoltarea (și repetarea) unor soluții bine gândite. Conținutul nu pare a exista în aceeași lumină.
Credința în documentul Word și producția de conținut CMS pare să sublinieze problema și de aceea aș continua să susțin existența unor instrumente, procese și metodologii practice care să încurajeze guvernarea în jurul producției și testării unui conținut bine gândit. În afara CMS.
Aveți un proces de producție pentru conținut? Mi-ar plăcea să vă aud gândurile în comentarii.
Accentsconagua