Design system opzetten? Makkie toch?

Bijna twee jaar geleden begon ik aan een uitdagende klus bij de Rijksdienst voor Ondernemend Nederland (RVO).

Mijn opdracht: zorg ervoor dat de klant een uniforme User Interface (UI) en User Experience (UX) ervaring heeft als deze gebruik maakt van de verschillende applicaties en websites van RVO.

De utopie van een Design System

De oplossing: Een design system. In dit design system wordt vastgelegd hoe componenten binnen de applicaties en websites eruit horen te zien. Een component binnen ons Design System moet voldoen aan de Rijkshuisstijl, gebruiksvriendelijkheid (op basis van resultaten vanuit intern en extern onderzoek) en toegankelijkheid. Daarnaast worden er patronen in het Design System opgenomen die laten zien hoe de verschillende componenten het beste met elkaar gebruikt kunnen worden.

Naïef als ik was dacht ik dat dit niet complex hoefde te zijn. Je ontwerpt een stuk of 30 componenten, enkele patronen en voorbeeldpagina's en de applicaties konden het Design  System gaan gebruiken. Binnen een paar maanden, misschien een jaar, zouden alle applicaties en kanalen een uniforme uitstraling hebben.

De realiteit van een Design System

De realiteit is anders. Het opzetten van het design system en het ontwerpen van de componenten en patronen ging voortvarend. De aansluiting van de applicaties is een uitdaging. Je krijgt te maken met tientallen verschillende applicaties van interne en externe leveranciers die allemaal een verschillend niveau van technische kennis hebben. En daarbij de (on)mogelijkheid om aan te sluiten op een design system. Ook spelen factoren zoals tijd en budget een rol waardoor aansluiten op een design system geen hoge prioriteit krijgt.

Al snel kreeg ik door dat ik mijn doel 'binnen korte tijd alles uniform' moest aanpassen. Ik moet klein beginnen.

Technische aansluiting is het belangrijkst

Dat wil zeggen dat applicaties de zogenaamde libraries van het Design System inladen. De libraries bestaan onder andere uit CSS bestanden die de styling bepaalt. Als daarbij de correcte HTML gehanteerd wordt ziet een component, bijvoorbeeld een button, er hetzelfde uit op de applicatie als in het design system. Als een andere applicatie precies hetzelfde doet zijn er twee identieke buttons op twee applicaties. Dit is op zich al een mooi gegeven, maar de kracht van het Design System wordt pas echt zichtbaar als de button moet worden aangepast.

Wat momenteel binnen onze organisatie speelt is dat er een aangepaste Rijkshuisstijl komt. De button, nog steeds het beste voorbeeld, krijgt een subtiele aanpassing. De hoeken worden namelijk afgerond waar ze nu recht zijn. Elke applicatie en website die moet voldoen aan de Rijkshuisstijl moet de hoeken van de knop afronden. Dat betekent in de CSS spitten naar waar de knoppen allemaal aangeroepen worden en daar een regel toevoegen (border-radius: 3px)

Als de applicaties of websites gebruik maken van ons Design System ROOS is dat een stuk simpeler. De aanpassing wordt dan centraal gedaan in een van de CSS libraries en doorgestuurd naar de aangesloten applicaties. Deze kun het nieuwe CSS bestand binnenhalen op een ontwikkelomgeving om te kijken of de aanpassing niks kapot maakt. Nu is dit bij de afronding van de hoeken van de buttons niet het geval. Na een kleine controle kunnen de aanpassingen doorgevoerd worden op de productieomgeving, en zie daar, de button heeft afgeronde hoeken. Nu heb ik het over een relatief kleine aanpassing aan een enkel component. Maar de tijdwinst die geboekt wordt als het gaat over meerdere aanpassingen over meerdere componenten is enorm.

Het doel is daarom als volgt: zoveel mogelijk applicaties delen zoveel mogelijk componenten en patronen. Des te meer, des te beter.

Prop niet alles in je Design System

Wat belangrijk is om te vermelden dat het niet betekent dat je elk component wat je bij een applicatie tegenkomt direct opneemt in je Design System. Hier wordt je Design System onoverzichtelijk en, op de lange termijn, onbruikbaar van.

Momenteel ben ik bezig met een applicatie waarbij gebruikers een topografische kaart kunnen bewerken. Veel gebruikte componenten zijn herbruikbaar, zoals een bewerkscherm met formuliervelden of een overzichtsscherm met cards. Maar een kaart die bewerkt kan worden door gebruikers is uniek voor deze applicatie. Dit wordt daarom ook niet opgenomen als component in het Design System. De regel is dat het door minstens een andere applicatie gebruikt kan worden.

Het is echter wel noodzakelijk dat componenten die niet in het Design System opgenomen worden, wel in de geest van het Design System ontworpen worden. Daarom is het belangrijker dat er designers aangesloten zijn bij het bouwteam die weten wat het Design System is en kunnen ontwerpen in de stijl van het Design System om de gebruikerservaring uniform te houden.

Tot slot

Het ontwerpen, maken, beheren en verkondigen van een Design System is een rommelig proces. En dat is lastig voor iemand zoals ik, die ondanks mijn creativiteit, toch altijd graag binnen de lijntjes kleurt. Ik moet accepteren dat niet alle applicaties of kanalen het Design System tot de letter kunnen volgen. Het gaat om het vieren van kleine overwinningen waar het Design System bouwteams kan helpen bij het maken van bruikbare en visueel aantrekkelijke applicaties of websites.

Wat is jouw ervaring met Design Systems? En hoe ziet jouw implementatie eruit? Ik ben benieuwd dus deel het met mij door hieronder een reactie achter te laten.