Het is een oude bekende, als content versus design, als Road Runner versus Wile E. Coyote: de strijd Developers versus Designers. Je weet wel, die creatieve losbollen tegenover die analytische codekloppers. Water en vuur, als je het mag geloven. De discussie is al oud en vele standpunten zijn al ingenomen. Ik geloof dat zelfs de oud Romeinse architecten lekker in de clinch lagen met de uiteindelijke bouwers over het wel of niet haalbaar zijn van een ontwerp. Tegenwoordig voert diezelfde discussie zich op een ander platform, het wonderwaardige web. En dus is de hamvraag: moet een designer kunnen coden?
Computer Arts Magazine (CAM) smijt er een mooie analogie tegenaan: “the designer creates a perfect egg and they hand it over to developers, who break it then stick it back together.” Resultaat; aan het einde van de rit is een designer zelden of nooit tevreden over het opgeleverde online product.
De tijd dat de designer zelf met Actionscript of HTML/CSS aan de slag ging lijkt steeds verder weg. Er komen steeds meer specialisaties, waarbij het aantal toepasbare technieken ook hand-over-hand toeneemt. De “hybride werknemer” is dood, leve de hybride werknemer!
De analogie van CAM is het startpunt van een discussie in het blad tussen verschillende partijen, waaronder Jeremy Baines, van Howard/Baines – leverancier van diverse webapplicaties aan bijvoorbeeld Reuters. Die Baines geeft zijn designers als eerste regel mee: “praat niet met de developers voordat je je concept volledig hebt uitgewerkt”. Vaak limiteert het de designer in zijn visie; “We make a point of not letting designers speak to developers and start going: ‘is this possible?’. As soon as you do that, you start limiting your creativity”.
De stelling van Baines is op zich goed. Het creatief proces moet zo vrij mogelijk zijn. Maar ik kan zo al een situatie bedenken waarbij developer X uiteindelijk aan het buro van projectmanager Y staat om hem/haar te vertellen dat het development-team 2 weken extra nodig heeft omdat het voorgestelde design te gecompliceerd was en er dus extra lang over gedaan is.
Persoonlijk denk ik dat het belangrijk is om kennis te koppelen. Laat een designer vrij in zijn creatief proces, maar ben als designer slim genoeg om op vaste tijden te overleggen met een developer. Denk als developer mee in het gedachtegoed van een designer. “Kan niet” is dan vaak geen optie, maar werk samen naar een oplossing. Vaak is die oplossing krachtiger omdat hij niet alleen goed ontworpen is, maar ook goed ontwikkeld kan worden. Communicatie is key. Volgens mij zorgt de juiste communicatie er niet voor dat een creatief wordt gelimiteerd, sterker nog – het maakt hem/haar beter. Moet een designer kunnen coden? Nee, naar mijn mening niet. Zoals een developer niet hoeft te kunnen designen.
Wat deze discussie voor mij uniek maakt is het feit dat hij enigzins parallel loopt met de ontwikkeling van het web. Van alles vanuit een individu naar kennisdeling. Waar het web zich nu klaar maakt voor de volgende stap; alle informatie op de juiste manier aan elkaar knopen – moeten wij dat ook….
…. of denk jij, Frank-ly lezer, daar anders over? :-)
(Computer Arts Magazine 151 is nu te koop in de winkel)
Van mij hoeft een designer geen code te kunnen kloppen, maar het zou wel handig zijn om er ‘iets’ vanaf te weten. Zodat je van tevoren gewoon enigszins rekening kunt houden met wat er wel en niet met het medium in de huidige staat mogelijk is en wat er binnen het gestelde budget past. Eindeloos creatief zijn is leuk, maar aan de andere kant zul je ook commercieel moeten denken, want je wilt wel een botenham eten. Toch?
Anyway, ik wil dat hele verhaal graag eens lezen!
Nicoline op 04 juli 2008 om 12:03http://www.frank-ly.nl
Ik denk dat vanaf de eerste concepten een programmeur in je team snokken heel verstandig is. En dan een programmeur die niet alleen denkt vanuit wat hij al weet, maar creatief kan omgaan met z’n kennis. Dan is een ontwerper zoals ikzelf dan een beetje, die wel wat kaas heeft gegeten van de technische kant van het verhaal toch wel handig. Het gebeurt regelmatig dat ik met creatieve suggesties kom qua hoe het technisch gezien misschien óók zou kunnen, die een codekloppert nog nooit zo had bedacht.
Nou ja. Kortom. Samenwerken. Samen snappen wat de bedoeling van het eindresultaat is. Samen snappen waarom de ontwerper het precies zo bedoeld had (of helemaal niet zo bedoeld had maar ook niet wist dat de programmeur dan vierenhalf uur met scriptjes en transparante png’tjes moest gaan klootviolen om het op alle platformen zo’n kekke scrollbalk te laten lijken). En samen kijken of de opgeworpen onmogelijkheden belangrijker zijn dan De Boodschap die met het geheel of de details overgedragen dient.
Zowel programmeurs of designers moeten niet alleen kunnen communiceren, maar ook wat van communciatie (willen) weten. Dan komt het goed. Ooit.
Hoof op 04 juli 2008 om 13:35http://hoofspot.blogspot.com
Interessante discussie. Ik denk dat het handig is als een designer wat van code en systemen af weet. Hij of zij hoeft het niet te kunnen maken, maar wel kunnen begrijpen wat de implicaties van bepaalde ontwerpkeuzes zijn.
Bij het bedenken van een nieuwe dienst of service kan technische kennis in de weg zitten, althans als je je daar niet los van kunt maken in het proces om een idee te ontwikkelen.
Het grootste deel van de werkzaamheden van een online of interaction designer zijn pragmatische oplossingen, steeds vaker primair gericht op usability dan op esthetiek. De kracht van een goede designer zit wat betreft interactieve producties ook veel vaker in hoe hij of zij verschillende diciplines kan verenigen in één ding of één ervaring voor de uiteindelijke gebruiker. En dat dit er ook nog eens goed uit ziet.
Wilbert op 04 juli 2008 om 14:36http://www.hypernarrative.com
Ik ben een interaction designer en ben vanuit de breedte de diepte in gegroeid omdat er in mijn werksituatie vraag naar was. Dat betekent dat ik zowel een interaction designer, vormgever en developer ben geworden. De laatste internationale conferenties (gericht op interaction design) waar ik ben geweest, daar hoor de designers maar over een ding: designer-developer relatie. En uit eigen ervaring, het gaat niet altijd over rozen..
Het feit dat de communicatie tussen developers en interaction designers vaak voor verbetering vatbaar is, is omdat designers en de developers te ijdel zijn. Als het een frankenstein-samenwerking is dan delven de designers het onderspit, omdat de programmeurs altijd de boel kunnen saboteren als zij hun punt willen maken. In de software wereld geldt de norm van het snelle ontwikkelen meer dan de kwaliteit. Het ergste wat een ontwikkelaar kan doen is expres langzaam gaan programmeren. Design is dan ook vaker een afterthought.
Het is gewoon prettig als je kunt programmeren omdat je dan niet alleen de uitvoerbaarheid kan meenemen in je ontwerp, maar ook dat je makkelijker door de medeprogrammeur wordt erkent. Het beste is dan ook om dan alleen het front-end werk te doen, zij blij omdat zij zich dan op de ‘echte’ uitdagingen kunnen richten. De leeftijd van de developer maakt uit, ik heb gemerkt dat er steeds meer developers afstuderen die de frontendprgramming ook uitdagend vinden.
Wie de ontwikkelstadia van interaction design van bedrijven bestudeerd (zie artilen van guru Jakob Nielsen: http://www.useit.com/alertbox/maturity.html , http://www.useit.com/alertbox/process_maturity.html, weet ook dat er pas interesse is voor interaction design als programmeurs het tot uitentreure eerst zelf hebben geprobeerd (en hebben gefaald) voordat zij echt een interaction designer accepteren. Tenminste dit is vaak zo in de wat traditionelere business-to-business software wereld. Ik kan mij voorstellen dat dit anders is bij interactiondesigners-developers bij marketing bureaus en mediabedrijven.
Simon Asselbergs op 04 juli 2008 om 20:42@simon
Johan Voets op 05 juli 2008 om 10:55Persoonlijk reken ik front-end development in dit geval JUIST tot “kunnen coden”. Zodra er namelijk een database en coldfusion/php/.net/ror bij komt kijken wordt het een heel ander balspelletje en dat gaat ook veels te ver om van een designer te verwachten.
http://www.frank-ly.nl
Natuurlijk is het handig als een designer weet wat zeg maar de kaders zijn waar binnen hij te werk kan gaan. Maar een designer hoeft zeker niet te kunnen coden. Natuurlijk is bijna alles technisch haalbaar als er maar tijd, budget en resources beschikbaar zijn. De alom bekende driehoek. Deze 3 factoren zijn 99 van de 100 keer uiteraard niet variabel en staan vast. Kortom creativiteit is prima maar wel binnen de gestelde kaders van deze driehoek. Om binnen deze kaders een creatief mooi design neer te zetten is uiteraard veel overleg nodig met de developers. Ik denk wel dat dit binnen Rhinofly goed gaat. Even aan de wandel en bij een frontend danwel backend developer buurten of dit kan en binnen de scope past. Kortom een designer hoeft te niet kunnen coden maar wel goed kunnen communiceren.
Bas Gezelle op 05 juli 2008 om 13:34http://bgezelle.tumblr.com
@ Johan,
Hangt er maar net vanaf waar je werkt. Ik heb nooit zo de behoefte gehad om de scope van de eindgebruiker te verlaten, een database is idd te diep. De focus is belangrijk. Echter uitzonderingen bevestigen de regel.
Als je een eigen zaak opzet, dan is het wel toch verdomd handig als je de breedte en de diepte in kan, zo heb ik gemerkt. Dus ik ben er hartstikke blij mee dat ik veel vrije tijd heb geinvesteerd in het opzetten van backend functionaliteit, inclusief remoting en databases. En mocht de business groeien dan is het fijn om een eigenaar te hebben die meer dan alleen affiniteit heeft met interaction design en techniek. Maar dat laatste is mijn eigen persoonlijke voorkeur.
Het hangt ook af in welke branche je werkt. Als je werkt met Business Intelligence toepassingen heb je vaak met Datawarehouse oplossingen te maken en dan ontkom je als interaction designer er niet aan om veel dieper in de stof te moeten duiken dan “normaal”.
@Bas
Communiceren is extra belangrijk bij iedere ontwerptaak, dat is voor interaction designers als het goed is geen nieuws. Ik ben er sterk van overtuigd dat dit ook betekent dat in de toekomst er meer verlangd zal worden van de communicatieve vaardigheden van programmeurs. Ik heb veel programmeurs zien werken in hun eigen “eilandjes” en ik vind dat onverantwoord. Wat teamalignment is dus zo gek nog niet.
Binnen de media en marketing bureaus is dat minder een issue dan binnen grote bedrijven waar grote aantallen medewerkers de software in elkaar zetten. Mij is opgevallen dat naarmate er meer ontwikkeluren in een pakket zitten er steeds minder vrijheidsgraden zijn voor aanpassingen.
Simon Asselbergs op 05 juli 2008 om 15:39@simon
Je geeft aan dat het belangrijk is affiniteit te hebben met de andere vlakken en dat ben ik (net als Nicoline boven je) met je eens. Het is handig als je een idee hebt waar het over gaat, de bakker weet tenslotte ook waar zijn graan vandaan komt. Hoe meer affiniteit en passie je voor je vak en de verschillende facetten toont, des te leuker. Echter, betekent affiniteit dat je een design van voorstel tot oplevering moet kunnen vertalen van PSD naar html/css? Voor mij persoonlijk niet.
Dieptebreedte-technisch ben ik het ook wel met je eens, het is handig om zowel de diepte als de breedte in te kunnen. Zeker als je een eigen zaak begint. Echter; wat zoek jij in een nieuwe werknemer? Nog steeds de diepte en de breedte, zeker in het begin – logisch. Totdat je dadelijk een zaak vol vierkante alleskunners hebt, die zowel de diepte als de breedte in kunnen maar elkaar niet meer versterken, maar alleen nog maar aanvullen.
Johan Voets op 05 juli 2008 om 16:25http://www.frank-ly.nl
Je kunt je afvragen welk personeel je wil hebben als je groeit, maar je kunt je ook afvragen welk bedrijf wil ik hebben en moet daar perse zo’n standaard heirarchisch organisatie plaatje bij horen. Het kan eigenzinniger, bijvoorbeeld een celstructuur.
Bij en celstructuur groeit het bedrijf niet verder dan 50 man en als het verder moet groeien, nieuw bedrijf en personeel verdelen tussen de twee bedrijven. Dan heb je als voordeel dat de menselijke maat blijft, je brede mensen goed kan inzetten en mensen elkaar kan laten versterken en toch kan groeien. De high potentials voor business kunnen dan binnen gehouden worden om ze als eerste man van het nieuwe bedrijf aan te wijzen.
De schaalvoordelen van grote bedrijven wordt volgens mij enorm overschat en volgens mij bijna nooit echt benut. Klanten en medewerkers worden naarmate een bedrijf groeit toch nummertjes en ontstaat er een politieke dikke laag van managers.
Simon Asselbergs op 05 juli 2008 om 17:57Wat ik niet begrijp is de indeling ‘developer’ vs ‘designer’.
De kunstacademie heeft mij opgeleid als ontwerper, in de breedste zin van het woord. Of dit nu code is of typografie. Op dit moment bouw ik websites van 0 tot Z. Dat begint met klantgesprekken, via interactie schetsen en prototypes en iteraties richting de eindversie. Ik weet heel goed wat momenteel ‘trendy’ is en wat er allemaal mogelijk is. Er moet per project worden bekeken wat de overhand heeft, gaat het puur om visuele uitstraling? Moet het functioneel zijn? Beiden?
Er moeten concessies worden gedaan om het functioneel genoeg te houden. Durf een ‘attitude’ te hebben. Durf support voor IE6 te laten vallen, durf nee te zeggen tegen sIFR en andere houtje-touwtje technieken waarmee geen duurzame website of webapplicatie te bouwen valt. Mijn mening is dat een vormgever zich niet aan die rol moet vastklampen zoals een DTP’er dat kan. Die hoeft zich niet druk te maken of het wel kan: het kan toch wel gedrukt worden. Een website is iets anders, en daar kunnen sommige visuele trucjes beter niet.
Wat ook niet meehelpt aan de dichting van deze kloof, is dat developers chronisch worden onderschat. Hoe vaak hoor ik niet: ‘oh ja het moet ook nog worden gemaakt’. Al het andere is belangrijker. Mijns inziens is het juist andersom, en is de techniek minstens even belangrijk. Je kan wel een heel mooi huis bedenken en uittekenen, als de technisch architect zegt dat het instort kun je maar beter terug naar de tekentafel.
Maar nee, de meeste bedrijven, zeker als ze voor klanten werken, willen snel snel snel alles in elkaar flansen: kwantiteit over kwaliteit. Dat is denk ik de grote meerwaarde van een bedrijf als google en 37signals: technische details boven trendy vormgeving. Voor de meesten van ons zou een stapje in die richting al voldoende zijn denk ik.
Tinus op 07 juli 2008 om 11:39@ Tinus
Kort: De focus ligt verkeerd er wordt te veel op kwantiteit en visuele speeltjes ingezet en te weinig op duurzaamheid.
Ik merk zelf dat het een gigantisch voordeel is als je een degelijke development en design achtergrond hebt. Er is dan weer meer serendipiteit, creativiteit en meer iteratie, je hebt tijdens het bouwen/designern feedback over het gedrag van interactie. Minder tussen schakels. Gedrag in iteractie kost veel tijd om gedetailleerd te beschrijven en dat is uitdagend om developers daarover uit te leggen/overtuigen.
Overigens, het is wel slim om soms bewust te zijn van DTP zaken als PMS sets en kleurkalibratie. Het is best wel handig om te weten dat als je een kleur gebruikt dat en waar hij voorkomt in het PMS spectrum. Als branding onderdeel is van je verantwoordelijkheden ook bij de user interfaces, dan moet je toch ook aandacht hebben voor dergelijke zaken.
Simon Asselbergs op 07 juli 2008 om 16:19