De kloof
Fantastische websites en applicaties maken is een waar genot. En als zulke producten samenkomen is dat een nederigmakende ervaring. Vooral als je je realiseert dat je het niet alleen hebt gedaan. Teamwork is op zijn best als de leden van het team elkaar aanvullen en naar een gemeenschappelijk resultaat toewerken. Het is geen geheim dat webdesigners en -ontwikkelaars het niet altijd met elkaar eens zijn. Ze hebben vaak verschillende doelen met verschillende uitkomsten voor het product. Iets wat design engineers ‘De Kloof’ noemen.
Een goed ontwerper of ontwikkelaar zijn is uitstekend, maar het overbrugt niet echt de kloof. Ontwerpers die leren coderen of ontwikkelaars die ontwerpvaardigheden aan hun CV toevoegen helpen ook niet. Dus wat is deze kloof?
Een korte situatieschets
Een ontwerper vraagt de header op een bepaalde fontgrootte te zetten. Hij wijst naar het scherm. De ontwikkelaar draait terug naar zijn monitor en zet de header op de nieuwe grootte. Klaar is Kees. Koffie!
De ontwerper valt bijna uit z’n stoel.
Niet alle kopteksten!
En waarom is het lettertype veranderd?
De ontwikkelaar vertelt de ontwerper dat er in feite maar één header is om de waarde op in te stellen en dat die waarde in feite dus voor alle headers geldt. En als ze een uitzondering willen dan hadden ze er om moeten vragen. Als ze dat toevoegen zien ze geen verandering in het lettertype: “Het ziet er hetzelfde uit als het altijd al deed.”
Ontwerper: Maar dan willen we een uitzondering voor de koptekst en een oplossing voor het lettertype. Ontwikkelaar: Dus jullie willen een verandering met twee headers en een fix die we niet kunnen zien?
Zowel de ontwerper als de ontwikkelaar praten over hetzelfde en lijken te begrijpen wat er wordt gevraagd. Maar ze zijn allebei onzeker omdat hun begrip vanuit verschillende contexten komt. Hoe kunnen ze in hemelsnaam, met groeiende frustratie, het ontwerp overdragen om het constructief te laten coderen zonder tech of debt? Dit is, onnodig te zeggen, zeer vervelend en geen van beiden bereikt de andere kant van deze onzichtbare kloof.
Dit scenario is ook vergelijkbaar als ontwerpers en ontwikkelaars in aparte teams zitten of samen deel uitmaken van multi-functionele teams. Elke discipline heeft immers een eigen taal. We moeten onze verhalen, inzichten en doelen op een gedeelde en gestructureerde manier op elkaar afstemmen. Meestal hebben we daar wat hulp bij nodig.
Van een productconcept naar de levering aan gebruikers
Werken van strategische doelen via ontwerp naar het leveren van een gedeeld en beoogd eindresultaat aan gebruikers is gecompliceerd en heeft meer te maken met productmanagement dan met ‘user experience’. Dit is de reden waarom we DesignOps voor ogen hebben. DesignOps probeert bredere zakelijke doelen te verenigen zodat de ontwerper kan deelnemen in een aanpak van deze kwesties.
Ontwikkelaars schrijven code om gebruikers productfunctionaliteit te bieden. Zoals je je kunt voorstellen is ontwikkeling net als ontwerp een breed domein met veel subdisciplines. In de afgelopen jaren heeft automatisering van het ontwikkelproces een vitale rol gespeeld in verkorting van de doorlooptijd om functies snel bij gebruikers te krijgen. DevOps maakt dit mogelijk en is (niet verwonderlijk) een integraal onderdeel van elke moderne software-release procedure.
De kloof dichten
Wat meestal wordt gesuggereerd is dat we DesignOps moeten kruisen en overlappen met DevOps en ervoor zorgen dat beide hun werk afstemmen. Jammergenoeg werkt een verbreding van kennisdomeinen niet omdat er geen code-switch is, geen verandering in het verhaal. De kloof duidt eigenlijk op een ontbrekende rol.
Zie hier de design engineer. Deze begrijpt de output van de ontwerper om een oplossing te codificeren, te standaardiseren en zelfs te automatiseren.
Ontwerpers gaan van een idee naar een wireframe, een prototype, een logo, of zelfs alleen maar naar een tekening. Ontwikkelaars gaan van een probleem of functie naar een gecodeerde oplossing of implementatie die wordt vrijgegeven. Beide professionals zijn creatief en staan ten dienste van de gebruiker. De design engineer is ook creatief en schrijft code, maar vertaalt een ontwerp systematisch en gestructureerd naar implementatie.
Ik heb nog nooit ergens gewerkt waar er niet iemand was die deze kloof probeerde te overbruggen. Deze rol wordt vaak per toeval ingevuld en organisaties zijn zich totaal niet bewust van de behoefte. Recruiters hebben er nog nooit van gehoord en IT-adviesbureaus hebben de capaciteit niet in hun rooster. Wij noemen de rol nu “design engineer” omdat de kloof groeit en de rol te complex is geworden. Tijd voor de design engineer.
Wie is uw design engineer?
Over de auteur
Egor Kloos (/dutchcelt) is een front-end ontwikkelaar die ooit, in 1997, besloot van de grafische vormgevingswereld over te stappen naar de online wereld en al zijn inspanningen op het Web te richten. Aanvankelijk als ontwerper en nu als ontwikkelaar. In de loop der jaren heeft hij gewerkt als consultant voor startups, kleinere toegewijde klanten en grote multinationals. Hij ontwerpt, organiseert en bouwt het Web, pagina per pagina, site per site en portal per portal. Geen wonder dat hij graag aan Design Systems werkt.
Engineering (1)