In de meeste ontwerpdisciplines is de werkvolgorde duidelijk. Je doet onderzoek, vervolgens ga je schetsen, daarop volgt uiteindelijk een definitief ontwerp en dat gaat naar de producent. Ontwerp je drukwerk? Als je bestanden bij de drukker liggen ben je klaar!

En zo was het tot het een paar jaar geleden voor webontwerpers ook: je werkte in een tekenprogramma en na goedkeuring ging er een pakket plaatjes over de schutting naar de bouwer. Die werkwijze (vaak ‘waterval’ genoemd) heeft zeker voordelen: het proces is helder en de taken zijn lekker duidelijk afgebakend. Maar er zijn ook nadelen.

Interactie

Interactie is moeilijk over te brengen in een set statische plaatjes. Het leidt tot gesprekken als “Wanneer je dit invult, gebeurt er dat” en “Als je op deze knop klikt, zie je een animatie van een ronddraaiend pijltje”. Alle betrokkenen moeten hierbij flink wat voorstellingsvermogen hebben.

Het gaat er toch anders uitzien

In een ontwerpprogramma wordt je ontwerp anders op subtiele, maar belangrijke manieren. Tekst wordt niet exact hetzelfde gerenderd: het is bijvoorbeeld net wat groter of vetter dan in de browser. En over ‘de’ browser gesproken: die bestaat niet eens – in de ene browser kan je lettertype flink anders uitpakken dan in de andere. En daar kom je pas achter als je ontwerp al is goedgekeurd, en de site al bijna af…

Door tijdens het ontwerpproces te testen en eventueel een prototype te bouwen kun je deze nadelen redelijk ondervangen. Maar met de opkomst van responsive design kwam er een probleempje bij.

Responsive design: lastig!

Toen responsive design net opkwam was het niet ongewoon om voor 2 of 3 vaste schermgroottes te ontwerpen: ‘mobiel’, ‘tablet’ en ‘desktop’, bijvoorbeeld. En dat betekende flink wat extra werk voor de ontwerper! Voortaan gingen er 3 setjes ontwerpen over de verschillende schuttingen…

Dat was al niet praktisch. Maar inmiddels weten we dat een responsive site er goed uit moet zien bij elke schermgrootte. En dat betekent dat je aan iedereen (ontwikkelaars, opdrachtgever, collega’s enzovoort) moet gaan uitleggen wat er gebeurt tussen die 2 of 3 breekpunten. Het zou zelfs kunnen dat je de breekpunten niet wilt definieren per pagina, maar voor de verschillende elementen op elke pagina. Ga dat maar eens in plaatjes vangen.

Ik heb een tijd zo gewerkt, maar het beviel eigenlijk steeds minder.

Alternatieven

Als je niet alles kunt vastleggen in afbeeldingen, wat doe je dan? Het is een vraagstuk waar veel webontwerpers zich de laatste tijd over buigen. Een mogelijke oplossing is om heel nauw samen te werken met de ontwikkelaar – als het even kan letterlijk naast elkaar gaan zitten. Maar dat is niet altijd mogelijk.

Een andere oplossing die veel wordt genoemd, bijvoorbeeld door onze eigen Stephen Hay, is: ontwerpen in de browser – meteen je ontwerp uitwerken in HTML en CSS. Dat ligt niet per se voor de hand als jij als ontwerper niet verantwoordelijk bent voor het bouwen van de site. Maar ik ben het toch maar gaan doen, en dit zijn mijn ervaringen.

Voordelen

Je krijgt een realistisch beeld

Je werkt niet aan een benadering van het uiteindelijke product, maar aan het product zelf. Je ziet exact hoe een lettertype getoond wordt op verschillende browsers en apparaten, wat er gebeurt tussen verschillende breekpunten, kortom: hoe het ontwerp ‘voelt’ op elk apparaat. Het is ook makkelijker om te bekijken wat er gebeurt bij extremen: wat als het label op een knop heel lang wordt, of als de hoeveelheid tekst in een kadertje verandert?

Communicatie wordt makkelijker

Dingen die niet te tonen zijn op een statische afbeelding kunnen nogal eens tussen wal en schip vallen bij de oude manier van werken. Een subtiele animatie die je ziet bij een hover, bijvoorbeeld, of een parallax-effect bij het scrollen. Als je zelf verantwoordelijk bent voor die dingen wordt het niet alleen makkelijker om ze toe te voegen, maar de kans is ook kleiner dat je ze vergeet. Bovendien hoef je nu niet aan de ontwikkelaar in woorden uit te leggen wat je bedoelt.

Dit geldt natuurlijk ook voor de communicatie met je opdrachtgever. Die krijgt vroeger in het proces een helder beeld van hoe het gaat worden. En kan eventueel dus ook op tijd bijsturen.

Testen met gebruikers gaat beter

Mijn ervaring is: hoe meer het prototype lijkt op het eindproduct, hoe betrouwbaarder de test. En met klikbare HTML wordt testen tijdens het ontwerpproces sowieso makkelijker dan met losse afbeeldingen. Je kunt je ideeën dus betrouwbaar testen en de resultaten meteen verwerken in je ontwerp.

Happy accidents

Tenslotte denk ik dat het ontwerp weleens beter zou kunnen worden van het werken in het uiteindelijke medium. Je happy accidents komen voort uit de code zelf – het worden geen subtiele, maar moeilijk na te maken photoshop-effecten. Ik denk zelfs dat dat goed is voor het niveau van webontwerp in het algemeen.

Er zijn ook nadelen

Je moet beslissen op welk moment je naar code gaat

Je begint een nieuwe opdracht nooit meteen met ontwerpen in de browser. Er gaat een heel traject aan vooraf, met o.a. een onderzoeksfase en een schetsfase. Naast schetsen op papier werk ik nog steeds graag in een tekenprogramma om een moodboard en mogelijke layouts te schetsen. De vraag is: wanneer stap je over naar je code-editor? Ik werk nu vaak in beide programma’s tegelijk. Dat is misschien niet het meest efficient.

Het is aanlokkelijk om de makkelijkste oplossing te kiezen

Wat nog steeds het makkelijkst is in een tekenprogramma, is om meerdere oplossingen te schetsen en die naast elkaar te bekijken. In CSS is dat veel lastiger. Het wordt dan soms verleidelijk om de eerste de beste oplossing die ‘goed genoeg’ lijkt te kiezen. Maar daar wordt je werk niet beter van.

Je moet verstand hebben van front-end code

Ontwerpen in de browser werkt alleen als je als ontwerper behoorlijk goed bent in HTML en CSS. Je hoeft geen code te schrijven voor de uiteindelijke site, maar je moet wel elke layout die je bedenkt kunnen bouwen. Als je CSS niet goed genoeg is, worden je front-end capaciteiten de beperkende factor voor de kwaliteit van je ontwerp. Moet je dat willen, als ontwerper?

Waarschijnlijk heb je toch een ontwikkelaar nodig

En erger nog: als je fancy effecten of echte interactie wilt, heb je ook JavaScript nodig. Goede ontwerpers die alle ins en outs van JavaScript kennen zijn heel, heel zeldzaam. Kortom: vroeg of laat kom je vast te zitten en heb je de hulp nodig van een ontwikkelaar. En die ontwikkelaar is misschien nog helemaal niet beschikbaar, aangezien de bouw ‘officieel’ pas later begint. Dit vereist dus goed overleg!

Dus..?

Uiteindelijk is ‘ontwerpen in de browser’ natuurlijk onzin. Ontwerpen doe je ook in je hoofd, in gesprekken en op papier. Het werk op de computer – in de browser of een tekenprogramma – zal daar altijd maar een deel van zijn.

Ik denk wel dat een deel van dat werk onontkoombaar verschuift van tekenprogramma’s naar HTML en CSS. Voor ons werkt het goed, ook doordat onze ontwikkelaars niet op locatie werken. Ontwerpers die kunnen CSS’en zou ik het zeker aanraden. En anders is het een goede reden om CSS te leren!