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.

Techniek vs mensen

Een product design team, bijvoorbeeld een team dat nieuwe TV’s ontwerpt, bestaat van oudsher uit drie disciplines. Een interaction designer die nadenkt over wat de gebruiker met het ding moet kunnen doen. Een visual designer die nadenkt over hoe het ding er uit moet zien. En een developer die nadenkt over wat er allemaal mee mogelijk is, die onderzoekt waar de grenzen van de huidige techniek liggen. Een tijd geleden sprak ik eens met iemand uit het TV-design-team van Philips. Voor hem was het vanzelfsprekend dat deze drie disciplines samen aan een TV werkten. In de jaren tachtig wilden designers natuurlijk ook heel graag hele platte TV’s maken. En het zou ook heel eenvoudig zijn om prachtige prototypes te maken, van piepschuim ofzo. Maar hoe hard ze ook zouden willen, het was toendertijd gewoon technisch onmogelijk. Een TV had een beeldbuis en een beeldbuis was dik.

Magisch Design

Web design is product design. En je zou in een webdesign team dus ook dezelfde disciplines verwachten. Een interaction designer, een visual designer én een developer. Maar vreemd genoeg zitten er vaak geen developers in een webdesign team. En dat is natuurlijk raar.

Ik las laatst een paper uit 1997 over prototyping waarin staat dat er drie redenen zijn om een prototype te maken. En die komen overeen met de drie disciplines uit een design team. Ten eerste kan je een prototype maken dat onderzoekt wat een gebruiker precies moet kunnen. Zo’n soort prototype negeert vaak de visuele en technische mogelijkheden en beperkingen. Je kunt ook een prototype maken om te onderzoeken hoe iets er uit moet komen te zien. In zo’n geval negeer je de techniek en de gebruiker. En tot slot kan je een technisch prototype maken om te onderzoeken hoe ver de techniek tegenwoordig is. Hierbij spelen de gebruiker en de look and feel weer niet zo’n belangrijke rol. Deze prototypes maak je tegelijkertijd. Hierdoor krijg je een goed beeld van wat mensen willen, wat er kan en hoe het er idealiter uit kan zien. Met deze kennis kan je uiteindelijk een product gaan ontwerpen.

In de webwereld begint er hier en daar wel iets te veranderen, maar tot voor kort maakten we geen technische prototypes in webdesign teams. Wél wireframes om de behoeftes van de gebruiker te onderzoeken. En ook Photoshop mockups om te visualiseren hoe iets er uit moet komen te zien. Maar niks technisch. Geen enkele validatie. Ik sprak laatst met een designer die letterlijk tegen me zei dat ”alles kan met computers”; technische prototypes zijn dus niet nodig. Ik noem dit Magisch Design. Al onze fantastieën kunnen gewoon gemaakt worden, binnen elk budget, en ze werken gewoon supersnel en prettig op elk mogelijk apparaat omdat computers.

Liegen

Dit is zo naïef dat het bijna schattig wordt. Maar er is ook een cynischere reden waarom sommige art directors liever geen technische validatie vroeg in het designproces willen: een fantastisch opgepoetst Photoshop-prototype ziet er nu eenmaal prachtig uit. En klanten zijn makkelijker te overtuigen als je ze gouden bergen belooft. Mochten dingen onmogelijk blijken te zijn dan is dat een probleem voor later. Ik werkte ooit bij een bureau dat op deze manier ontwerpen verkocht en élke site die ik daar gemaakt heb draaide uit op een teleurstelling. De klant was niet blij omdat er niks overbleef van de beloofde gouden bergen. De ontwerpers waren niet blij omdat hun magische design niet bleek te werken. De developers waren niet blij omdat ze een onmogelijke opdracht kregen. En de bezoekers waren niet blij omdat ze alweer een slechte site aan het bezoeken waren.

Zonder technische validatie is een design geen design. Het is een fantasie. En een vervelende eigenschap van een fantasie is dat het beperkt blijft tot datgene wat jijzelf kunt bedenken. Grote kans dat daar niet alles tussen zit wat er tegenwoordig allemaal kan. De developer weet misschien wel dat er tegenwoordig briljante dingen zoals WebRTC bestaan. Of dat er tegenwoordig een File API bestaat. Of dat er meer en meer visuele filters worden toegevoegd aan browsers. Of dat de combinatie video en canvas bijzonder spectaculaire resultaten kan opleveren. Maar om te onderzoeken hoe goed deze nieuwe technieken allemaal in te zetten zijn voor een echte site moeten er prototypes gemaakt worden. Technische prototypes. Web design is product design. En in een product design team hoort naast een interaction designer en een visual designer ook een developer.

Comments

    • Sjors Pals
    • #

    Wow, goed geschreven, ik wil het misschien nog wel aansterken met het feit dat UX ontwerpers en Designers vaak niet op de hoogte zijn van technologische mogelijkheden waardoor ze juist bepaalde zaken niet in hun ontwerp/design opnemen, terwijl sommige “frutsels” vaak tot onnodige frustraties bij techniek leiden.

    Beste voorbeeld was denk ik nog wel een website waarbij op de homepage ook een overzicht stond van best gelezen artikelen, waar een overzicht van meest recente artikelen technisch een eitje had geweest zorgde het best gelezen element ervoor dat ik naast het bestaande systeem een aparte database moest gaan bijhouden met daarin statistieken, dat aan de voorkant een complexe query moest plaatsvinden om de best gelezen artikelen uit het CMS te filteren, en bovenal dat het caching systeem ook anders moest werken omdat de cache laag niet interactief is, en dus ook geen view counts kan bijhouden. Kortom deze kleine feature zorgde voor 60 uur meer werk, uren die veel beter aan mooie features besteed hadden kunnen worden wanneer er van te voren afgestemd had geweest hoe moeilijk zo iets was. Gelukkig zie ik in pitches wel dat er steeds meer technisch gevalideerd word zodat er geen “foute” dingen beloofd worden.