Hoe designers en developers écht kunnen samenwerken: ideeën uit de praktijk

Designers en developers hebben heel verschillende taken in het ontwikkelingsproces van een applicatie. Effectief en productief samenwerken is niet altijd eenvoudig. Volgens mij kan het beter: mijn ideeën op basis van twintig jaar praktijkervaring.

Ik begon mijn carrière als een one-man band: een digital designer die alles in zijn eentje ontwierp en ontwikkelde. Dit gaf me totale controle, maar het maakte de projecten die ik aankon ook vrij beperkt. En soms was het ook gewoon eenzaam. Dus begon ik te dromen. Dromen over samenwerken. Over geweldige producten maken, met andere mensen, als een team.

Fast forward naar 20 jaar later: ik ben onderdeel van een multidisciplinair team bij een digital agency. Samen met andere strategen, designers en developers ontwikkelen we complexe applicaties voor allerlei opdrachtgevers. Maar werken we ook écht samen? Stuwen we elkaar op naar grote nieuwe hoogten? Of slepen we het project voort, van de ene afdeling naar de andere? Een beetje van beiden ben ik bang. Dus dat kan beter, toch?

Samenwerken is moeilijk!

Digitale producten worden gemaakt door designers en developers. Samenwerking tussen hen lijkt daarom misschien vanzelfsprekend. Maar dat is het niet altijd. Hoe komt dat?

Een lineair proces

Gewoonlijk is het creëren van een nieuw digitaal product een lineair proces. Het begint met onderzoek, gaat over naar ontwerp en op basis daarvan wordt het eindproduct geprogrammeerd. Door dit lineaire proces ontstaat het gevaar van werken in silo’s, het werken op je eigen eilandje. De designers gooien het ontwerp over de schutting bij de developers, en beginnen vervolgens aan het volgende project, hun ontwerp en de developers aan hun lot overlatend.

Agency life

Werken bij een agency kan de silo-aanpak versterken. Hoeveel ik ook houd van de dynamiek en variatie van mijn ‘agency life‘, het maakt het ook moeilijker om iedereen bij alle fasen van een project betrokken te houden. De beschikbare tijd die je aan een project kunt besteden is altijd beperkt door een budget. Soms worden mensen naar een ander project verplaatst om de planning sluitend te krijgen. Mensen kunnen tegelijkertijd aan verschillende projecten werken, waardoor hun focus verslapt. Designers zijn misschien al begonnen aan het volgende project, terwijl de developers proberen de ontwerpen om te zetten in een werkend product.

1:6 verhouding

Het maken van digitale producten heeft over het algemeen een verhouding van ongeveer 1:6 tussen design- en development-tijd. Dit betekent dat de ontwikkelfase altijd veel langer is dan de ontwerpfase. En doordat het ontwerpen meestal ook nog eens aan het begin van een project plaatsvindt, gaat development door, lang nadat het ontwerp is afgerond. Het vraagt dus veel extra commitment van designers om betrokken te blijven tijdens de ontwikkelingsfase, wanneer ze misschien het gevoel hebben dat hun werk al gedaan is en andere projecten hun aandacht opeisen.

Ontwikkelaars komen van Mars, ontwerpers van Venus?

Ik kan prima overweg met developers. Maar developers en designers komen toch een beetje van twee verschillende planeten. En ze hebben verschillende rollen. Ik vind dit geweldig, en het draagt ​​bij aan de kwaliteit van het eindresultaat, maar het vergt wel enige inspanning van alle betrokkenen om elkaars standpunten te zien, te respecteren en op de juiste manier te combineren.

Samenwerken is fijn!

Als samenwerken zo moeilijk is, waarom zouden we er dan energie in steken? We leveren nu toch ook producten op? Wat hebben we aan een betere samenwerking?

Gedeeld eigenaarschap

Een betere samenwerking tussen designers en developers leidt tot een gedeeld eigenaarschap van het project waaraan ze werken. Developers zullen de overwegingen en beslissingen begrijpen die hebben geleid tot een bepaald ontwerp. Designers zullen de afwegingen en beslissingen begrijpen die nodig zijn om een ​​werkend product binnen tijd en budget te ontwikkelen. Designers, vaak verantwoordelijk voor de productvisie, kunnen op basis van die visie ook helpen samen de juiste afwegingen te maken.

Meerdere perspectieven

Meerdere perspectieven leiden tot een beter eindproduct. In mijn ervaring is elk nieuw perspectief waardevol, maar de perspectieven van designers en developers zijn éxtra waardevol.

Door developers bij het ontwerpproces te betrekken, kan de designer worden gewezen op nieuwe technische mogelijkheden die het eindproduct beter kunnen maken. Het beschermt de designer ook tegen het ontwerpen van dingen die misschien te moeilijk te implementeren zijn. Door designers bij het ontwikkelingsproces te betrekken, zorg je ervoor dat de productvisie niet over het hoofd wordt gezien en dat de ontwerpen volledig worden begrepen door het ontwikkelteam. Het maakt het ook gemakkelijker om ontwerpdetails, als dat nodig is, direct aan te passen om het ontwikkelingsproces te versnellen.

Echte samenwerking mogelijk maken

Ik denk dat het mogelijk maken van echte samenwerking tussen designers en developers draait om het creëren van het juiste startpunt en het juiste proces om samen te werken.

Een gedeelde productvisie

Het is misschien voor de hand liggend, maar het creëren van een goed product begint met een duidelijke visie. Vaak is dit iets wat strategen en designers bepalen. Door developers bij dit proces te betrekken, creëren we een gedeelde visie die zorgt dat we elkaar beter begrijpen en beter kunnen samenwerken.

Waar gaan we naartoe?

Het maken van een roadmap aan het begin van een project draagt bij aan de gedeelde productvisie. Door samen met designers en developers de roadmap te maken, is het gemakkelijker om verschillende features van een product af te wegen en hun impact op verschillende stadia van de productontwikkeling te zien.

Focus op de eindgebruiker

Om samen te werken moeten we elkaar dus begrijpen. Designers proberen de afwegingen van developers te begrijpen, en omgekeerd. Maar wat als je verschillende meningen hebt en het gewoon niet met elkaar eens bent? Guess what? Je mening doet er niet toe! Uiteindelijk gaat het om de eindgebruiker van het product dat je maakt. Door de eindgebruiker, door middel van bijvoorbeeld interviews of gebruikerstest, bij het creatieproces te betrekken – ik vind de ideeën daarover in Continuous Discovery Habits erg goed – kun je verder kijken dan een bepaalde mening, en een product creëren dat je eindgebruiker wil gebruiken.

Productteams

Agencies denken vaak nog steeds in designteams en development-teams. Dit bevordert het silo-denken. Vanuit het oogpunt van de samenwerking zou het beter zijn om in plaats daarvan productteams te hebben. Maar binnen agencies is dit vaak een uitdaging. Aangezien agencies uren verkopen, is het verleidelijk om mensen veel tussen verschillende projecten heen en weer te schuiven, om zo de ‘optimale’ planning te maken, de optimale planning voor het boeken van uren om precies te zijn. Samenwerking kan in dat proces verloren gaan.

Veel van deze suggesties wijzen in dezelfde richting:

Een niet-lineair proces

Je kunt een ontwerp te maken, het bij development over de schutting te gooien, en vrolijk aan je volgende project beginnen. Maar wat als design en development parallel zouden plaatsvinden? Dan zouden designers en developers echt kunnen samenwerken, en elkaars inzichten direct kunnen implementeren.

Ontwikkelaars gebruiken toevallig al zo’n niet-lineair proces: Scrum. Wat als we design ook in dat proces zouden kunnen integreren? Zoals je waarschijnlijk weet deel je bij Scrum een project op in kleine stukjes, user stories genaamd. Een user story is een onderdeel van een project dat een lid van het projectteam zelfstandig kan afmaken. Samen bepaalt het team in welke volgorde aan de user stories wordt gewerkt. Hierbij gebruiken ze natuurlijk ook de inzichten die ze hebben gekregen door de user stories waar ze eerder aan hebben gewerkt.

Designers zouden eerst het ontwerp voor een user story kunnen maken. Als het ontwerp klaar is, kunnen developers deze user story oppakken en integreren in het product. Designers werken ondertussen aan de volgende story. Zo werken designers niet (te) ver voor development uit, maar blijven beide processen dicht bij elkaar. Hierdoor is het makkelijker en vanzelfsprekender feedback op elkaars werk te geven en te verwerken.

De uitdaging hierbij is dat design fundamenteel anders is dan development. Wanneer een development-team begint met development, moeten in ieder geval de contouren van het product duidelijk zijn. Dit maakt het mogelijk om het project op te splitsen in de user stories die nodig zijn voor het Scrum-proces. Design gaat juist over het creëren van deze contouren. Het probleem onderzoeken, een oplossing bedenken, deze oplossing testen, verbeteren, totdat het product voldoende gedefinieerd is voor development om te gaan bouwen. Zeker de start van dit proces is erg moeilijk op te splitsen in de user stories die nodig zijn voor Scrum.

Een mogelijke oplossing hiervoor is het invoeren van een Sprint Zero. In Sprint Zero werkt het team nog niet aan user stories. In plaats daarvan wordt de basis voor een product gelegd. Voor design betekent dit het creëren van de contouren van het product zoals hierboven beschreven. Tegelijkertijd creëert development de technische contouren van het product: dingen als het kiezen van de juiste tech stack, het opzetten van de ontwikkelarchitectuur of het onderzoeken van mogelijke integraties met bestaande klantsystemen.

Conclusie

Er zijn allerlei praktische zaken die de samenwerking tussen designers en developers lastig maken. Maar als we echt willen kunnen die worden overwonnen. Bijvoorbeeld door het creëren en onderhouden van een gedeelde projectvisie en het verbeteren van onze processen. Misschien komen ontwerpers van Venus en ontwikkelaars van Mars, maar juist vanwege hun verschillende standpunten denk ik dat samenwerking tussen hen veel waarde toevoegt aan het creëren van digitale producten.

Over de auteur: Lútsen Stellingwerff is Solution designer bij Lifely.

Op de hoogte blijven van het laatste nieuws binnen je vakgebied? Volg Emerce dan ook op social: LinkedIn, Twitter en Facebook.