6 tips om design in je development proces te integreren

Speelt één of meerdere van deze deze uitdagingen in jouw organisatie?

• De gebouwde functionaliteiten komen niet overeen met het design.
• Het design van onze applicaties is heel inconsistent. Bijvoorbeeld allerlei verschillende Buttons of 10 verschillende zoekvelden.
• Mijn designers werken op een eilandje en communiceren weinig met onze developers.
• Mijn designers maken een mooi ontwerp, maar denken te weinig na over de technische oplossing.
• Mijn developers vinden design secundair en vinden het niet belangrijk om een design op de pixel nauwkeurig uit te werken.
• Design wordt door het gehele bedrijf gezien als optioneel.

Veel van deze problemen hebben met elkaar te maken. Deze problemen zijn ook niet te wijten aan individuele personen, maar vooral aan het proces en de organisatie. In de volgende 6 inzichten hopen we deze problemen weg te nemen.

1. Bedenk je maatstaf

Om verandering te bewerkstelligen zul je zelf moeten gaan uitdragen dat design belangrijk is en zul je het werk ook hierop moeten beoordelen. Het simpelweg aannemen van een designer is niet voldoende om je organisatie te veranderen. Het beoordelen van design zonder een design achtergrond kan lastig zijn.

Om je hierbij te helpen kun je een benchmark doen van in jouw ogen goed ontworpen applicaties binnen of buiten jouw markt. Als je een aantal voorbeelden hebt gevonden kun je beschrijven wat deze zo goed maakt. Hebben ze een mooie stijl? Vriendelijke teksten? Korte laadtijden? Fijne animaties? of werken ze gewoon heel goed? Begin met het benoemen waar jouw applicaties ook aan moeten gaan voldoen. Gebruik deze benchmark als maatstaf voor alle output binnen je bedrijf. Op deze manier kun jij design beoordelen zonder zelf designer te zijn.

Natuurlijk is een designer essentieel om te kunnen ontwerpen en reviewen, dus adviseren we om te beginnen met een Senior Designer die al ervaring heeft bij andere design-gedreven bedrijven. Maar let dus op: Een designer zal niet in zijn eentje deze grote strategische verandering kunnen bewerkstelligen.

2. Maak van design geen eiland

Om design-gedreven te worden moet je beginnen met het integreren van design binnen je bestaande development processen. Een designer mag niet op een eilandje werken, maar moet juist veel samenwerken met het gehele team. De designer is de schakel tussen de business en de developers. Een designer heeft dus géén eigen proces, maar is onderdeel van een proces. Binnen het development proces zijn er twee belangrijke stappen waar design ingebouwd moet worden: tijdens het maken van een User Story en bij het afleveren van een User Story.

3. Wijzig de Definition of Ready

Zorg ervoor dat het design exact overeenkomt met de User Story. Als deze afwijkt zullen developers ruimte krijgen voor improvisatie en zal de applicatie in toenemende mate gaan afwijken.

Wanneer er een nieuwe functionaliteit is bedacht wordt deze uitgeschreven door iemand binnen het team. Het is belangrijk dat bij het uitdenken van de functionaliteit een designer wordt betrokken, of zelfs dat de designer deze zelf uitwerkt. Als er een Business Analyst in het team zit zal deze waarschijnlijk de User Stories uitschrijven. Hierbij is het van belang dat hij/zij de designer betrekt bij het oplossen van het gebruikersprobleem.

Wanneer de User Story is uitgeschreven is het essentieel dat het design exact overeenkomt. Het kan dus niet zo zijn dat iemand een extra requirement in de Story heeft gezet zonder dat dit is verwerkt in het design.

De designer is daarbij dus ook verantwoordelijk dat alle verschillende states van een design zijn uitgewerkt. Dus niet alleen de happy flow. Denk hierbij bijvoorbeeld aan error states, empty states, loading states en hoe het werkt op mobiel of juist desktop.

Je zult zien dat een goed uitgewerkt design ervoor zorgt dat een Story minder uitgebreid geschreven hoeft te worden en tegelijk de Story duidelijker zal maken. Win win!

4. Wijzig de Definition of Done

Voeg een Design Review toe aan je Definition of Done. Developers moeten naast goede code ook worden afgerekend op het design, anders zullen ze design altijd als optioneel beschouwen.

In je Scrumboard kun je naast een ‘To (code) Review’ ook een ‘To design Review’ status toevoegen. Hierdoor zorg je ervoor dat niemand deze stap meer overslaat. Wanneer een designer feedback heeft gegeven kan de User Story weer terug naar ‘In Progress’, zodat de developer hem kan oppakken. Het is belangrijk dat de designer verantwoordelijk wordt gesteld voor het regelmatig reviewen van de Stories. De designer maak je hiermee verantwoordelijk voor de aflevering van een functionaliteit en dus niet alleen voor het design.

5. Gebruik een Design system

Door het hanteren van een design system zal je wildgroei van vergelijkbare elementen voorkomen en zullen developers niet telkens vergelijkbare elementen opnieuw moeten bouwen.

Een design system is in essentie een verzameling van alle bouwblokken (componenten) binnen je applicatie. De basis zijn kleuren, typografie en iconen. Met deze elementen kun je componenten zoals buttons en inputs maken. Hiermee maak je weer grotere componenten zoals een navigatie of een popup.

Een design system bestaat uit twee delen: Het design system in design vorm en het design system in code. Wij noemen de code versie ook wel een Component Library. Door het maken van een design system heb je één plek waar je alle basiscomponenten van je gehele app beheert. Zo heb je een single source of truth en hoeven designers een component maar één keer te reviewen.

Het is extreem belangrijk dat het design system en de component library exact overeenkomen met elkaar. Doordat zowel de designer als developer continu gebruik maken van hun eigen componenten wil je dat het design en de code in werkelijkheid zo dicht mogelijk bij elkaar liggen.

6. Neem een front-end developer aan

Front-end developers vinden design belangrijk en willen hun best doen om het design zo goed mogelijk uit te werken. Andere developers zullen vaker weerstand bieden als het op design aankomt.

In veel bedrijven bouwen developers zowel de front-end als back-end. Vrijwel altijd ligt de focus daarbij op de logica van de applicatie (de back-end) en is de front-end een bijzaak. Fulltime front-end developers vinden design juist leuk en zijn goed in het bouwen van interfaces. Ze houden ervan niet alleen het design na te bouwen maar zelfs ook om mee te denken in de ontwerpoplossing. Let wel op: Als je de voorgaande stappen niet hebt geïmplementeerd, dan zal een front-end developer weinig oplossen.

Conclusie

Om je development teams design gedreven te maken zul je meer moeten doen dan alleen een designer aannemen. Het verwerken van design binnen het bestaande proces is daarin de sleutel. Ook helpt het enorm als je met mensen werkt die het leuk vinden om met design bezig te gaan. Voor designers is het werken met een goede front-end developer ook een verademing en zal het proces ook een stuk soepeler laten verlopen. Bedenk je wel dat mensen alleen zullen veranderen als jij als manager of directeur dit zelf ook écht belangrijk vind en de output ook daadwerkelijk hierop gaat beoordelen.

Wil je meer lezen? 

Org Design for Design Orgs

Building a design-driven culture