Bij DataCamp is onze missie om datascience-onderwijs voor iedereen te democratiseren, en met meer dan 2 miljoen studenten wereldwijd boeken we snel vooruitgang. Op dit groeitempo opereren vergt veel inzet van iedereen binnen het bedrijf en brengt een hoop nieuwe, spannende uitdagingen met zich mee.
Voor het designteam betekent dit dat we verschuiven van pagina-voor-pagina ontwerpen naar een schaalbaardere manier van ontwerpen. Het hergebruiken van bestaande componenten, het verkorten van ontwikkeltijd, het verbeteren van de bruikbaarheid en het vergroten van de toegankelijkheid worden steeds belangrijker.
Dit artikel gaat over hoe we beginnen om grip te krijgen op een designsysteem.
Wat is een designsysteem?
Een designsysteem brengt alle componenten samen die nodig zijn om een ontwerpoplossing te verspreiden en te reproduceren. Het is niet nieuw of exclusief voor digitaal productontwerp — door de geschiedenis heen zijn er talloze voorbeelden te vinden.
Zo hadden boogschutters in het eerste Chinese rijk het probleem dat ze de pijlen van hun kameraden niet konden gebruiken. Elke pijl was specifiek ontworpen voor een bepaalde boog, waardoor andere pijlen simpelweg niet pasten. De eerste Chinese keizer, Ying Zheng, standaardiseerde de manier waarop pijlen werden ontworpen en dat had een enorme impact op hun militaire veroveringen.
In de jaren 50 had elk station van het NYC Transit System zijn eigen bewegwijzering. Dat zorgde voor veel verwarring, omdat elk station zijn eigen manier van navigeren had. Daardoor aarzelden veel mensen om het openbaar vervoer te gebruiken omdat ze niet begrepen hoe het werkte. Massimo Vignelli en Bob Noorda maakten het NYC Transit Authority — Graphics Standards Manual, waarin werd vastgelegd hoe borden gemaakt moesten worden en hoe ze in stations geplaatst moesten worden. In de loop der tijd is dit systeem min of meer hetzelfde gebleven en het wordt vandaag de dag nog steeds actief gebruikt.
Waarom zouden we een designsysteem hebben?
Als elke pagina in isolatie wordt ontworpen, ontstaan er veel dubbele of vergelijkbare componenten. Dat maakt een digitaal product moeilijk te begrijpen voor gebruikers en lastig te onderhouden voor engineering. Bij DataCamp ontdekten we meer dan 20 verschillende knoppen in ons product, elk met hun eigen eigenaardigheden (verschillende hover-states, inconsistente uitgeschakelde staten, enzovoort). Het is moeilijk om al deze componenten bij te houden wanneer een product snel groeit, en het wordt vrijwel onmogelijk om ze te onderhouden. Daar komt een designsysteem van pas.
Voor een digitaal product beschrijft een designsysteem de gebruikersinterfacecomponenten die je kunt gebruiken om een interface te creëren die een probleem oplost en resulteert in een samenhangende ervaring voor de gebruiker.
Als een designsysteem goed wordt uitgevoerd, leidt dat tot een kettingreactie die …
- Minder miscommunicatie veroorzaakt
- De implementatietijd verkort
- Het onderhoudswerk vermindert
- Minder bugs oplevert
- Minder supporttickets oplevert
- De kwaliteit verhoogt
- De efficiëntie verhoogt
- De levensduur verlengt
- De leerbaarheid vergroot
- De bruikbaarheid vergroot
- De toegankelijkheid vergroot
- De innovatie vergroot
- De focus vergroot
- De verkoop verhoogt
Het is niet makkelijk …
Een designsysteem creëren, onderhouden en afdwingen vergt veel discipline en een doorlopende inspanning van iedereen die betrokken is bij het creatieproces. Het is niet alleen design; ook engineering en productmanagement zijn belangrijke stakeholders. Zij moeten allemaal lastige vragen kunnen stellen zoals: “Waarom bouwen we dit?”, “Kunnen we deze component ergens anders hergebruiken?”, “Hebben we al iets vergelijkbaars?”, “Levert deze maatwerkcomponent genoeg voordeel op in verhouding tot de moeite die we erin steken?”.
Design System 101 bij DataCamp
1. Maak een componentinventaris
Doel: Zorg dat iedereen de bestaanstoestand en status van een component kent.
Toen ik bij DataCamp begon, was er een Sketch-bestand met kleuren, iconen, lettertypen en enkele basiscomponenten. Het was verre van compleet, maar het was een goed startpunt. Front-end engineering had ook een verzameling componenten die ze in projecten gebruikten.
Samen maakten we een inventaris in Airtable op basis van de componenten die in productie worden gebruikt. Dit gaf het designteam een idee van wat er al bestond en voorkwam dat we onbewust nieuwe componenten creëerden. Het gaf ons ook inzicht in hoeveel vergelijkbare componenten we hadden en hoe ernstig de situatie eigenlijk was.
2. Gebruik naamgevingsconventies
Doel: Miscommunicatie tussen Design en Engineering voorkomen.
Toen we componenten begonnen te vergelijken, merkten we dat Design en Engineering niet dezelfde taal spraken. Zo was de ‘primaire kleur’ die door design was gedefinieerd in de code de ‘secundaire kleur’. Zulke dingen kunnen tot miscommunicatie leiden wanneer teams opschalen, en zorgen voor verwarring en frustratie. We hebben ervoor gezorgd dat overal dezelfde terminologie wordt gebruikt.
3. De designworkflow optimaliseren
Doel: Voorkomen dat werk verloren gaat en een transparante workflow hebben.
Samenwerken als designteam brengt eigen uitdagingen met zich mee. We sloegen designs op in Dropbox, maar toen ons team groeide, namen de risico’s op werkverlies en de moeite om wijzigingen bij te houden sterk toe.
Ons designteam stond open voor een workflowverandering en we zijn Abstract gaan gebruiken. Daarmee konden we onze designs goed versiebeheren, transparanter werken en met meer vertrouwen ontwerpen.
4. Betere documentatie + onboarding
Doel: Snellere onboarding van nieuwe collega’s en communicatielast voorkomen.
We zijn ons proces en ons designsysteem gaan documenteren met Slite. Als we iets meer dan één keer moeten uitleggen, moet het gedocumenteerd en gedeeld worden met het team. Dit voorkomt veel communicatielast en voorkomt dat informatie verloren gaat.
5. Designreviews
Doel: Verwachtingen afstemmen tussen Design en Engineering.
Het is belangrijk dat designreviews twee richtingen op gaan. Designers moeten front-end kunnen reviewen, maar front-end moet ook design kunnen reviewen. Designers hebben de neiging om iets tofs en nieuws te maken. Engineers moeten lastige vragen kunnen stellen zoals: “Waarom bouwen we iets maatwerks?”, “Kunnen we deze component niet hergebruiken?”, “Kunnen we deze component verbeteren?”, “Is deze component de extra ontwikkelinspanning waard?”. Het draait om het verantwoorden van beslissingen en het afstemmen van verwachtingen met iedereen die betrokken is.
Conclusie
We zijn net begonnen met het samenstellen van ons designsysteem en proberen nog steeds grip te krijgen op alle dubbele componenten die we in ons product vonden. Er ligt nog een lange weg voor ons, maar met elke component die we aanpakken, creëren we voor onze klanten een beter, consistenter en makkelijker te leren product.
We zijn benieuwd hoe andere organisaties hun designsysteem vormgeven. Stuur me een e-mail als je je ervaringen wilt delen.
Bij DataCamp zijn we altijd op zoek naar getalenteerde mensen om ons team te versterken. Geïnteresseerd? Bekijk onze openstaande functies.
