Het is allang niet meer de vraag of je een designsysteem moet hebben, maar de vraag is vooral hoe je deze moet implementeren binnen je projecten. Voor organisaties in het midden- en grootbedrijf is een consistente merkbeleving belangrijk; je wilt geen afbreuk doen aan het merk dat je met zoveel energie hebt gebouwd. Daarnaast wil je elke mogelijkheid aangrijpen om je merk meer kracht bij te zetten. Maar hoe zorg je voor goede borging van je designsysteem binnen je websites en webapplicaties?
Het antwoord op deze vraag is afhankelijk van een aantal aspecten. Welke applicaties moeten het designsysteem gaan implementeren (idealiter zoveel mogelijk) en in welke volgorde (meest gebruikte eerst)? Zijn de applicaties gebouwd op veel verschillende (maar overlappende) technieken? Wordt er nog actief doorontwikkeld aan deze applicaties? Why is it never easy…
Bij Pixelpillow onderscheiden we drie verschillende, opeenvolgende niveaus om design systemen te implementeren op het web. Een hoger niveau zorgt voor meer consistente implementatie van het designsysteem, maar vereist ook een hogere inspanning van de ontwikkelteams. Een goed designsysteem opbouwen kost tijd, maar levert op de lange termijn een consistentere merkbeleving op en scheelt enorm veel tijd ontwikkeling van nieuwe sites en applicaties. Het is niet voor niets dat een aantal jaar geleden elke nieuw gebouwde applicatie op basis van Bootstrap werd ontwikkeld.
Wanneer we een ontwerp plat slaan, bestaat deze uit een combinatie van lettertypes, kleuren, positionering, witruimte, schaduwen, maar bijvoorbeeld ook de manier waarop onderdelen binnen het ontwerp animeren. Het idee van een design token is dat je verschillende waarden (bijvoorbeeld kleuren) samen met haar toepassingen centraal opslaat als een stukje configuratie. Elk element binnen de implementatie maakt vervolgens gebruik van die waarde in de configuratie. Zo verwijst de kleur van de pagina titel naar het design token voor “paginatitel kleur”.
Meer weten of design tokens? Luister naar de podcast.
Op deze manier voorkom je een wildgroei van verschillende waardes. Facebook is hier vaak veelgebruikt voorbeeld. Bij een inventarisatie bleek dat door de organisatie een paar honderd kleuren blauw gebruikt werden, waarbij het eigenlijk de bedoeling was om de primaire kleur blauw toe te passen. Allemaal omdat de “juiste” blauw niet voorhanden was.
Design tokens kunnen nog een stukje verder gaan dan een simpele kleurcode. Zo zou je combinaties van lettertypes en groottes kunnen vastleggen, op basis waarvan je weer CSS genereert die je vervolgen binnen een website of applicatie toepast.
Hoe je design tokens implementeert is geen gegeven: je kan al van design tokens spreken wanneer je een losstaand configuratie bestand binnen je organisatie deelt. Maar dat weerhoudt natuurlijk niemand om die kleur rood die eigenlijk gedefinieerd is voor foutmeldingen, te gebruiken voor een pagina kop..
De volgende stap is het daadwerkelijk vastleggen hoe je terugkerende elementen gebruikt. Bijvoorbeeld een button, een tabel of de opbouw van een formulier. Grote kans dat er een belletje gaat rinkelen wanneer je de term Bootstrap of Foundation hoort; dit zijn breed gebruikte CSS frameworks die veelal ingezet worden om applicaties er fatsoenlijk te doen uitzien, zonder zelf na te hoeven denken over de gebruikersinterface.
Het grote voordeel ten opzichte van design tokens is dat CSS frameworks stukjes gebruikersinterface ontsluiten die je direct kan implementeren. Je hoeft de design tokens dus niet langer zelf te combineren. Hierdoor is de opmaak van elementen eenduidig. Als ontwikkelaar pas je simpelweg de stijlen in je HTML toe, of deze nu gegenereerd wordt in een presentatielaag in het backend, of door een frontend framework zoals React of Angular.
Overigens zijn wij geen fan het implementeren van designsystemen op basis van bestaande CSS frameworks. Helemaal niet wanneer je “design-first” denkt. Je moet al snel naar trucs grijpen wanneer een onderdeel uit het design system niet lekker te implementeren is met configuratieopties die het framework aanbiedt. Natuurlijk is het prima om meer algemene onderdelen uit zo’n framework te gebruiken, zoals grids en andere algemene functionaliteiten.
Als je écht zeker wilt zijn dat het design system van je organisatie consequent wordt doorgevoerd, dan moet je de stap maken naar component libraries. In zo’n library worden geïsoleerde, herbruikbare stukjes functionaliteit samengevoegd in een component. Een component voorziet zowel in de structuur, opmaak en het gedrag van een stukje functionaliteit. Op die manier weet je zeker dat deze niet (meestal goedbedoeld) aangepast wordt en niet langer in lijn is met het designsysteem.
Door het gebruik van componenten kan je precies vastleggen hoe een component gebruikt kan worden. Misschien wil je een ontwikkelaar de mogelijkheid geven om een icoontje in een button aan te passen, maar wil je wel afdwingen dat het icoontje altijd links van de tekst staat. Met componenten (en een component library) kan je hier dus voor waken.
Component libraries worden vaak geïmplementeerd voor een specifiek framework. Wanneer je een component library hebt ontwikkeld voor React, kan je deze niet gebruiken in bijvoorbeeld Angular of Vue.js. Organisaties die meerdere frontend frameworks gebruiken kiezen daarom vaak voor een combinatie van een CSS framework en meerdere component libraries. Hierbij wordt wordt het CSS framework toegepast binnen de verschillende component libraries. Op die manier voorkom je dat (delen) van het designsysteem op meerdere plekken onderhouden moet worden, maar heb je wel de voordelen van een component library.
Iedereen die in aanraking komt met designsystemen snapt deze deze van grote waarde kunnen zijn, maar verschilt het per organisatie hoe je dit het beste kan implementeren. En dan hebben we het nog niet eens gehad over het onderhouden en communicatie rondom een succesvolle implementatie. Ben jij opzoek naar een partij die jullie kan helpen? Neem dan contact op met Pixelpillow.
