Inleiding 

Op de website http://www.designervsdeveloper.com.au/ kan men op basis van het uiterlijk gokken of de persoon een ontwerper of een programmeur is. De verschillen tussen een ontwerper en programmeur zijn echter lastig te bepalen aan de hand van uiterlijke kenmerken. Wanneer men kijkt naar de manier waarop een persoon zijn hersenen gebruikt wordt het al een stuk makkelijker te bepalen of de persoon in kwestie meer geschikt is voor het ontwerpen of het programmeren.  

Onze hersenen zijn onderverdeeld in twee delen: links en rechts. Mensen die voornamelijk hun linkerhersenhelft gebruiken zijn in staat om meer analytische en logische taken uit te voeren. Mensen die voornamelijk hun rechterhersenhelft gebruiken zijn in staat om meer creatieve en visuele taken uit te voeren. Om een goede programmeur te kunnen zijn is analytisch denken een vereiste. Om een goede ontwerper te kunnen zijn is het visuele aspect belangrijker. Ondanks dat de ontwerper en de programmeur totaal verschillende karaktereigenschappen hebben zijn ze binnen de webdesign industrie samen verantwoordelijk voor het eindproduct. De ontwerper levert de grafische vormgeving van de voorkant aan en de programmeur is verantwoordelijk voor het vertalen hiervan in code voor de achterkant. 

Dit onderzoek gaat dieper in op de verschillen tussen de ontwerper en de programmeur en de manier waarop deze samenwerken. Er wordt gekeken naar de problemen die de verschillen opleveren en hoe deze het beste opgelost kunnen worden.  

Allereerst wordt er gekeken naar de verschillen tussen de linker en de rechterhersenhelft. Vanuit een theoretisch perspectief wordt een basis gecreëerd waarmee een scheiding gemaakt kan worden tussen de ontwerper en de programmeur. Deze theoretische basis wordt gereflecteerd op een drietal vooraanstaande figuren binnen de webdesign industrie, waaronder één van de populairste vakmannen binnen dit gebied: Jeffrey Zeldman. Ook is er een interview met Paul Boag, voorzitter van het 'Future of Web Design' evenement en Christian Heilmann, een belangrijke schakel binnen de programmeerafdeling van Yahoo. 

De vragen die binnen dit onderzoek centraal staan: In hoeverre is er een scheiding tussen de ontwerper en programmeur? Hoe verloopt de samenwerking tussen de ontwerper en programmeur? Wat voor een problemen ontstaan er en hoe worden deze opgelost? 

In hoofdstuk 1 wordt er gekeken naar de scheiding van de hersenhelften en de manier waarop de ontwerper en de programmeur hiermee te maken hebben.  

1. Verschillende manieren van denken 
Wat zorgt er nu voor dat een persoon meer aanleg heeft voor het ontwerpen of het programmeren? Vanuit de neurowetenschap komt het idee dat dit te maken heeft met de verdeling van ons brein. Zo heeft de mens een linkerhersenhelft en een rechterhersenhelft. In zijn boek The Right Brain: A New Understanding of the Unconscious of the Unconscious Mind and Its Creative Powers uit 1980 heeft Thomas R. Blakeslee het over twee manieren van denken: “After hundreds of experiments of the two hemispheres finally emerged, proving that the two halves of our brain think in distinctly different ways.” (Blakeslee, 1980: 9) Deze manieren van denken onderscheidt Blakeslee met het volgende voorbeeld: “Words and logic are powerful tools for thinking, and the left brain easily outperforms the right in tasks where they are useful. But the right brain comes into its own in matters that are difficult to put into words or understand in logical steps-the things that you must 'have a feel for.'” (Blakeslee, 1980: 10). Logische en analytische dingen zijn makkelijker te behappen voor de linkerhelft, de rechterhelft is daarentegen weer sterker met zaken waar 'gevoel' bij komt kijken.  
Daniel H. Pink geeft in zijn boek A Whole New Mind: Why Right-Brainers Will Rule The Future uit 2005 aan dat er na 30 jaar onderzoek vier belangrijke verschillen zijn tussen de twee hersenhelften:

• “1. The left hemisphere controls the right side of the body; the right hemisphere controls the left side of the body.” (Pink, 2005: 17). Dit wil zeggen dat wanneer iemand zijn rechterhand opsteekt dit gedaan wordt vanuit de linkerhersenhelft en vice versa.  
• “2. The left hemisphere is sequential; the right hemisphere is simultaneous.” (Pink, 2005: 18). De linkerhelft is vooral goed in opeenvolgende gebeurtenissen zoals het lezen van tekst. Bij het lezen van een zin decodeert de linkerheflt elk woord en elke letter. De rechterhelft houdt zich meer bezig met het grotere geheel, bijvoorbeeld de betekenis van de zin, paragraaf of het hoofdstuk. 
• “3. The left hemisphere specializes in text; the right hemisphere specializes in context.” (Pink, 2005: 20). De linkerhelft analyseert de tekst en de rechterhelft plaatst het in de context, zoals het geval is bij een metafoor. Als de hersenen te horen krijgen dat er 'een rij van hier tot Tokyo staat' dan begint de linkerhelft te analyseren en in paniek te raken omdat het dan wel heel erg lang gaat duren. De rechterhelft kalmeert de linkerhelft door het in de juiste context te plaatsen. 
• “4. The left hemisphere analyzes the details; the right hemisphere synthesizes the big picutre.” De hersenen interpreteren informatie door deze te analyseren en te synthetiseren. De linkerhelft begrijpt alle details maar de rechterhelft houdt het overzicht.

Er is een verschil tussen mensen waarbij de linkerhersenhelft actiever is. Pink betitelt deze als 'L-Directed Thinkers'. Mensen waarbij de rechterhersenhelft actiever is, krijgen op hun beurt de titel 'R-Directed Thinkers' mee. In onderstaande tabel staan enkele beroepen onderverdeeld in deze twee groepen: 

L-Directed Thinkers 

• Wetenschappers 
• Programmeurs
• Accountants 
• Artsen

R-Directed Thinkers

• Kunstenaars
• Ontwerpers
• Auteurs
• Psychologen

De beroepen in de linkerkolom van de tabel vragen om een groot analytisch vermogen en het nauwkeurig interpreteren van informatie. De beroepen in de rechterkolom van de tabel vragen om een bepaalde vorm van creativiteit. 

Ontwerper & programmeur 

In dit onderzoek gaat het om het verschil tussen de ontwerper en de programmeur in de webdesign industrie. Zoals te zien is in de bovenstaande tabel hebben deze twee karakters een verschillende denkwijze. Toch is het belangrijk dat zij samenwerken om tot een bepaald product te komen. Het gaat hierbij om het creëren van een website. 

In dit onderzoek is een ontwerper iemand die zich voornamelijk bezighoudt met het ontwerpen van websites. Het ontwerpen van de voorkant van de website, waar de gebruiker direct mee in contact komt. In een zoektocht naar een duidelijke omschrijving van het begrip spreekt de definitie zoals deze gegeven wordt op de website van het 'Design Institute of Australia' het meeste aan: “A designer is a business professional who develops solutions to commercial needs that require the balancing of technical, commercial, human and aesthetic requirements.” (What is a designer, 2008). Deze definitie benadrukt het commerciële aspect. Het ontwerp moet bruikbaar zijn voor de gebruiker, anders is het niet te verkopen.  

Een programmeur is iemand die zich voornamelijk bezighoudt met de achterkant van de website. De programmeur is bezig met de onderliggende techniek en de werking van alle elementen. Deze code is niet direct zichtbaar voor de gebruiker. 

Binnen de webdesign industrie bestaan er veel verschillende termen, die zowel een ontwerper als programmeur aanduiden. Dit blijkt ook uit het onderzoek gehouden door 'A List Apart', één van de populairste online magazines op het gebied van webdesign. In de onderstaande grafiek staan de meest gebruikte titels van banen in de industrie: 

In dit onderzoek wordt een developer gezien als een programmeur en een webdesigner wordt gezien als een ontwerper. Het is nu duidelijk is hoe de begrippen ontwerper en programmeur binnen dit onderzoek gebruikt worden. In het volgende hoofdstuk wordt gekeken naar hoe deze tegenstelling tussen de ontwerper en programmeur leeft binnen de webdesign industrie en hoe een mogelijke botsing voorkomen kan worden.

2 Links en rechts in de praktijk

In dit hoofdstuk wordt de theorie gereflecteerd op de praktijk. In hoeverre is deze scheiding terug te zien op de werkvloer? Maakt het verschil in de karakters van een ontwerper en een programmeur de samenwerking onmogelijk, of is dit geen probleem? En hoe zijn mogelijke problemen het beste op te lossen? 

Om de theorie uit voorgaande hoofdstukken in de praktijk te toetsen zijn er interviews gehouden met zowel ontwerpers als programmeurs die actief zijn binnen de webdesign industrie. Er zijn drie prominente figuren binnen de webdesign industrie geïnterviewd.

2.1 Paul Boag 

Paul Boag presenteert 'Boag World', de populairste podcast op het gebied van webdesign. Tevens is hij voorzitter van het Future of Web Design evenement dat op 17 april 2008 in Londen plaatsvindt. Reden te meer om zijn perspectief op dit onderwerp te krijgen.  

Boag begon als iemand die zowel als ontwerper als programmeur functioneerde. Binnen het bedrijf was hij als enige verantwoordelijk voor het ontwerpen en bouwen van websites. Ondanks dat omschrijft Boag zichzelf als “Jack of all trades, master of none” (Boag, 2008). Hij kan alles een beetje, maar is niet uitmuntend in een bepaald onderdeel. 

Maar naar welke kant van het spectrum neigt Boag dan het meest? Naar de linkerkant of de rechterkant? Op de vraag of hij zichzelf meer als een ontwerper of programmeur ziet is zijn antwoord resoluut ontwerper. Hij is opgeleid als grafisch ontwerper er hij geeft aan dat hij slechts gedeeltelijk code kan interpreteren en schrijven: “I am not logical and organized enough to be what you call a hardcore coder.” (Boag, 2008). Logisch en georganiseerd zijn zijn dus volgens Boag twee karakter eigenschappen die een programmeur moet hebben. Op de vraag welke kwaliteiten essentieel zijn voor een ontwerper antwoord hij na een lange pauze: ”I think there is a need to have a eye for visual detail... it's wether or not you are visually orientated.” (Boag, 2008). 

Maar wat is dan het grote verschil tussen een ontwerper en een programmeur? Boag haalt diep adem en zegt:

“Attention span. Being a programmer you need to really concentrate and really get into something in depth. You need to be intressted in something for a long period of time and concentrate for a long period of time. With a designer you often find that designers have short attention spans... [I]t's purely part of the charasteristics, part of that creative point of view... [T]hey tend to be flitting from the one thing to another.” (Boag, 2008). 

Het gaat om de aandacht die een ontwerper en een programmeur aan iets besteden. Een ontwerper springt snel van het ene naar het andere, terwijl een programmeur langer gefocust blijft op één bepaald probleem. 
Is het ondanks dit verschil mogelijk voor een ontwerper om een programmeur te worden en andersom, of is het iets wat vastgelegd is in de manier waarop wij onze hersenen gebruiken?

Volgens Boag is er geen zwart wit antwoord op deze vraag. Een ontwerper kan de basis van het programmeren leren en een programmeur kan de basis van het ontwerpen leren. “But I think to truly excel I think there is a degree of hard wiring.” (Boag, 2008). Om een echt goede ontwerper of programmeur te worden is een bepaalde structuur in de hersenen noodzakelijk. 

Wanneer er gevraagd wordt naar de ervaringen van de samenwerking tussen ontwerper en programmeur begint Boag te vertellen over een online applicatie voor bejaarden die zelf niet meer in staat zijn om te koken. Zij laten daarom bevroren maaltijden bezorgen. Hij vertelt over de confrontatie tussen de ontwerpers en de programmeurs: “[It] involved designers and developers working very close with one another which is always a very challenging area.” (Boag, 2008). Ondanks dat Boag de samenwerking omschrijft als een uitdaging gaat hij niet dieper in op het verloop van de samenwerking. Want hoe communiceren deze twee partijen met elkaar? “We have discovered that in projects where designers and developers and project managers need to work very closely with on another that actually working side by side in office is the most effective method.” (Boag, 2008). Maar wat gebeurt als de ontwerper spontaan een idee krijgt? Rent de ontwerper dan naar de programmeur met de vraag of deze het kan bouwen? Het gaat niet om wat de ontwerper of programmeur het beste vindt, het gaat om de gebruiker, aldus Boag: 

“I believe... and perhaps this is because I come from a design background... any web application or website needs to be user based driven. I don't believe a projects needs to be restricted by the underlying technology. As a designer you want to achieve a particulair thing through the user experience you talk with the developer of how that is achievable. Sometimes you have to make compromises about that.” (Boag, 2008). 

Boag omschrijft de essentie van deze communicatie en samenwerking tussen de ontwerper en programmeur als fundamenteel: “I don't think a project can be run succesfully if the design team and the programming team aren't working close together... [t]here needs to be a continuing dialogue going between those two parties.” (Boag, 2008).

De samenwerking tussen de ontwerper en de programmeur verloopt echter niet altijd soepel. “The biggest problems we have expierenced have been when we were commisioned by a client to produce the design and front end content and then there is a seperate organization that has been commisioned to do the intergretation.” (Boag, 2008). Boag vertelt over een project waarvoor zij werden ingehuurd. De voorkant van een website moest zo toegankelijk mogelijk gemaakt worden. Voor de achterkant, het programmeerwerk, werd een andere partij ingeschakeld. Al snel werd duidelijk dat de basis van het programmeerwerk onvoldoende flexibiliteit bood voor de voorkant. Door deze beperkingen moest Boag drastisch inleveren op de toegankelijkheid van de applicatie. Het project werd meer vanuit de techniek bepaald dan vanuit de uiteindelijke gebruiker:  

“The developers selected were very much indoctrinated into the way of thinking that was associated with this technology. They were struggling to think beyond the constraints of this technology.”. The problem arises when you get a group of developers that are wedded to a specific piece of technology. They work exclusively with one piece of technology. And over a period of time I think they can end up seeing the world through the filter of that piece of technology.” (Boag, 2008) 

Omdat programmeurs zich dermate focussen op een bepaalde technologie, is het lastig om de beperkingen van deze technologie te zien.  

Hoe is dit probleem op te lossen? Boag heeft de volgende oplossing: de ontwerpers aan het begin van het project inbrengen en te laten helpen in het proces bij het kiezen van een technologie. “As designers we're not neccesarily technology experts but certainly we can ask the kind of issues that are important to designers and are important to good user expieriences and we can probe in those areas. Especially on projects where we say user experience is fundamental it's important to get on designers earlier.” Hiermee impliceert Boag dat ontwerpers zich beter kunnen inleven in de eindgebruiker en een beter inzicht hebben in wat nodig is om het product zo gebruiksvriendelijk mogelijk te maken. 

Maar de problemen liggen dus voornamelijk bij de klant. De klant heeft een bepaald idee voor een product en huurt dan een ontwerper (of ontwerpers) in voor de voorkant en een programmeur (of programmeurs) voor de achterkant. Deze twee partijen kennen elkaars werkwijze niet en dat zorgt ervoor dat het traject stroever verloopt. “It's not particualy a dialog, the client knows very specifically what they want from the project. They go out they hire a designer to do that than they hire a developer to do the other side of that. There is not much of a dialogue going on...” Boag prefereert een traject waar de klant aan het begin een consultancy bureau inschakelt, die de klant helpt bij het formuleren van de specificaties van het project.  

De problemen tussen een ontwerper en programmeur vloeien volgens Boag voornamelijk voort uit een slechte structurering van het project. Maar hoe zit dat dan met de individuele karakters van de ontwerper en de programmeur? Zijn er bepaalde eigenschappen van deze twee karakters die altijd zullen botsen? Boag ervaart deze botsing niet: “A good designer should have understanding of how to code things. They are exposed to some of the things developers have to face. Equally a good developer has a basic grasp of user interface design. So where the real problems come is to do with how the organizations are set up.” (Boag, 2008). Het bedrijf waar de ontwerper en programmeur samenwerken moet er voor zorgen dat ze van elkaar weten wat ze doen. Wanneer een ontwerper nooit in contact is gekomen met de onderliggende code is het onvermijdelijk dat hij of zij ontwerpen maakt die onmogelijk zijn om te bouwen door de programmeur. Hetzelfde geldt voor de programmeur. Wanneer deze geen gevoel heeft voor het user interface is het goed mogelijk dat de code totaal gestructureerd wordt aan de hand van de technologie. Het gemak van de gebruiker wordt achterwege gelaten.

“That's where problems occure when they live in total different universes. The biggest area of difficulty is in communication. Developers in particulair are not good in communicating. Some of the most talented developers are borderline authistic. That's what enables them to be so good at what they do. But that does create a fundamental communication problem. So you often find developers making statements such as: 'That can't be done'. What they actually mean is: 'It can't be done in the way you currently suggesting it.'. What needs to really happen is a dialogue, what is possible and how can work around that and what compromises need to be made?” (Boag, 2008). 

De programmeur heeft problemen met het correct communiceren van zijn gedachten. Maar de ontwerper kent ook zijn gebreken: 

“There is also a problem from the design point of view that designers are often very precious over their design work and often very unwilling to compromise. A lot of designers fail to grasp that they are designers and they are not artists. They fail to produce work that fails to meet a need. And exist in a commericial envirionment where compromise is part of the landscape. Where sometimes you have to do things that make you feel vaguely dirty to get the project done and in order to meet the need. I think those would be the two big weaknesses. Developers aren't good at communicating and designers are maybe overly precious.” (Boag, 2008).  

Programmeurs hebben problemen met communiceren en ontwerpers zijn te trots en voorzichtig met hun ontwerpen. Boag heeft een oplossing voor het probleem. Zet iemand tussen deze twee verschillende karakters: “The kind of a person which is a bit left brain a bit right brain... People like that are fundamentally important in the process bridging that gap between designer and developer. To have those individuals to aid and facilitate communication.” (Boag, 2008). Door iemand als intermediair te laten functioneren die zowel de ontwerper als de programmeur begrijpt verloopt de communicatie soepeler en is er minder frustratie onderling. 

De meest belangrijke les die Boag geleerd heeft in de samenwerking tussen ontwerper en programmeur is de volgende: “The need to respect the skills of both parties. That both parties have unique characteristics and personalities and skill sets. It's very easy to focus on the weaknesses of those two different skill sets when actually we need to be focusing on their strengths and posibilities.” De nadruk moet liggen op de positieve aspecten van de verschillende karakters. Boag geeft het volgende advies: “Try living in the other persons shoes for a few days. Try doing some programming if you are a designer and if you are a developer try building a user experience.” (Boag, 2008). Op deze manier krijgen beide partijen meer begrip voor elkaar en het werk dat zij doen.  

2.2 Christian Heilmann

Christian Heilmann is een ontwikkelaar van de meest bezochte website in Amerika, Yahoo. Hij heeft meerdere malen op conferenties gesproken. Zo heeft hij onlangs meegedaan in een debat welke specifiek gericht was op de verschillen tussen de ontwerper en de programmeur en hoe de samenwerking tussen deze tegenpolen verloopt. 

Heilmann ziet zichzelf meer als een programmeur ondanks dat hij in het verleden ook websites ontworpen heeft. “I used to do design, but even when I was a designer I did it in a structural way. I actually strive at being creative with boundaries. Give me a technical boundary and I will get the best out of it. If you just tell me: 'make me a logo that is really pushing the enveloppe in this and that direction' I would just stand there like, no that's not me.” (Heilmann, 2008). Zelfs als ontwerper is Heilmann gestructureerd. Hij werkt graag met technisch definieerbare grenzen. Wanneer het te abstract en visueel wordt haakt hij af. 

Heilmann omschrijft de kwaliteiten die hem tot een programmeur maken. Deze kwaliteiten zijn volgens hem essentieel voor een programmeur: 

“It's definitely structural thinking, and it's definitely thinking your way in a very abstract model which is not available in nature... [I]t's a matter of being open to this very complex and theoretical things. To me it's also a matter of laziness. A really good developer is cleverly lazy he or she doesn't want to do things twice. They want to do them once, and right... [U]se technology as a tool for things you don't want to do as a human being.” (Heilmann, 2008). 

Het is een soort van luiheid. Een goede programmeur is lui en wil iets maar één keer doen. Dus die ene keer moet het goed gebeuren.  
 

Heilmann gelooft dat de hersenen van een programmeur op een specifieke manier gestructureerd zijn, zodat zij abstracte dingen beter te begrijpen: “There has to be a certain affinity to these kind of things. [W]e are all wired in different ways in which we understand things.” (Heilmann, 2008). Zo zijn de hersenen van een ontwerper en programmeur op een verschillende manier gestructureerd. 
Heilmann is het eens met de observatie van Boag. Het verschil tussen een ontwerper en een programmeur zit hem onder andere in de mate van het vasthouden van aandacht. “A programmer will do something once, will remember it for the rest of their lives. Where as a designer approaches the problem always from different angles.” (Heilmann, 2008). Zoals Heilmann aangeeft doet een programmeur iets liever maar één keer. Een ontwerper doet alles meerdere keren, maar bekijkt het dan vanuit verschillende invalshoeken.

Een anders verschil is de mate van diepte “Designers are much more human focused than most programmers are. That's why a lot of programmers are bad in building human interfaces. A designer will actually see how they can take something and convery the message of it to users. A programmer would take something, analyze it and take it apart. They try to understand what is going on.” (Heilmann, 2008). Als voorbeeld gebruikt Heilman de manier waarop een gedicht geïnterpreteerd wordt: “If you show a nice poem to a designer and they will start talking about the metaphors and how the meaning of it comes through. If you show a poem to a programmer it will say like: “well there are five rhymes and two verses and so forth” (Heilmann, 2008). De manier waarop de ontwerper en programmeur iets interpreteren verschilt hevig van elkaar. De kans dat deze twee dan met elkaar botsen lijkt groot. Heilmann heeft hier echter niet zulke grote problemen mee. 

Over het algemeen vindt Heilman, als programmeur, de samenwerking met een ontwerper heel vruchtbaar. Hij vertelt over verschillende projecten waaronder visitbritain.co.uk. Visitbritain.co.uk is een portal voor toeristen die Groot Britannie bezoeken. Hij zegt hierover: “I basically talk to the designers about what's technically feasible, what can be done and what can not be done. And what makes sense for usability as well for blind people and people with disabilities.” (Heilmann, 2008). Ondanks het feit dat de communicatie over het algemeen soepel verloopt erkent Heilman dat de communicatie soms lastig kan zijn:

“Just because the designer and the developer are so differently wired it is very tricky. A lot of times it's because of wrong assumptions from both sides. A lot of designers come from a print background and think they have the same control over the web, They don't, On the internet the interface belongs to the user... [T]he fundamental problem is that a lot of designers I had problems with saw their envirionment as the internet. So they had computers with high resolution screens and basically said: 'We can put this amout of information in, that is no problem what so ever.' They basically don't realize the final experience of the internet is very much depended on the other side that you don't know about. You don't know the computer, you don't know the screen, you don't know if that person is blind, you don't know if that person needs larger font sizes.” (Heilmann, 2008).

Aan de ene kant hebben de ontwerpers een bepaalde affiniteit met de eindgebruikers maar aan de andere kant zien zij de omgeving waarin zij werken als de omgeving waarop de eindgebruiker de website benadert. 

Ook zouden de ontwerpers koppig zijn, zij zouden immers niet door hebben hoeveel extra programmeer werk het kost om een klein grafische aanpassing te doen: “It's hard to transpire to a designer what a little change in graphical design means in terms of code.” (Heilmann, 2008). Bijvoorbeeld wanneer een ontwerper een bepaalde functie voor een website verzint. Deze wordt aan de klant getoond die er erg blij is met deze functie. De ontwerper gaat enthousiast naar de programmeur toe die dan van de programmeur te horen krijgt dat de functie niet gebouwd kan worden in het huidige technologische systeem dat gebruikt wordt. 

Een moeizame communicatie heeft echter niet alleen te maken met de verschillende karakters. Het heeft volgens Heilmann ook te maken met de hiërarchie binnen het bedrijf: 

 “It's about hierarchy in the company. I've never had a problem with junior designers who wanted to proof themselves. I had a problem when somebody was already head of design for several years and didn't want to change their ways and saw the company guidelines as the most important thing even if it was completely inapplicable to the media they tried to apply it to. New people are a lot more open and try to get their job done instead of trying to get their agenda through.” (Heilmann, 2008). 

Het gaat ook om de functie binnen het bedrijf. Een vastgeroeste ontwerper die hoofd is van een afdeling is veel koppiger dan een jonge ontwerper die open staat voor verandering.

Zoals Boag al aangaf komt ook Heilman met het argument dat de ontwerper en de programmeur meestal met hetzelfde probleem zitten maar een totaal verschillende taal met elkaar spreken: “A lot of times we have the same problem. We just don't communicate in the same way.” (Heilmann, 2008). De oplossing die Heilmann hiervoor heeft is als volgt:  
“I give [the designer] kudos from the beginning. I see you as the person who knows how to build interfaces to communicate with human beings. I'm the guy who can tell you how to do that technically, let's work together.” Heilman geeft dan ook het volgende als advies om de communicatie te versoepelen: “Understand what each other do. Look over each others shoulders and ask about their passions. Why are you a designer and why are you a programmer? Then you understand the human behind the deliverer. And to show respect for each other. If that guy says it can't be done then it can't be done. Give reasosn for your problem. People just say no, but they don't say why.” (Heilmann, 2008). 

Opvallend is dat Heimann hetzelfde advies geeft als Boag. Neem eens een kijkje in de keuken bij de ander. 

2.3 Jeffrey Zeldman

Zeldman is de directeur van het webdesign bureau Happy Cog, een bedrijf dat hij zelf heeft opgestart. Eén van zijn taken is het maken van ontwerpen en deze omzetten naar HTML en CSS code. Het grootste deel van zijn tijd is hij bezig met het aansporen van werknemers en het praten met klanten, ontwerpers, informatie architecten en schrijvers. Tevens werkt hij 
samen met een partner aan een conferentie. Hij ziet zichzelf als representatief voor een ondernemer van een middenklein webdesign bureau. Hij is steeds minder bezig met het ontwerpen en ontwikkelen van websites. Zo geeft Zeldman aan dat: “Five years ago I might have been more of a 'in the trenches' designer/developer.” (Zeldman, 2008).  

Zeldman is net zoals Boag en Heilmann begonnen met het verkennen van zowel het ontwerpen als het programmeren. Toch ziet hij zichzelf meer als een ontwerper:  

“I'm more like a designer who learned programming by necessity. My brain isn't as logical as a good programmer's brain would be. I understand things intuitively. I sometimes get the big picture but I'm missing the details. Details are very important for a designer but details are really really critical for developers.” (Zeldman, 2008). 

Zeldman begon als een journalist en raakte geïnteresseerd in het web. De onderliggende code werd voor hem boeiend. Niet zozeer door het gebruik van de syntax, maar omdat het mooi zou zijn om een ontwerp te kunnen beïnvloeden door middel van de code. Veel verder dan het gebruik maken van de code in dienst van het ontwerp gaat Zeldman dan ook niet: “Designers code is what I love... If I could just do it all the time in a text editor, than I would.” (Zeldman, 2008). Helaas is dit niet mogelijk door de huidige beperkingen van de technologie waarmee websites gemaakt worden. Ondanks het feit dat het bezig zijn met code voornamelijk gezien wordt als een taak voor de programmeur geeft Zeldman aan dat het werken met code zeer zeker ook ontwerpen kan zijn. 

De grens tussen een ontwerper en een programmeur is dus vager bij Zeldman. Hij gaf eerder aan dat het cruciaal is voor een programmeur om logisch te kunnen denken, maar welke kwaliteiten acht hij voor een ontwerper cruciaal?

“I think there is to some extend an eye. Some of it is it's capability in just taste. Knowing that one thing looks better than an other. The rest of it is really understanding what design is for that it is to communicate and facilitate. To communicate ideas and to facilitate activity.” (Zeldman, 2008). 

De ontwerper moet de vaardigheid bezitten om een bepaalde taak te faciliteren door middel van een website: “Im in a site I have never been in before and yet I quickly understand what kind of content I'm being presented with. ” (Zeldman, 2008). 

Volgens Zeldman is deze taak echter niet uitsluitend weggelegd voor de ontwerper. Zeldman praat over hybride karakters en vervaagt daardoor de grens tussen ontwerper en programmeur: “I think there are a lot of hybrids. I think there are people in our medium who like to say they are one or the other but can do both....[I]t's more like a percentage.” (Zeldman, 2008). Er is geen harde scheiding, het is beter in percentages uit te drukken. Iemand kan dus voor 20% ontwerper zijn en voor 80% programmeur. Zeldman geeft het voorbeeld van zijn collega Eric Meyer. Meyer ziet zichzelf niet als een ontwerper, maar is volgens Zeldman toch in staat om prachtige dingen te creëren: “Eric would never call himself a designer. But he made this really beautiful timeline the other day. He made really simple mark up and then he styled it. The thing is gorgous.” (Zeldman, 2008). Ondanks dat Meyer zichzelf als een programmeur ziet is hij toch in staat Zeldman te imponeren. Zeldman vindt dat het over het algemeen niet zo zwart wit is, maar in sommige gevallen is de tegenstelling juist wel erg groot: “I was the creative director at one place where there was a rigid seperation and they keep making me hand my compositions to a HTML person and not saying anything to him about how he was doing it.” (Zeldman, 2008). Het gaat voornamelijk om de structuur en inrichting van het bedrijf: de ontwerpers en de programmeurs worden van elkaar gescheiden. Ze hebben geen interactie met elkaar. Deze bedrijven hebben volgens Zeldman: “A less advanced understanding of the medium... [T]here isn't a whole lot of shared understanding.” (Zeldman, 2008). In deze situaties wordt een website dan ook meestal gezien als een scherm, een plaatje. Het wordt niet gezien als een dynamische omgeving waar de gebruiker interactie mee moet hebben. 

Maar hoe zorg je er in deze situatie dan voor dat ontwerpers en programmeurs met elkaar gaan communiceren? Volgens Zeldman komt de oplossing niet van bovenaf, dus niet vanaf de directie, maar moeten de ontwerpers en programmeurs het onderling oplossen: “If you're in a corporation where you in a rigid segmentation and your boss doesn't even want you to talk to those people. You probably have to do things like: 'Hey you guys want to go out for a coffee?'.” Zeldman adviseert om op een informele wijze een gesprek met elkaar aan te gaan over het project. Zeldman impliceert hier dat de scheiding tussen de ontwerper en programmeur voornamelijk vanuit de hiërarchische structuur van een bedrijf bepaald wordt. Maar hoe zit het met de scheiding tussen de denkwijze van de ontwerper en de programmeur? Als deze een informeel gesprek met elkaar aangaan, verloopt de communicatie dan wel soepel? Is het dan een mythe dat de karakters botsen? “No. It's not a myth...[W]hen people are segmented in these different groups then the developers are like: 'You know, these idiot designers they bring me these photoshop files it 1200 pixels wide! That's not even an audience we can serve!” (Zeldman, 2008). Volgens Zeldman is communicatie tussen deze twee groepen belangrijk: “Thinking outside your special area, what you already know, and how can I explain: 'This designer just gave me an idea that isn't great. How can I tell this person who doesn't know anything about user experience that a 200 pixel square pop up is a bad idea.' A lot of it is maturity and learning how to work with others.” (Zeldman, 2008). 

Zeldman geeft advies om de communicatie te versoepelen: “Try to understand as soon as they do something wrong. Try to explain this from your knowledge area in a way that includes them.” (Zeldman, 2008). Zeldman vergelijkt het met communicatie met zijn dochtertje. “I know a lot of things she doesn't know. How can I explain this to my daughter in a way she understands and make her feel good about learning something.” (Zeldman, 2008). Een programmeur weet veel over zijn eigen kennisgebied en moet daarom proberen te vertalen voor een ontwerper waarom iets wel of niet werkt. Hetzelfde geldt voor de ontwerper. “Don't assume that they're ignorant or bad because of their different knowledge area.” (Zeldman, 2008).  

Is het met deze aanpak dan alsnog onvermijdbaar dat de ontwerper en programmeur met elkaar botsen door hun verschillende karakters? “It is inevitable but another way of looking at it is: A costume designer, a cinematagropher, a composer and a screenwriter all have different talents somehow they come together and make a movie. [Y]ou don't look at it as here is this stubborn person who is preventing me from realising my vision but you make it about us.” 

Nu de theorie vanuit drie verschillende perspectieven belicht is, is het interessant om te kijken naar de verschillen en overeenkomsten in de bevindingen.

3. Conclusie

In hoofdstuk één is duidelijk geworden dat er mensen zijn die voornamelijk met hun linkerhersenhelft denken en dat er mensen zijn die voornamelijk met hun rechterhersenhelft denken. Deze manier van denken heeft invloed op de voor hun karakteristieke eigenschappen. Zo is duidelijk geworden dat programmeren weggelegd is voor de mensen die voornamelijk met hun linkerhelft denken en dat het ontwerpen beter geschikt is voor de mensen die voornamelijk met hun rechterhelft denken. Ondanks deze verschillen is het binnen de webdesign industrie belangrijk dat de programmeur en ontwerper een goede wisselwerking met elkaar hebben om zo tot een geslaagd eindproduct te komen. Communicatie is hierin een belangrijk punt.  

Daarom is er in hoofdstuk twee aandacht besteed aan een drietal interviews die afgenomen zijn met enkele prominente figuren binnen de webdesign industrie. Hoe ervaren zij deze scheiding tussen ontwerper en programmeur. Hoe verloopt de samenwerking en tegen welke problemen lopen zij op? Hoe worden deze problemen opgelost? In de conclusie worden de bevindingen op de onderstaande vragen toegelicht. 

• In hoeverre is er een scheiding tussen de ontwerper en programmeur?
• Hoe verloopt de samenwerking tussen de ontwerper en programmeur?
• Wat voor problemen ontstaan er en hoe worden deze opgelost?

3.1 In hoeverre is er een scheiding tussen de ontwerper en programmeur?

Wat direct opvalt bij het analyseren van de gegevens van de interviews is dat zowel Boag, Heilman en Zeldman begonnen zijn met zowel ontwerpen als programmeren. Zij hebben alle drie beide terreinen afgetast, maar kwamen al snel tot de conclusie welk onderdeel hen beter lag. Hier komt dan ook meteen de scheiding tussen links en rechts naar voren. Boag vertelt dat hij niet georganiseerd genoeg is om een programmeur te worden. Zeldman geeft ook aan dat hij niet logisch genoeg is om een programmeur te zijn terwijl Heilman aangeeft dat hij zelfs het ontwerpen op een zeer gestructureerde manier deed. Uit de interviews blijkt dat deze personen onderkennen dat er een duidelijk verschil is tussen een ontwerper en een programmeur en dat dit voornamelijk komt door de manier waarop de hersenen ontwikkeld zijn. De programmeur heeft voornamelijk een gestructureerde werkwijze en een groot analytisch vermogen. De ontwerper heeft een goed oog voor visuele details.

Het verschil tussen de programmeur en ontwerper zit hem volgens Boag voornamelijk in de manier waarop ze hun aandacht kunnen houden bij projecten. Een ontwerper gaat snel van het ene naar het andere project, terwijl een programmeur zich juist heel lang op één bepaald detail kan focussen. Heilmann is het eens met deze bevinding. Volgens hem doet een programmeur iets maar één keer en probeert hij het dan ook zo goed mogelijk te doen. Een ontwerper benadert een probleem vanuit verschillende perspectieven. 
Er is een scheiding tussen een ontwerper en een programmeur. Beide denken op een verschillende wijze en zijn daarom beter geschikt voor het specifieke werk dat zij doen. 

3.2 Hoe verloopt de samenwerking tussen de ontwerper en programmeur?

Er is een duidelijk verschil tussen de ontwerper en de programmeur. De vraag is echter in hoeverre dit invloed heeft op de samenwerking. Boag erkent dat de samenwerking een uitdaging kan zijn, maar deze is niet per definitie problematisch. Heilman ziet de samenwerking als iets vruchtbaars. Zeldman geeft aan dat de samenwerking afhankelijk is van de hiërarchische structuur van het bedrijf. Zodra er binnen een bedrijf een duidelijke scheiding tussen de ontwerpers en de programmeurs gemaakt wordt, vertaalt dit zich ook in de samenwerking. Heilmann ziet het probleem ook in de hiërarchie van een bedrijf, maar legt de nadruk meer op de positie van de ontwerper. Een junior ontwerper staat volgens hem eerder open tot nieuwe ideeën, dan een vastgeroeste senior developer. Boag ziet het probleem voornamelijk voor de manier waarop het project gestructureerd is, wanneer de ontwerper en programmeur gescheiden benaderd worden in plaats van deze te laten samenwerken.  

Opmerkelijk is dat er niet zo zeer gesproken wordt over de verschillende karakters van de twee maar dat deze scheiding voornamelijk problematisch is wanneer deze wordt gevormd door het project of het bedrijf waarin de twee groepen moeten samenwerken. Het idee dat de ontwerper en de programmeur verschillend zijn wordt dus niet noodzakelijk problematisch door de verschillende karaktereigenschappen maar door de manier waarop een bedrijf of project gestructureerd is en omgaat met deze scheiding. Het verloop van de samenwerking is grotendeels afhankelijk van deze gestructureerde scheiding. 

3.3 Wat voor problemen ontstaan er en hoe worden deze opgelost?

De problemen zijn niet geheel af te schuiven op de structurering van een bedrijf of project. De ontwerper en programmeur hebben zeer verschillende karaktereigenschappen die de communicatie soms moeizaam maken. Boag ziet dit probleem vaak terugkomen wanneer de ontwerper en programmeur een totaal verschillende leefwereld hebben. De programmeur is over het algemeen geen wonder in het communiceren met andere mensen. Bijvoorbeeld wanneer de ontwerper een idee aandraagt aan de programmeur die dan aangeeft dat dit niet mogelijk is. Wat de programmeur eigenlijk bedoelt is dat het wel mogelijk is, maar niet op de manier waarop de ontwerper het voorstelt. Aan de andere kant kan de ontwerper nogal te trots zijn op zijn eigen werk, aldus Boag. Dit maakt de ontwerper koppig en deze staat niet altijd open om zijn 'kunstwerk' aan te passen aan de grillen van de techniek die de programmeur hanteert. Heilmann ziet dit eerder als kortzichtigheid van de ontwerper. De ontwerper is zich niet bewust van het programmeerwerk dat gepaard gaat met een grafische aanpassing aan het ontwerp.  

De ontwerper en de programmeur leven dus wel degelijk in twee verschillende werelden, ongeacht of deze vanuit een hiërarchische bedrijfscultuur bepaald wordt. Dit is een probleem wanneer de ontwerper en programmeur moeten samenwerken, omdat dit de communicatie tussen beide partijen gecompliceerd maakt. 

Over de oplossing zijn zowel Boag, Heilmann en Zeldman het eens. Het is belangrijk om kennis te hebben van de werkzaamheden van de andere partij. Een ontwerper moet zich inleven in de programmeur en vice versa. Boag geeft aan dat er meer aandacht gevestigd moet worden op de gebundelde krachten en mogelijkheden in plaats van de individuele zwakheden. Boag adviseert de ontwerper om eens wat programmeerwerk te doen en de programmeur moet eens eens iets ontwerpen. Heilmann geeft aan dat de ontwerper en programmeur over het algemeen met dezelfde problemen zitten, maar dit op een verschillende manier communiceren. Heilmann laat als programmeur meteen merken dat hij respect heeft voor de ontwerper. Plaats een ontwerper of programmeur niet in een hokje, maar probeer de persoon achter de titel te zien. Zeldman geeft aan dat je moet proberen een probleem vanuit je eigen ervaring en kennis uit te leggen. Je moet niet aannemen dat iemand dom of onwelwillend is, puur omdat zij een verschillende achtergrond hebben. De communicatie tussen de ontwerper en programmeur kan een probleem zijn. Echter is dit probleem niet onoverkoombaar. Zeldman maakt een treffende vergelijking met de Hollywood Industrie. Er is een kostuumontwerper, een cinematograaf, een componist en een scenarioschrijver met elk totaal verschillende talenten. Op de een of andere manier lukt het ze toch om gezamenlijk een product te maken.

3.4 Vervolgonderzoek 

Wat naar voren kwam in dit onderzoek maar wat onderbelicht is gebleven is de manier waarop er een hybride vorm ontstaat tussen de ontwerper en de programmeur. Zoals aangegeven in het advies voor mogelijke oplossingen, moeten zowel de ontwerper en programmeur zich begeven op het terrein van de de ander. In hoeverre gebeurt dit en wat voor implicaties heeft dit voor de webdesign industrie? Ook is gebleken dat de scheiding onder andere door de structurele indeling van een project versterkt kan worden. Maar in hoeverre gebeurt dit precies en hoe kan dit vanuit de bedrijfscultuur voorkomen worden? 
Websites vormen een groot deel van onze alledaagse communicatie. Het is daarom belangrijk om kritische vragen te blijven stellen bij de totstandkoming van deze websites. Daarbij is de samenwerking tussen de ontwerper en programmeur cruciaal. Het is daarom van belang om deze samenwerking te blijven onderzoeken en te evalueren. 

Literatuur

• Blakeslee, Thomas R.. The Right Brain: A New Understading of the Unconscious Mind and Its Creative Powers. Londen: The MacMillan Press LTD, 1980. 
• Boag, Paul. Skype interview. 5 Feb 2008. 
• Heilmann, Christian. Skype interview. 5 Feb 2008. 
• Pink, Daniel H.. A Whole New Mid: Why Right-brainers WIll Rule the Future. New York: Riverhead Books, 2005. 
• "What is a designer?." Design Institute of Australia. Design Institute of Australia. 28 Feb 2008 <http://www.dia.org.au/content.cfm?id=186>. 
• Zeldman, Jeffrey et al. "Findings from the Webdesign Survey 2007." A List Apart. 16 Oct 2007. A List Apart. 28 Feb 2008 
• <http://www.alistapart.com/d/2007surveyresults/2007surveyresults.pdf>. Zeldman, Jeffrey. Skype interview. 21 Feb 2008.