De Drupal workflow: wie is de baas?

De kracht van Drupal is dat je het systeem op maat kan laten maken. Op maat voor de verschillende doelgroepen die de website bezoeken, maar zeker ook voor de mensen die er uiteindelijk dagelijks mee moeten werken aan de achterzijde. Echter, de gebruikerservaring van die laatste groep krijgt in de praktijk vaak weinig aandacht, wat indirect weer ten koste gaat van het succes van een website.

In deze serie deel ik tips en modules die ervoor kunnen zorgen dat het werken met de back-end van Drupal snel en pijnloos verloopt. Maar het begint allemaal met die eerste fase waarin de website nog ontwikkeld moet worden. Op welke punten kan dit proces worden verbeterd om de "werkvloer" beter tegemoet te komen?

Nee! Niet weer nieuw systeem!

Werken met een nieuw CMS systeem is bijna nooit leuk. Dat weet ook Thomas Svenson, leider van het Drupal Usability Initiative. In zijn artikel The Content Editors Are Your Most Important Users (2012) zegt hij hierover: “(...) users hate CMS’s, as they are forced to adapt to the technology. Including learning a lot of new technical terms, complex workflows and other stuff they shouldn’t have to.”

Het lijkt inderdaad vanzelfsprekend geworden dat een nieuw systeem grote aanpassingen vraagt van werknemers en dan ook zelden met enthousiasme wordt ontvangen. Maar de modulaire structuur van Drupal heeft juist als voordeel dat je aanzienlijke controle hebt over de manier waarop je functionaliteiten aanbiedt, zowel aan de voor als achterzijde.

Dit maakt het mogelijk om Drupal aan te passen aan de gebruiker in plaats van andersom. Dat is ook wat Svenson graag zou zien: “What it really boils down to, though, is that we need to be better on adapting Drupal to user needs, not the way around.” Dus bij voorkeur geen trainingen achteraf, maar meer zeggenschap vooraf. Klinkt logisch, maar waarom gebeurt het niet altijd?

Waarom de werkvloer niet wordt betrokken..

Jeff Eaton, programmeur bij Lullabot en zeer betrokken bij de community en de ontwikkeling van Drupal, betoogt in zijn presentatie Baby got back-end (DrupalCamp Toronto, 2012) dat de content editor, diegene die daadwerkelijk met de website zal gaan werken, de belangrijkste gebruiker is. Maar zijn leven ziet er volgens Eaton momenteel weinig rooskleurig uit.

Dit komt volgens hem doordat die groep vaak pas op het laatste moment (of helemaal niet) betrokken wordt bij de bouw van een website. Het management of de IT afdeling neemt meestal alle beslissingen en zij hebben met name oog voor zaken als de gebruikersvriendelijkheid voor bezoekers en of alle gevraagde features aanwezig zijn.

Daar valt aan toe te voegen dat het ook niet verwacht kan worden van diegenen die verantwoordelijk zijn voor de nieuwe website dat zij zich volledig bewust zijn van alle mogelijkheden die er zijn met betrekking tot het aanpassen van de achterzijde. Daarbij kan de gedachte overheersen dat dit veel tijd en geld kost die beter besteed kan worden aan de bezoekers ervaring.

...en waarom dat geld kost

Toch zijn er goede argumenten om meer aandacht aan de back-end te besteden en redacteuren eerder te betrekken. Eaton noemt hier twee belangrijke redenen voor. Ten eerste raken medewerkers gedemotiveerd door een frustrerend CMS systeem. Zij zullen zich twee keer bedenken voordat ze een artikel plaatsen als ze hierbij tegen drempels aanlopen. En minder content betekent minder conversie. Niet alleen beloont Google websites die regelmatig vernieuwd worden met een hogere pagerank, maar ook bezoekers krijgen een veel betere indruk van een website die actueel is.

De tweede en misschien wel belangrijkste reden is tijdwinst. Laat het per content-item een minuut tijdswinst opleveren door bijvoorbeeld een layout beter in te delen of een bepaalde handeling te automatiseren. Tel je al die minuten bij elkaar op dan kan de totale tijdswinst als snel uitkomen op een paar uur per week, per werknemer. Zonde van de tijd en het geld.

Hoe medewerkers wel te betrekken

Door diegenen die daadwerkelijk met het systeem gaan werken bij de bouw van de website te betrekken voorkom je een hoop frustraties terwijl dit weinig extra tijd en geld hoeft te kosten. De investering haal je er bovendien makkelijk weer uit met de tijdswinst die het uiteindelijk oplevert en doordat medewerkers minder training nodig zullen hebben.

Om te beginnen kun je prototypes voor leggen aan werknemers en hun vragen om hierbinnen bepaalde taken uit te voeren waarbij ze ondertussen notities maken. Via een aantal feedback rondes ontstaat er zo bij de ontwikkelaar een steeds beter beeld van de workflow. Voor welke taken wordt het CMS systeem gebruikt? In welke volgorde vinden deze plaats? Welke gebruikersrol neemt welke taken op zich? En wat is het kennis niveau van de personen binnen een bepaalde rol? De aanpassingen die hieruit volgen zijn meestal klein maar hebben desondanks een grote impact hebben op de usability.

Geen gouden formule, wel globale richtlijnen

Wat in de ene situatie een verbetering is kan in een andere situatie juist een verslechtering zijn. Svenson en Eaton benadrukken dat workflows voor elke organisatie weer uniek zijn en dat je dus telkens weer het systeem zult moeten vormen naar de specifieke taken en gebruikers in plaats van de medewerker aan te passen aan het systeem.

Wel zijn er in ieder geval twee globale gebruikersrollen te onderscheiden. Zo zijn medewerkers die af en toe, zeg 1 keer in de maand, moeten inloggen om kort iets aan te passen zeer geholpen met veel aanwijzingen. Op die manier hoeven zij zich niet telkens af te vragen hoe alles ook al weer werkt. Medewerkers die juist zeer frequent met een CMS systeem werken hebben vooral behoefte aan snelheid.

De eerste groep noemt Eaton "confused newbies" en de tweede groep "power users". Voor beide groepen zijn er aanpassingen en modules die kunnen helpen om hun specifieke taken zo aangenaam mogelijk te maken. In het volgende artikel ga ik het over deze richtlijnen en modules hebben.