Share
Jeg hadde en interessant samtale med en venn av en venn sist helg, og diskuterte behovet for arbeidsflytverktøy for pre-CMS-innhold Nærmere bestemt snakket vennevennen til ideen om å koble fra innholdsstyringssystemer: Å ha plattformer skilt fra publiserings-CMS som fokuserer bare på redaksjonelle og produksjonsprosesser. Han trodde du kunne gjøre alt dette arbeidet direkte i CMS.
Selv om dette er et rettferdig punkt (teknisk minst), har jeg siden blitt plaget med argumentene jeg kunne ha gitt mot denne ideen om å gjøre alt i CMS.
På den tiden kritiserte jeg bare den generelle brukeropplevelsen av å skrive og administrere innholdsproduksjon i et CMS, og mumlet Karen McGranes analogi om trykkpresser (om vanskelighetene med å ha et verktøy som forsøker å gjøre alt).
Jeg har siden innsett at svaret mitt helt ikke klarte å konfrontere det mest åpenbare problemet med hans poeng: det innebærer at innholdsproduksjon ikke krever en dedikert prosess.
Den morsomme tingen om denne samtalen var at mannen faktisk jobbet på en UX-konsulent; et sted hvor prosessen er åpenbart en stor avtale.
I sammenheng med ekstrem designforskning, brukertesting og bedriftsevaluering virker det litt galt å foreslå at alt som omgir opprettelsen av innhold, enkelt kan gjøres i CMS. En ettertanke, eller i det minste noe som kan utføres i et (veldig generelt) vakuum.
Og det ville være mitt mer ansett svar på mannen: at ved å foreslå innholdsutvikling kan gjøres i CMS, tror jeg at vi er i fare for å tilordne innhold som en ettertanke; noe som innebærer at det ikke egentlig krever en dedikert prosess og (mer seriøst) at den ikke skal betraktes som en komponent i design- eller UX-arbeidet.
Her er noen mer konkrete grunner for å unngå en CMS-sentrisk tilnærming til å utvikle innhold:
Tiden for innholdsproduksjon er ofte undervurdert. Dette er åpenbart mer sannsynlig når produksjonsplanleggingen ikke er gjort oppe (det er umulig å estimere timer for ubestemt arbeid).
"Vi har fullført nettstedet ditt, vi venter bare på innholdet" - fyren
Hvis du ikke vurderer innholdskravene riktig ved starten av et prosjekt, eller unngår styring rundt innholdsproduksjonen, kan du ikke klage når estimeringen er skjev og prosjektet ditt er forsinket..
En populær tilnærming er å kjøre innholdsplanleggingsverksteder (med personer fra både klienten og byråksiden av prosjektet) ved starten av et prosjekt. Disse kan fungere veldig bra for å få alle ombord med prosessen for å produsere innhold ...
Som et resultat av disse workshops (/ gruppe terapi økter), vil alle også se hvor mye arbeid er involvert og estimater vil være mer nøyaktige.
Det kan være fint å fokusere verkstedet på å definere produksjonsstadiene involvert i å få en bestemt innholdstype fra utkast til publisert. Så du kan se på de ulike undersøkelsene, utarbeide og gjennomgå syklusene som er involvert i å få en "eventside" publisert (og også holde den oppdatert!).
Når du har gått gjennom prosessen, kan du beregne tiden som er involvert for å fullføre prosessen, og deretter multiplisere dette med mengden sider i prosjektet. Folk kan gråte.
Et tydelig resultat av mislykkede estimater er en mangel på å arbeide innenfor budsjettet. En kostbar ettertanke.
Når du har gjort verkstedet ditt, kan du veldig klart bruke innholdet i produksjonen i budsjettet på en måte som kunden din vil forstå. Du har lagt ned bakken, og dukket opp behovet for en investering i innholdsproduksjon.
Ground-hog dag: god kvalitet innhold tar tid å produsere. Når den ikke er gitt tid, forskning, planlegging og vurdering det fortjener, utfallet vil være innhold som ikke klarer å engasjere folk. Det er ganske farlig.
Opprettelsen av effektivt innhold, i noen situasjoner, kan definitivt ende opp med å bli mer tidkrevende og komplisert (i forhold til ledelsen i det minste) enn opprettelsen av teknologien og den visuelle utformingen av et nettstedsprosjekt.
Du hevder definitivt at visuelle design lettere gjentas ved hjelp av mønsterbiblioteker og stilguider, og skaper et sett med repeterbare regler. Det er også meget klare standarder og brukerforventninger når det gjelder informasjonsarkitektur og strukturell utforming av nettsteder. Det er mye mer tydelig når dette brukergrensesnittet eller strukturelle design er inkonsekvent eller ikke fungerer (innholdet er et veldig tett og tvetydig medium for å teste).
Gi deg selv tid. Og definer en prosess.
Ved å ha en dedikert prosess rundt innhold (før CMS) blir det mye lettere å faktorere i verktøy for å hjelpe deg med å lage innhold som fungerer.
Du bør bruke litt tid på forhånd for å lage en stilguide for å hjelpe folk å lage innhold som oppfyller kriteriene for prosjektet ditt. Dette kan føles litt skremmende, men det er mange eksempler du kan bruke som maler for å lage din egen.
Du kan også bruke samarbeidende verktøy for redigering av Internett, for eksempel Google Dokumenter, Draft, Penflip eller GatherContent, for å være vert for innholdsproduksjonen din på et sentralt sted. noe som gjør det enklere å administrere prosessen og håndheve din stilguide.
Ganske forutsigbart, fører dette argumentet oss tilbake til ideen om en innholds-første tilnærming til webdesign. Hele innholdsbegrepet blir igjen til CMS foreslår en veldig innholds-siste tilnærming. Det antyder at forskningen og designen finner sted, da er CMS bygget ut, og så er det bare et spørsmål om å fylle ut blankene med innholdet.
Dette er ganske retorisk: du gjør bare designbeslutninger med kunnskap om (og basert på) innholdet. Farvel, lorem ipsum.
Det er mange nyere ressurser på wireframing og prototyping med ekte innhold (Typecast er et fint verktøy for å hjelpe deg med dette).
Typecasts fungerende prototyperSelv om det ikke er det endelige utkastet, er det bare fornuftig å bruke ekte innhold i wireframes og tidlig design; for å se om kommunikasjonen din egentlig virker, helhetlig.
Når design og innhold kobles fra, er hele brukeropplevelsen i fare. Når vi vurderer noens erfaring ved å bruke et nettsted, bør vi bli informert (og test) innholdet de bruker. Bare å teste en persons reise til innholdet, teste ikke virkelig opplevelsen. Det er som å analysere noens tur til kino, men ikke å vurdere hva de tenkte på filmen.
Det er en tendens til brukervennlighetstesting for å forsømme innhold. Hvis du gjør brukertesting, bør du involvere oppgaver og spørsmål rundt informasjonen som er tatt fra fagøkten. Hva hentet de fra innholdet? Er det det du forventet? Er noe viktig gjort uklart? Er noe for fremtredende som ikke burde være? Hvordan påvirket dette deres erfaring.
Selv om du ikke gjør formell brukeropplevelse testing, kommer det virkelig til å erkjenne at innholdet alltid kommer til å være en massiv komponent av en persons erfaring på nettet.
Når innholdet ikke oppfyller dine brukeres behov, er det usannsynlig at forretningsmålene dine blir oppfylt.
Og når dine forretningsmål ikke er oppfylt ...
Dette gjør prosjektet til en feil.
Og ingen vil det.
Ingen (vel veldig få folk) tror virkelig at innholdet kan overlates til siste øyeblikk. Hele "innholdet er viktig" kampanjen er bra siden over; og verdien av innhold, og av å jobbe innholdet-først har definitivt blitt omfavnet.
Men selv om vi kan være enige om at innholdet er strategisk viktig, synes det fortsatt å være mangel på investering i en produksjonsprosess for å skape dette innholdet. Gjenta ordene til Karen McGrane:
"Jeg hadde en klient spør meg en gang" Er CMS mer som en utskrift eller mer som et arbeidsflytverktøy for å administrere alle våre publiseringsprosesser? ' For mange organisasjoner er den virkelige smerten med produksjonsprosessene som skjer utenfor publiseringssystemet. " - Karen McGrane
Når det gjelder design og teknologi komponenter av web prosjekter, synes det å være så et avansert sett av prosesser som støtter utvikling (og iterasjon) av veloverveide løsninger. Innhold ser ikke ut til å eksistere i samme lys.
En tro på Word-dokument og CMS-innholdsproduksjon ser ut til å understreke problemet, og det er derfor jeg vil fortsette å argumentere for eksistensen av verktøy, prosesser og praktiske metoder som oppmuntrer til styring rundt produksjon og testing av godt vurdert innhold. Utenfor CMS.
Har du en produksjonsprosess for innhold? Jeg vil gjerne høre dine tanker i kommentarene.
Accentsconagua