Laten we bij het begin beginnen

Ontwerp systeem. De laatste jaren is deze term overal terug te vinden. Voor ons, ontwerpers, zijn de definitie en het nut van een ontwerpsysteem vanzelfsprekend. Voor andere teamleden is het echter niet altijd zo duidelijk. 

Als u al weet wat een ontwerpsysteem is, aarzel dan niet om direct naar de paragraaf over communicatie te springen.

In 2018 gaf Usabilis de volgende beschrijving: een Design System is vergelijkbaar met een bibliotheek van componenten, visuals en principes met herbruikbare code. Deze evoluerende toolkit biedt een UX- en UI-repository voor ontwerpers en ontwikkelaars van digitale producten en diensten. Oké, maar dan zonder het technische jargon?

We zouden een designsysteem kunnen vergelijken met een grote keuken. Er zijn tal van ingrediënten en recepten waarmee u deze ingrediënten op de juiste manier kunt gebruiken.

De koks van het ontwerpsysteem zijn de ontwerpers (UI en UX) en de ontwikkelaars. Het is voor hen dat het ontwerpsysteem het meest zal dienen. De ontwerpers selecteren de ingrediënten (maken de componenten), schrijven de recepten (maken de modellen) en leveren deze aan de ontwikkelaars die de gerechten gaan bereiden (ontwikkelen van de websites, apps, etc.).

Door een gemeenschappelijke keuken te gebruiken, dezelfde ingrediënten en dezelfde recepten te gebruiken, zijn ontwerpers en ontwikkelaars zeker van consistentie op alle gerechten die in de kamer worden afgeleverd (in productie) en vooral om een ​​resultaat te krijgen dat zeer dicht bij of zelfs identiek is aan de stroomopwaarts gecreëerde modellen.

En dat is nog niet eens het grote voordeel van het ontwerpsysteem! De belangrijkste troef is inderdaad de snelheid van uitvoering die het mogelijk maakt voor het hele productteam (ontwerpers + ontwikkelaars). Omdat de componenten al klaar zijn, hoeft u ze alleen nog maar in elkaar te zetten om nieuwe pagina's, interfaces,... te creëren! We vergelijken het ontwerpsysteem vaak met Lego, het is niet voor niets.

Het andere grote voordeel komt van componentupdates. Inderdaad, alle componenten zijn "verbonden" met de bibliotheek, een update van een ervan rechtstreeks in de bibliotheek maakt het mogelijk om de component moeiteloos te updaten, waar deze ook wordt gebruikt. Bespaart tijd, bespaart moeite (u hoeft niet met de hand te zoeken waar het onderdeel wordt gebruikt!), wat wil je nog meer?

Disclaimer: voor de ontwikkelaars heeft het ontwerpsysteem alleen voordelen voor de voorkant. Het neemt op geen enkele manier de complexiteit van de rug en de beheerregels weg.

# Inhoud

Een ontwerpsysteem bestaat over het algemeen uit 2 bronnen van werk. Een bron voor ontwerpers, compatibel met de gebruikte software (Sketch, Figma, ...) en een bron voor ontwikkelaars, die alle reeds ontwikkelde componenten presenteert, evenals hun code. In beide gevallen kunnen de componenten die op deze bronnen aanwezig zijn direct worden "aangeroepen" (ofwel in de modellen voor de ontwerpers, ofwel in de code voor de ontwikkelaars), wat veel tijd en consistentie bij de realisatie bespaart.  

Wanneer we het over een designsystem hebben, verwijzen we meestal naar de broncode voor de ontwikkelomgeving, omdat die in productie wordt gebruikt. Het zijn de elementen die de eindgebruikers te zien krijgen. De broncode voor de ontwerper is alleen bedoeld om zichtbaar te zijn voor ontwerpers en ontwikkelaars.

Maar wat zit erin? Het hangt er vanaf. Er zijn natuurlijk richtlijnen, een veelheid aan artikelen met best practices. Aarzel niet om ze te volgen als ze niet helemaal overeenkomen met de behoeften. Bovendien is het opzetten van een ontwerpsysteem iets heel lang. Alles tegelijk doen is ingewikkeld. Er zijn echter belangrijke elementen om naar te neigen, minder primordiale elementen die het toch goed is om te hebben en die we later volledig kunnen toevoegen.

Enkele belangrijke inhoudselementen:

• de kleuren
• typografie
• roosters
• de onderdelen
• de richtlijnen voor het gebruik van alle hierboven genoemde elementen
• de toon om te gebruiken

In mijn ervaring zijn de belangrijkste problemen bij het opzetten van een ontwerpsysteem:

• voor het bedrijf: de kosten voor het opzetten en onderhouden die op lange termijn winstgevend zullen zijn
• voor de teams die het gaan opzetten en gebruiken: anticiperen op de komst van nieuwe leden in het team en communicatie tussen ontwerper en ontwikkelaar

Hier zullen we ons concentreren op wat direct van invloed is op de teams.

Als je je afvraagt ​​wat de komst van nieuwe leden zo bijzonder maakt, heb ik een vraag voor je. Heb je ooit bij iemand anders gekookt? Zo ja, heb je toen alle kastjes en lades opengetrokken op zoek naar de ingrediënten en keukengerei die je nodig had? Was je verbaasd dat je een specerij die je onmisbaar vindt, niet kon vinden? Voor mij is het antwoord ja.

Het is precies hetzelfde voor ons ontwerpsysteem. Of het nu een nieuwe ontwikkelaar is of een nieuwe ontwerper die het team komt versterken, hij zal heel snel zelf moeten kunnen vinden wat hij zoekt en dat de gebruiksaanwijzing voldoende duidelijk is om de componenten correct te kunnen gebruiken . Hierdoor zal onze nieuweling (laten we hem Fred noemen) in staat zijn om dit nieuwe project in de beste omstandigheden en zonder frustratie op zich te nemen.

Dan komt het probleem van de communicatie. Door uitbreiding van de nomenclatuur en rangschikking van componenten in het ontwerpsysteem. Om teamleden (nieuw of niet) hun weg te laten vinden, moet het ontwerpsysteem inderdaad al intuïtief zijn.   

Als teamleden meerdere termen gebruiken om naar hetzelfde onderdeel te verwijzen, wordt dit vroeg of laat een probleem.

Laten we een eenvoudig voorbeeld nemen :

Sommigen zullen hier spreken van droplist, anderen van dropdown. Weer anderen uit de vervolgkeuzelijst of zelfs uit DDL. 4 mogelijke namen om een ​​enkel onderdeel aan te duiden.

Als voor verschillende onderdelen van het ontwerpsysteem iedereen zijn eigen naam gebruikt, zal de communicatie tussen mensen steeds moeilijker worden omdat iedereen de moeite zal moeten nemen om te onthouden dat Lenny "dropdown", Karl "DDL", Lisa "droplist" zegt.

De een zal dus telkens de gedachte van de ander vertalen. In deze context, stel je nu Tony voor, de nieuwste aanwinst. Hij weet nog niet dat deze collega's verschillende namen gebruiken om over hetzelfde te praten. Tijdens een gesprek gaat Lisa met hem in gesprek over “droplist”. Dat is goed, Fred heeft het nodig voor zijn werk. Het zal daarom verwijzen naar het ontwerpsysteem en ... er is geen onderdeel met de naam "droplist". Het zal Fred dus extra moeite kosten om het bekende onderdeel te vinden. Hij zal ook moeten leren dat Lenny en Karl andere termen gebruiken. 

Omgekeerd, als je het hebt over de volgende kleur die je "blauw" zei, en het hele team gebruikt dezelfde term, dan zal de communicatie goed verlopen. Als we zeggen "dit onderdeel is blauw", weet iedereen aan tafel over welke blauwtint we het hebben.

Zoals je kunt zien, is het hebben van één nomenclatuur voor alle teamleden, zowel verbaal als in het ontwerpsysteem, erg belangrijk om vloeiende communicatie te hebben en ook om gemakkelijke bediening en navigatie in het ontwerpsysteem mogelijk te maken.

# Onderhouden en updaten van het ontwerpsysteem

Een sleutelbegrip in de Usabilis-beschrijving is 'schaalbaar'. Een ontwerpsysteem is bedoeld om in beweging te zijn. Dit zijn geen in steen gebeitelde wetten: de elementen waaruit het bestaat, kunnen worden bijgewerkt, andere kunnen worden gemaakt, oude componenten kunnen worden verwijderd. Net zoals we een recept naar onze smaak aanpassen nadat we het meerdere keren hebben gemaakt, kunnen we nieuwe ingrediënten toevoegen om meer smaken, meer subtiliteiten te verkrijgen. 

Een designsystem is geen doel op zich. Het is een hulpmiddel voor ontwerpers en ontwikkelaars. Als zodanig evolueert het mee met de teams en projecten.

Een ontwerpsysteem moet niet worden beschouwd als een project met een beperkte looptijd. De componenten en regels die het bevat kunnen veranderen. Uitzonderlijke variaties van sommige componenten kunnen nodig zijn. Daarom is het belangrijk om middelen (dev + designers) te blijven inzetten voor het monitoren en onderhouden van het ontwerpsysteem. Als het een jaar niet is gebruikt, zou het bijwerken ervan bijna hetzelfde zijn als al het werk om het op te zetten. Het is erg lang. Niemand wil dit twee keer doen. Om nog maar te zwijgen over de kosten voor het bedrijf. Het is daarom essentieel om middelen toe te wijzen aan het onderhoud en de evolutie van het ontwerpsysteem. Afhankelijk van de mate van volwassenheid van de DS kan een uur per week voldoende zijn.

# Belangrijkste punten

Als je zo ver bent gekomen, hoop ik dat dit artikel nieuwe horizonten heeft geopend voor je ontwerpsysteem, of dat je een beter begrip hebt van wat het is en waar het voor dient.

Als je maar een paar punten hoefde te onthouden :

• Het ontwerpsysteem is een creatie- en communicatietool gebouwd door en voor ontwerpers en ontwikkelaars
• Het zorgt voor de consistentie van een product
• De kosten van implementatie en onderhoud worden grotendeels gecompenseerd door de snelheid van uitvoering die het ontwerpers en ontwikkelaars biedt.
• Het kan in de loop van de tijd veranderen
• Het moet regelmatig worden bijgewerkt