Waarom je een design language nodig hebt

25 februari 2016 Inzichten / Waarom je een design language nodig hebt

Een design language is een stijlgids on steroids. Het is een leidraad en een visie voor het hele team. De design language bundelt alle bevindingen over gebruiksvriendelijkheid, stijl, conversie en techniek in een mooi en publiek beschikbaar overzicht per component, interactie en structuur. Resultaat? Sneller consensus en nooit meer nodeloze discussies.

Situatieschets: er is feedback op het design en er is complete chaos. Opnieuw. In het design ontbreekt de ‘sorteer-knop’ bij een tabel, maar bedoelt de informatiearchitect dan een sorteer-knop per kolom? En moet de ontwikkelaar de database-query dan aanpassen of hoe zat dat nu weer? En hadden ze die discussie niet vorige maand ook al gehad? En konden we die component van toen niet hergebruiken? Natuurlijk. Je moet het gewoon doen.

Net zoals het bestaat voor het Nederlands hebben we dus vaak nood aan een ‘groen boekje’ met een aantal vuistregels. Helaas vertalen websites zich niet zo goed in woorden, dus hebben we nood aan iets visueels. Een ontwerptaal, maar in het Engels klinkt dat beter: een Design Language.

Nooit meer discussie

Een Design Language dus. Waarom zou je daar van wakker liggen? Wel, vooral omdat je dan in de toekomst een pak minder slaap moet laten voor discussies die je nu eindeloos opnieuw moet voeren.

Hoe werkt het? Als het team overeenkomt hoe bijvoorbeeld een hoofdnavigatie er zou moeten uitzien en welke gebruiksvriendelijke aspecten zeker aanwezig moeten zijn, dan neem je het op in je design language. Elke volgende designdiscussie begint vanaf dan op basis van de design language.

Het is een concept dat heel mooi accordeert met het concept ‘modulair design’ of ‘atomic design’. We denken als informatiearchitecten nog steeds graag in pagina’s, maar tegenwoordig vervagen pagina’s (bijna letterlijk) in elkaar. We beschrijven dus beter de legoblokjes van een website: componenten. Brad Frost legt dat trouwens een pak beter uit dan ik.

Bekijk de design language als een IKEA-catalogus waarbij je voor elk type huis en kamer een verzameling van uitstekend ontworpen meubels nodig hebt. Je moet ze enkel nog juist monteren (en soms een nieuw kleurtje geven of een extra deurtje vastschroeven).

Je bereikt een gemeenschappelijke visie en er is consistentie over de websites heen. Nieuwe projectleden herkennen het meteen en je kan het zo opnieuw gebruiken in de toekomst. Een win-win-win-win-(repeat) situatie.

Maar een website is meer dan componenten alleen. Componenten maken deel uit van een structuur en zijn het onderwerp van een hoop interacties.

Interacties en structuur

Als componenten de woorden van de taal zijn, dan zijn interacties en structuur de zinnen en de grammatica. Een voorbeeld van een interactie is bijvoorbeeld het gedrag ‘toevoegen van een item aan een lijst’. Een voorbeeld van structuur kan een sitemap zijn, een aantal richtlijnen om componenten te combineren (of juist niet) of in het algemeen: de relaties tussen componenten.

Het spreekt vanzelf dat vooral onze online marketeers geïnteresseerd zijn in de ‘interacties’ en welk effect dat zal hebben op de conversie. Is in het verleden gebleken dat bij een A/B-test deze interactie beter werkt? Waarom nemen we dat niet op in de design language?

Informatiearchitecten geven het beste van zichzelf om doordachte en begrijpbare structuren van componenten op te bouwen. Ook dat zijn bevindingen die een plaatsje verdienen in de design language.

Heb ik dat echt allemaal nodig?

Babysteps. Alles heeft z’n nut, maar de nuttigste dingen eerst. Als je een aantal verschillende projecten tegelijk doet of je hebt meerdere websites, dan wil je waarschijnlijk ergens opschrijven wat de grootste gemene deler is. Discussies worden zo herleid tot twee gevallen:

  1. Uitzonderingen die heel specifiek zijn aan het huidige project:
  • Die kan je maar moeilijk veralgemenen en zal je moeten uitklaren per project.


2. ​Discussiepunten die al zijn opgenomen in de design language:


  • ‘Hier hebben we het al eens over gehad, gaan we dit echt opnieuw bespreken?’

  • Soms moet dat kunnen, maar hou het efficiënt en koppel het resultaat terug naar de design language.


Er zijn fantastische voorbeelden te vinden, zoals IBM, Mailchimp, Brad Frost of Google. Sommigen blijven bewust een beetje wollig met ‘principes’ en ‘concepten’, anderen maken het graag concreet met code snippets en technische documentatie.

Je hoeft echt geen Silicon Valley Superhero te zijn om een design language op te stellen. Een huisstijl heb je waarschijnlijk al. Waarom kan daar geen design language bij?

Dit is toch gewoon ‘best practices’ in een nieuw jasje?

Ja en nee. Het zijn inderdaad ‘best practices’, maar een design language heeft een heel duidelijke indeling van ‘componenten’, ‘interacties’ en ‘structuur’. Het helpt designers, informatiearchitecten, ontwikkelaars en marketeers te denken in termen van herbruikbaarheid en consistentie, en het vermindert discussies.

Het hoeft trouwens lang niet alleen over visueel ontwerp te gaan: integreren is het toverwoord.

Geen silo’s

Ik zeg design, ik bedoel eigenlijk alles wat voor de ontwikkelfase komt. Ik bedoel eigenlijk ook de ontwikkelfase. Ik bedoel eigenlijk ook de conversie-optimalisatie achteraf. Inderdaad. Alles. Een design language gaat over informatiearchitectuur, grafisch ontwerp, front-end- én back-end-ontwikkeling en marketingoptimalisatie.

Je kan zo ver gaan als je wil, maar vermijd daarbij dat iedereen op zijn eilandje werkt. Het best maak je componentbeschrijvingen met daarin het gewenste UX-gedrag, de code snippet voor de front-end developer en zet er dan ook het best de logica van de PHP controller in.

Maar mag het nog een stapje verder? Waarom geen winkelmandje-component die voor onze online marketeers ook de gewenste impact heeft? En zou dat ook geen logische plaats zijn om daar de TagManager-configuratie neer te zetten? Uiteraard.

Weg dus met silo’s en ivoren torens, iedereen multidisciplinair! Maar hou het wel begrijpbaar voor iedereen.

Start small

Moet dat vandaag klaar zijn? Uiteraard niet. Maar begin eraan, desnoods in een google doc of op een mini-wiki. Zet het publiek bewerkbaar voor iedereen en neem een moment om aan iedereen het concept uit te leggen. Dump vanaf dan elk bruikbaar ideetje erin. Na een tijd wordt het een uiterst boeiend document.

 

Heb jij nog frisse ideeën voor onze design language? Wijs zoekt nog extra collega's!

Lees meer

Iedereen bij Wijs deelt zijn expertise, ook Jasper en Evi. Benieuwd naar de laatste nieuwtjes en blogposts? Schrijf je in voor onze nieuwsbrief!