This article was written in 2014. It might or it might not be outdated. And it could be that the layout breaks. If that’s the case please let me know.

Weg met “U Vraagt Wij Draaien”

Bijna iedereen ziet inmiddels wel in dat de watervalmethode niet geschikt is voor het maken van websites. Dat werkt goed in een productie-omgeving, zoals een fabriek, maar de meeste websites zijn uniek. Het maken van een website is geen productie, het is een design-proces.

Veel bureaus zeggen tegenwoordig dat ze werken via een agile methodiek, of ze doen scrum. Maar als ze heel eerlijk zijn moeten ze toegeven dat ze het bouwen van websites nog altijd zien als het ongezien over de schutting gooien van nutteloze deliverables naar de volgende lading inwisselbare webarbeiders. We doen hetzelfde, we noemen het alleen anders.

Zwartepieten

Het is heel moeilijk om over te schakelen naar een andere manier van werken. De watervalmethode bracht namelijk ook een hoop prettige eigenschappen met zich mee. Zo konden developers zich aan elke verantwoordelijkheid onttrekken door de ontwerpers de schuld van alles te geven. En ontwerpers hoefden geen enkele verantwoordelijkheid over het eindproduct te nemen omdat de developers het — zoals altijd — hadden verprutst. Heerlijk, zo’n leven zonder verantwoordelijkheid. Wel jammer dat het resulteerde in een constante stroom van webdiarree.

Overschakelen naar een agile werkwijze is niet gewoon een managementsbeslissing. Er is ook een verandering in de houding van de mensen uit het design-team voor nodig.

Van codeklopper naar meedenker

”U vraagt wij draaien”, is het motto van veel developers. Ik haat die uitdrukking. Niemand is gebaat bij het kritiekloos uitvoeren van slechte ideeën. Het is de taak van een developer om elk idee te toetsen aan de realiteit. Kan dit wel? En zo ja, kan dat niet makkelijker, of sneller, of goedkoper? Je kan niet van designers verwachten dat ze op de hoogte zijn van alle technische mogelijkheden en beperkingen van het huidige web. Een developer legt dus uit, indien nodig. Een developer komt met suggesties om een design met kleine aanpassingen technisch wél haalbaar te maken. Developers moeten, net zoals iedereen, het budget in de gaten houden. Als een ontwerp van een site vol zit met fancy features moeten developers er iets van zeggen. De meeste opdrachtgevers hebben namelijk niet het budget van Facebook. En als er uiteindelijk een broddelwerkje wordt opgeleverd in plaats van een goed werkende site dan moet je niet de ontwerper de schuld geven. Het is je eigen schuld. Jij hebt je namelijk gedragen als een ongeschoolde fabrieksarbeider aan de lopende band. En niet als de duurbetaalde expert die de klant denkt te hebben ingehuurd.

Van plaatjesmaker naar webkenner

Ontwerpers hadden een topbaan. Ze maakten de mooiste fantasieplaatjes, met de duurste en meest geavanceerde software. Ze hadden de beste computers en kregen altijd alleen maar hele blije klanten te zien.

”Echt waar? Krijgen we zo’n prachtige, flitsende site, met zo veel bijzondere toeters en bellen voor ons matige rotbudget? Fantastisch!”

”Natuurlijk kan dat allemaal voor die fooi”, loog de ontwerper, en gooide de bak met features over de schutting naar de developer. Van de andere kant was zachtjes ”U vraagt, wij draaien” te horen.

Het is niet de taak van ontwerpers om elke klant van de stoel te blazen met een oogverblindend ontwerp. Het is de taak van ontwerpers om een site te maken die de problemen en doelen van de klant zo goed mogelijk, en binnen het budget, oplost. Natuurlijk moeten ze daarbij de grenzen van het mogelijke opzoeken. Dat gebeurt niet solo, maar samen met de engineers en andere leden van het design-team.

Interaction engineers en design-nerds

Zowel developers als ontwerpers zitten graag op hun specialistische, kunstmatige eilandjes. Daar moeten ze nu vanaf en dat is lastig. Het is wennen. Maar ook tof. Naast de klassieke functies zie je in echte design-teams ineens mooie talenten opbloeien. Interaction engineers. Design-nerds.

Dit soort teams leveren geen ingelijste, uitgeprinte, opgepoetste, geïdealiseerde photoshop-impressies van een website meer. Misschien vinden sommige klanten dat jammer. Maar ze zijn wél blij met het feit dat de uiteindelijke site gewoon wel werkt. En het team geeft elkaar schouderklopjes, in plaats van de schuld.

Comments

    • Gertjan
    • #

    We moeten gaan werken als een bandje: je schrijft het basisliedje in je eentje. En daarna duik je met je bandleden de oefenruimte in schaaf je er samen net zo lang aan tot je een een mooie compositie hebt waar je trots op bent en dat je met een breder publiek wilt delen.

    Kan ook met websites, wedden?

    • Roberto
    • #

    Oooh… dit klinkt zo fijn :) De methode valt of staat echter vaak met “ons matige rotbudget”. De klant wil een raming van de totale kosten en dat blijft moeilijk inschatten als je blijft schaven en verbeteren.

  1. Ik denk dat je ook zoals je al zegt steeds meer multidisciplinaire designers krijgt die enig inzicht hebben in wat een developer doet en zich daar voor – of tijdens – het designproces al mee bezighoudt. Zo krijg je minder heen en weer gekaats tussen dev en designer, wat het uiteindelijke proces ook weer bevorderd.

  2. Helemaal eens, en wat goed dat iemand die instructie geeft aan mensen die deze industrie inkomen dit door heeft! Dit is ook waarom wij sinds 2008 interaction engineers hebben: je moet tussen de twee kampen in gaan zitten en ze beter en vaker met elkaar laten praten. De mooiste resultaten ontstaan in de ruimte tussen een designer en een engineer. (Nog mooier: als die twee rollen in één persoon zitten. Maar dat is zeldzaam) Het wordt ook steeds relevanter nu dat je dingen als responsive design en motion engineering mee moet nemen in je ontwerp. En die elementen worden niet zichtbaar uit een statisch photoshop bestand.

    Wist je overigens dat wij een manifesto over interaction engineering hebben? Die staat hier: http://q42.nl/interaction-engineering

    • Vasilis
    • #

    Dank je wel voor je comment, Rahul. Ik heb de link naar jullie manifesto toegevoegd aan het artikel.

  3. Ha Vasilis, toffe post. En dit is ‘nog’ maar het snijvlak tussen design en developers. Maar wat dacht je van ‘beheer’ en developers en ‘testers’ en developers?

    Uiteindelijk gaat het om teamspelen, samenwerken en inderdaad niet zwartepieten. Samen verantwoordelijkheid nemen en begrijpen dat je specialist bent in je vak maar dat uiteindelijk de combinatie meer is dan de som van de delen.