Share
Ik had afgelopen weekend een interessant gesprek met een vriend van een vriend, waarin ik de behoefte aan pre-CMS content-workflowtools besprak (classic lad banter). Meer specifiek betwist deze vriend van vriend het idee om content management systemen te ontkoppelen: het hebben van platforms los van het publishing CMS dat zich puur richt op redactionele en productiewerkstromen. Hij geloofde dat je al dit werk rechtstreeks in het CMS kon doen.
Hoewel dit een redelijk punt is (technisch tenminste), ben ik sindsdien geplaagd door de argumenten die ik had kunnen geven tegen dit idee om alles in het CMS te doen.
In die tijd bekritiseerde ik de algemene gebruikerservaring van het schrijven en beheren van de inhoudsproductie in een CMS en mompelde de vergelijking van Karen McGrane over drukpersen (over de moeilijkheden van het hebben van één tool die alles probeert te doen).
Ik heb me sindsdien gerealiseerd dat mijn antwoord het meest flagrante probleem niet met zijn punt kon confronteren: het impliceert dat de productie van inhoud geen specifiek proces vereist.
Het grappige van dit gesprek was dat de man daadwerkelijk bij een UX-adviesbureau werkte; een plek waar het proces vanzelfsprekend een groot probleem is.
In de context van extreem ontwerponderzoek, gebruikerstests en bedrijfsevaluatie lijkt het een beetje gek om te suggereren dat alles rond het creëren van inhoud eenvoudig in het CMS kan worden gedaan. Een bijzaak, of op zijn minst iets dat kan worden uitgevoerd in een (zeer algemeen) vacuüm.
En dat zou mijn meer overwogen antwoord op de man zijn: dat door inhoudelijke ontwikkeling in het CMS te suggereren, ik denk dat we het gevaar lopen om inhoud als een bijzaak toe te kennen; wat impliceert dat het niet echt een specifiek proces vereist en (ernstiger) dat het niet als een onderdeel van het ontwerp of UX-werk moet worden beschouwd.
Hier zijn een paar meer tastbare redenen om een CMS-gerichte benadering voor het ontwikkelen van inhoud te vermijden:
De tijd die nodig is voor de productie van inhoud wordt vaak onderschat. Dit is uiteraard waarschijnlijker wanneer de productieplanning niet vooraf wordt gedaan (het is onmogelijk om uren in te schatten voor ongedefinieerd werk).
"We zijn klaar met uw website, we wachten gewoon op de inhoud" - de man
Als u de inhoudvereisten aan het begin van een project niet goed evalueert of als u geen beheer rond uw inhoudsproductie gebruikt, kunt u niet echt klagen wanneer schattingen scheef staan en uw project wordt vertraagd.
Een populaire aanpak is om workshops over inhoudsplanning (met mensen van zowel de klant als de agentkant van het project) aan het begin van een project uit te voeren. Deze kunnen heel goed werken om iedereen aan boord te krijgen met het proces voor het produceren van inhoud ...
Als resultaat van deze workshops (/ groepstherapiesessies), zal iedereen ook zien hoeveel werk eraan is verbonden en zullen schattingen nauwkeuriger zijn.
Het kan leuk zijn om de workshop te concentreren op het definiëren van de productiefasen die betrokken zijn bij het verkrijgen van een specifiek inhoudstype van concept tot gepubliceerd. U kunt dus kijken naar de verschillende cycli voor onderzoek, opstellen en beoordelen die zijn betrokken bij het publiceren van een 'evenementenpagina' (en deze ook up-to-date houden!).
Nadat u het proces hebt doorlopen, kunt u de benodigde tijd berekenen om het proces te voltooien en dit vervolgens vermenigvuldigen met het aantal pagina's in uw project. Mensen kunnen huilen.
Een voor de hand liggende uitkomst van mislukte schattingen is een gebrek aan werk binnen het budget. Een dure bijzaak.
Zodra u uw workshop heeft voltooid, kunt u de inhoudsproductie heel duidelijk in uw budget opnemen op een manier die uw klant zal begrijpen. U hebt het grondwerk vastgelegd en de noodzaak van een investering in de productie van inhoud aan het licht gebracht.
Ground-hog day: inhoud van goede kwaliteit kost tijd om te produceren. Wanneer het de tijd, onderzoek, planning en overweging het verdient, de uitkomst zal inhoud zijn die er niet in slaagt om mensen te betrekken. Dat is behoorlijk gevaarlijk.
Het creëren van effectieve inhoud, in sommige situaties, kan zeker uiteindelijk meer tijdrovend en complex (in termen van management in ieder geval) zijn dan de creatie van de technologie en het visuele ontwerp voor een website-project..
U beweert zeker dat visuele ontwerpen gemakkelijker kunnen worden herhaald met behulp van patroonbibliotheken en stijlgidsen, waardoor een reeks herhaalbare regels wordt gecreëerd. Er zijn ook zeer duidelijke normen en gebruikersverwachtingen als het gaat om informatiearchitectuur en het structurele ontwerp van websites. Het is veel duidelijker wanneer deze gebruikersinterface of het structurele ontwerp niet consistent is of niet werkt (inhoud is een zeer 'dicht' en 'dubbelzinnig' medium om te testen).
Geef jezelf tijd. En definieer een proces.
Door een specifiek proces rond inhoud (vóór het CMS) te houden, wordt het veel gemakkelijker om hulpmiddelen te gebruiken om u te helpen inhoud te maken die werkt.
U moet van tevoren enige tijd wijden aan het maken van een stijlgids om mensen te helpen inhoud te maken die voldoet aan de criteria van uw project. Dit kan een beetje ontmoedigend zijn, maar er zijn genoeg voorbeelden die u kunt gebruiken als sjablonen om uw eigen sjablonen te maken.
U kunt ook collaboratieve online bewerkingstools zoals Google Docs, Draft, Penflip of GatherContent gebruiken om uw contentproductie op een centrale plaats te hosten; het gemakkelijker maken om uw proces te beheren en uw stijlgids op te leggen.
Zeer voorspelbaar, dit argument leidt ons terug naar het idee van een inhoud-eerste benadering van webdesign. Het hele concept van inhoud dat wordt overgelaten tot het CMS suggereert een zeer veel inhoud-laatste benadering. Het suggereert dat het onderzoek en ontwerp plaatsvinden, dan is het CMS opgebouwd, en dan is het gewoon een kwestie van invullen van de lege plekken met de inhoud.
Deze is nogal retorisch: je neemt eenvoudig ontwerpbeslissingen met een kennis van (en op basis van) de inhoud. Tot ziens, Lorem ipsum.
Er zijn veel recente bronnen over wireframing en prototyping met echte inhoud (Typecast is een leuke tool om mee te helpen).
De werkende prototypes van TypecastZelfs als het niet de definitieve versie is, is het alleen zinvol om echte inhoud te gebruiken in uw wireframes en vroege ontwerpen; om te zien of uw communicatie echt werkt, holistisch.
Wanneer ontwerp en inhoud worden losgekoppeld, loopt de hele gebruikerservaring gevaar. Wanneer we iemands ervaring met het gebruik van een website overdenken, moeten we goed worden geïnformeerd (en de inhoud testen die ze gebruiken). Alleen al het testen van iemands reis naar de inhoud test de ervaring niet echt. Het is alsof je iemands reis naar de bioscoop analyseert, maar niet nadenkt over wat ze van de film vonden.
Er is een tendens voor het testen van bruikbaarheid om inhoud te verwaarlozen. Als u gebruikerstests uitvoert, moet u taken en vragen in verband met de informatie uit de onderwerpen-sessie betrekken. Wat hebben ze uit de inhoud gehaald? Is dat wat je verwachtte? Is er iets belangrijks onduidelijk gemaakt? Is iets te prominent dat niet zou moeten zijn? Hoe heeft dit hun ervaring beïnvloed?.
Zelfs als je geen formele gebruikerservaringstests uitvoert, komt het er echt op aan te erkennen dat inhoud altijd een enorm onderdeel van iemands ervaring op het web gaat worden.
Wanneer de inhoud niet voldoet aan de behoeften van uw gebruikers, is het onwaarschijnlijk dat uw bedrijfsdoelstellingen worden behaald.
En wanneer uw bedrijfsdoelstellingen niet worden behaald ...
dit maakt het project een mislukking.
En niemand wil dat.
Niemand (heel weinig mensen) gelooft echt dat inhoud op het laatste moment kan worden overgelaten. De hele campagne "Inhoud is belangrijk" is goed sindsdien; en de waarde van inhoud en werkinhoud - eerst is zeker omarmd.
Maar hoewel we het ermee eens kunnen zijn dat inhoud strategisch belangrijk is, lijkt er nog steeds een gebrek aan investeringen te zijn in een productieproces om deze inhoud te maken. Herhaling van de woorden van Karen McGrane:
"Ik vroeg een klant ooit om een vraag" Is het CMS meer een drukpers of meer een workflow-tool om al onze publicatieprocessen te beheren? " Voor veel organisaties ligt de echte pijn bij de productieprocessen die buiten het publicatiesysteem plaatsvinden. " - Karen McGrane
Als het gaat om de ontwerp- en technologiecomponenten van webprojecten, lijkt er zo'n geavanceerde reeks processen te zijn die de ontwikkeling (en iteratie) van doordachte oplossingen ondersteunen. Inhoud lijkt niet in hetzelfde licht te bestaan.
Een overtuiging in Word-document en CMS-contentproductie lijkt het probleem te onderstrepen, en daarom zou ik blijven pleiten voor het bestaan van tools, processen en praktische methodes die governance rond de productie en het testen van weloverwogen inhoud aanmoedigen. Buiten het CMS.
Heb je een productieproces voor inhoud? Ik hoor graag uw mening in de opmerkingen.
Accentsconagua