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.
Niveau 1: Design tokens
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..
Niveau 2: CSS frameworks
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.
