Grip op website-ontwikkeling? Kies de juiste aanpak

Het resultaat van een ontwikkeltraject blijft nogal eens achter bij de verwachtingen. Wensen die aan het begin duidelijk geformuleerd leken raken gedurende de bouw van de site hun betekenis kwijt. Hoe zorg je nu als opdrachtgever dat je grip blijft houden op de bouw van je website? Dat je aan het einde van de rit de website krijgt die je in eerste instantie voor ogen had?

Iedereen weet: Als je een zin vier keer vertaalt, krijg je een vertaling die een andere betekenis heeft dan de zin waarmee je begon. En als je het nog niet weet, probeer het maar eens uit. Vertaal een willekeurige samengestelde zin drie maal achter elkaar in steeds een andere taal en tenslotte weer terug naar het Nederlands. Als je zelf geen vier talen spreekt kun je gebruik maken van een vertaler als Google Translate. De uitkomst van de test? De betekenis is kwijt. ‘Lost in translation’. Geen uitkomst die verbaast. Of toch?

Van wens naar website

Meerdere keren achtereenvolgens vertalen doet de betekenis veranderen. Toch proberen we in een typisch ontwikkeltraject precies dát te doen. De bouw van een website kent gewoonlijk tussen de drie en de acht vertaalslagen. Ieder bureau heeft zijn eigen methodiek en terminologie – niet overal komen alle stappen aan bod. Hier volgt een zo kort mogelijke uitleg op basis van mijn eigen ervaringen. (Voor de helderheid staat het werkwoord vertalen steeds dikgedrukt.)

Strategie als uitgangspunt

De strategische doelstellingen vormen het uitgangspunt van de bouw van iedere website. Je leidt ze af van de algemene doelstellingen van de organisatie als geheel. Die vertaal je vervolgens stapsgewijs naar een online strategie. Dat kun je alleen doen, of je schakelt een ervaren partij in om je te helpen. Het is wel het fundament van de toekomstige website, waar je het over hebt.

De definitie –Programma van eisen

Als we de strategie concreet maken en inkleuren krijgen we het programma van eisen (of functioneel ontwerp). Dat is de vertaling van de online strategie naar concrete en helder gedefinieerde instructies waarmee vormgevers en technici uit de voeten kunnen.

Het smoel – Interactie en vormgeving

In het interactieontwerp vertalen ontwerpers de definities in het functioneel ontwerp naar schematische overzichten van de diverse pagina’s van de website. Het visueel ontwerp vertaalt vervolgens het interactieontwerp (samen met andere input, zoals de strategische doelstellingen) naar een fraai en duidelijk plaatje: de smoel van de website.

De werking – Technisch ontwerp

Het technisch ontwerp is een vertaling van het functioneel ontwerp naar instructies en specificaties die technici nodig hebben om de nieuwe website te kunnen ontwikkelen. In deze fase bepalen techneuten welke technieken (hoogwaardig of laagwaardig) ze gaan gebruiken om de site te realiseren.

Realisatiefase

In de realisatiefase wordt vervolgens alle input uit de drie ontwerpen gesliced, geHTMLd, gescript, geflashed, en geremixed tot er een werkende site uitrolt. Dit is ook een vertaalslag: in dat proces neemt de bouwer namelijk vaak in zijn eentje detailbesluiten op basis van de voorgaande vertalingen. En dat heeft niet altijd het gewenste effect.

De inhoud en het onderhoud

De content, tenslotte, geeft inhoud aan de werkende website en is zeer bepalend voor de indruk die de bezoeker krijgt bij het bezoek aan de website. Het reclamebureau, de fotograaf en de copywriters maken hun geheel eigen vertaling van de doelstellingen van de site. Ze ontwikkelen de content, die vervolgens vaak op onvermoede wijze interactie heeft met de werkende website. Dit proces gaat door ook nadat de website voor de eerste keer gevuld is met content. Op lange termijn verwateren of veranderen (vertaalslag!) de doelstellingen van de webredactie in de organisatie.

Grip op je website

Zoals je ziet wordt er nogal eens vertaald tijdens de realisatie van een website volgens een gangbare methode. Met alle gevolgen van dien. Functionaliteiten worden vergeten, anders ingevuld of veranderen van vorm. Het eindproduct sluit niet meer aan op de eisen die in het begin gesteld werden. De oorspronkelijk doelstellingen van de site zijn uit het oog verloren.

Het is niet moeilijk om een aantal voorbeelden te vinden van sites waarbij het lost-in-translation-effect zichtbaar aanwezig is. Het web wemelt van websites die niet effectief zijn en die als product niet aansluiten bij de oorspronkelijk doelstellingen. Maar laten we de ‘worst practices’ negeren en het hebben over wat de beste aanpak is om het lost-in-translation-effect te voorkomen. Want daar leren we tenminste iets van.

De architecten-aanpak

Laten we om te beginnen eens buiten de branche kijken. Architecten hebben een vergelijkbaar vertaalprobleem. Zij ontwerpen een gebouw en verbinden hun naam niet alleen aan het ontwerp, maar ook aan het uiteindelijke eindproduct. Daarmee bouwen ze hun portfolio en stellen zij hun toekomst zeker. Zij hebben een andere verantwoordelijkheid dan bijvoorbeeld een technisch adviesbureau, een aannemer. Hoe bewaken zij de kwaliteit van de uitvoering van hun plannen en zorgen zij dat er geen vervorming optreedt tijdens het vertaalproces?

Een architect is gewoonlijk betrokken bij een project van planning tot bewoning. De architect vertaalt de wensen van de eigenaar naar een concreet ontwerp. Hij (of zij) organiseert en overziet namens de cliënt al het werk dat tijdens de voorbereiding en constructie van het gebouw gedaan moet worden. Als we dat vertalen naar onze lost-in-translation metafoor: er is steeds slechts één vertaler die alle talen machtig is. Op die manier voorkomt de architect vervorming van zijn plannen. Diezelfde aanpak kunnen we gebruiken om websites te ontwikkelen.

Een voorbeeld: Jungle Minds heeft de architecten-aanpak toegepast bij de constructie van de Schipholsite. Daar is Tim Besselink al vanaf de strategie- en definitiefase betrokken geweest bij de ontwikkeling van de website. Gedurende het project had hij steeds een vertalende en sturende rol, en zat hij namens de opdrachtgever met de ontwerpers en bouwers aan tafel. Om zijn argumenten kracht bij te zetten, toetste hij de output van een ontwikkelfase bij de enige die er echt verstand van heeft: de eindgebruiker. Het resultaat? De Schipholsite won vorige week voor het tweede jaar op rij een Webbie Award.

SCRUM

Een andere aanpak om te zorgen dat de doelstellingen niet uit het oog verloren worden is SCRUM. Bij die methode vertegenwoordigt een professional (de ‘product owner’) de opdrachtgever. De product owner neemt dus namens de klant deel aan het ontwikkelproces. Dat gaat als volgt. De product owner beschrijft wat de uitkomst moet zijn van het SCRUM proces in de Product Backlog, stelt prioriteiten en controleert de output. Hij blijft dagelijks betrokken bij het ontwikkelproces om vragen van ontwikkelaars en vormgevers te beantwoorden. Kortom, hij (en hij alleen) vertaalt de doelstellingen van de eigenaar naar concrete uitkomsten.

Er zijn belangrijke verschillen tussen SCRUM en de architecten-aanpak. Bijvoorbeeld: waar een architect stuurt op ‘wat’ (wat de uitkomst moet zijn) en ‘hoe’ (hoe die uitkomst het best bereikt kan worden) is de SCRUM product owner alleen geïnteresseerd is het ‘wat’. ‘Hoe’ een SCRUM team het ‘wat’ bereikt is vervolgens hun zaak. Het voordeel van SCRUM is daarmee dat je optimaal gebruikt maakt van de kennis van het SCRUM team en innovatieve ideeën de vrije loop laat.

De site die je voor ogen had

De architecten-aanpak en de SCRUM methode zijn allebei succesvol in het voorkomen van vervormingen. Dat komt omdat er slechts één vertaler is – er is steeds één persoon die namens de opdrachtgever kan spreken. Hij controleert of de uitkomsten van het project voldoen aan de doelstellingen en de wensen van de klant.

Dus, de eerste les is: website-eigenaars, maak één partij verantwoordelijk voor de realisatie van je website en zorg dat die partij het project blijft begeleiden, van begin tot eind. Dan is de kans een stuk groter dat je de website krijgt die je in het begin voor ogen had.

Welke aanpak?

Welke aanpak gebruik je nou in welke situatie? Wanneer kun je SCRUM het beste toepassen, en wanneer gebruik je een ‘architect’? Dat is afhankelijk van de technische complexiteit van het project en de duidelijkheid/onduidelijkheid van de opdracht. Als vuistregel:

• Betreft het de bouw van een website waar het geheel van wensen van belanghebbenden vertaald moet worden in aansprekende alomvattende online visie? Zoals bijvoorbeeld bij een corporate website. Is de opdracht niet eenduidig, of zijn er veel eisen en wensen die elkaar uitsluiten? Ga dan aan de slag met de architecten-aanpak. Alleen een ‘architect’ heeft genoeg overzicht en gewicht om zo’n proces in goede banen te leiden.
• Gaat het juist om een technologisch ingewikkeld of vernieuwend traject? Wordt er veel voortschrijdend inzicht verwacht, of is het gewoon veel werk? Ga dan met SCRUM aan de gang – want dan zit de innovatieve kracht precies waar ie moet zitten: bij de mensen die je website aan het maken zijn.