Wat is het verschil tussen een designsysteem en een huisstijlgids?

Een huisstijlgids legt vast hoe een merk eruitziet: logo, kleuren, lettertypes en het gebruik daarvan, meestal in een document. Een designsysteem gaat verder en bevat werkende bouwstenen: componenten in de ontwerpsoftware én in code, met documentatie over wanneer je welk onderdeel gebruikt. Een huisstijlgids beschrijft, een designsysteem levert. Het verschil merk je in gebruik: uit een gids moet je zelf iets afleiden, uit een systeem pak je een bestaand onderdeel.

Vanaf welke omvang loont een designsysteem?

Er is geen harde grens, maar de vuistregel is dat het loont zodra meerdere mensen aan hetzelfde product werken of zodra een site jarenlang wordt doorontwikkeld. Voor een site van tien pagina's die eenmalig wordt gebouwd, is het overdreven: de opzetkosten worden dan nooit terugverdiend. Voor een portaal, een webshop met veel schermen of een organisatie met meerdere sites in dezelfde stijl is het vrijwel altijd voordeliger dan telkens opnieuw beginnen.

Kan ik een bestaand systeem gebruiken in plaats van een eigen?

Ja, en dat is vaak verstandig. Er bestaan volwassen open systemen die je kunt overnemen en voorzien van je eigen kleuren en typografie. Voor Nederlandse overheidsorganisaties is er bovendien een gemeenschappelijk systeem dat aansluit op de toegankelijkheidseisen. Het voordeel is dat het meeste denkwerk al gedaan is; het nadeel is dat je aan de mogelijkheden ervan gebonden bent. Voor een sterk eigen merkuitstraling is een eigen systeem meestal alsnog nodig.

Wie onderhoudt een designsysteem na oplevering?

Dat is de belangrijkste vraag en tegelijk de meest overgeslagen. Een systeem dat niemand bijhoudt, raakt binnen een jaar uit de pas met de werkelijke site, en dan gaan mensen er weer omheen werken. Bij grotere organisaties is er vaak een vast team of een aangewezen persoon; bij kleinere is het meestal een afspraak met het bureau in de vorm van een periodiek onderhoudsbudget. Regel dit vooraf, want zonder eigenaar is de investering binnen twee jaar grotendeels verdampt.

Moeten ontwerp en code echt gekoppeld zijn?

Ze hoeven niet technisch gekoppeld te zijn, maar ze moeten wel gelijk blijven lopen. In de praktijk is dat de grootste valkuil: de ontwerpbibliotheek wordt bijgewerkt en de codebibliotheek niet, of andersom. Sommige teams lossen dat op met gedeelde designtokens, waarin kleuren en maten op één plek staan en beide kanten daaruit putten. Dat helpt, maar vervangt niet de afspraak dat een wijziging aan beide kanten wordt doorgevoerd.

Maakt een designsysteem het ontwerp niet saai?

Dat is een reëel risico als het systeem als keurslijf wordt gebruikt, maar het is geen noodzakelijk gevolg. Een goed systeem legt vast wat herhaald wordt en laat ruimte voor wat uniek moet zijn: campagnepagina's of verhalende pagina's wijken bewust af van het patroon. De winst zit erin dat de honderden gewone schermen consistent blijven, zodat er tijd en aandacht overblijft voor de plekken waar onderscheid daadwerkelijk iets toevoegt.

Designsystemen | WebdesignVergelijker.nl

Wat is een designsysteem?

Een designsysteem is een vastgelegde verzameling herbruikbare onderdelen en de regels voor het gebruik ervan. Het bestaat doorgaans uit drie delen: een bibliotheek met componenten in de ontwerpsoftware, dezelfde componenten in werkende code, en documentatie waarin staat wanneer je welk onderdeel inzet. Ontwerpers en developers werken daarmee uit dezelfde voorraad in plaats van elke keer opnieuw iets te bedenken.

De aanleiding om er een te bouwen is bijna altijd hetzelfde: een site die door de jaren heen uit elkaar is gegroeid. Er zijn zeven varianten van dezelfde knop ontstaan, formulieren werken op elke pagina net anders, en niemand weet meer welke versie de bedoelde is. Elke variant was op zichzelf een redelijke keuze van iemand die haast had, maar samen kosten ze onderhoudstijd en maken ze de site rommelig.

Een designsysteem is daarmee vooral een organisatorisch instrument dat zich als ontwerpwerk voordoet. De componenten zijn het zichtbare deel, maar de eigenlijke winst zit in de afspraak dat iedereen ze gebruikt en dat er één plek is waar ze worden bijgehouden. Zonder die afspraak is een designsysteem niet meer dan een nette map met bestanden waar mensen omheen werken zodra ze onder tijdsdruk staan.

Wat valt er precies onder?

Een volwaardig designsysteem bestaat uit meer dan een verzameling knoppen; het legt ook de onderliggende waarden en het gebruik vast.

Designtokens: de basiswaarden voor kleur, afstand, tekstgrootte en hoekafronding, op één plek vastgelegd zodat beide kanten eruit putten.
Componentbibliotheek in ontwerp: de herbruikbare onderdelen in de ontwerpsoftware, met al hun toestanden en varianten.
Componentbibliotheek in code: dezelfde onderdelen als werkende code, zodat een developer ze rechtstreeks kan gebruiken.
Patronen: samengestelde oplossingen voor terugkerende situaties, zoals een formulierindeling of een filterpaneel.
Richtlijnen voor gebruik: wanneer je welk onderdeel inzet en wanneer juist niet, want dat is waar de meeste fouten ontstaan.
Schrijfrichtlijnen: afspraken over de toon en formulering van knoppen, labels en foutmeldingen.
Toegankelijkheidseisen per component: wat er per onderdeel geregeld moet zijn aan contrast, focus en ondersteuning voor hulpsoftware.
Versiebeheer en wijzigingsproces: hoe een aanpassing wordt voorgesteld, beoordeeld en uitgerold naar de bestaande site.

Hoe verloopt de opbouw van een designsysteem?

Een systeem wordt zelden in één keer opgebouwd; het groeit vanuit wat er al is, in de volgorde waarin onderdelen daadwerkelijk nodig zijn.

Inventariseren. Alle bestaande varianten worden verzameld: hoeveel soorten knoppen, kleuren en formulieren er feitelijk in gebruik zijn. Die uitkomst is vrijwel altijd hoger dan verwacht.
Terugbrengen. Er wordt bepaald welke varianten blijven en welke vervallen. Dit is de fase waarin de meeste discussie ontstaat en de meeste winst zit.
Fundament vastleggen. Kleuren, afstanden en typografie worden als tokens vastgelegd, zodat alle componenten daarop kunnen voortbouwen.
Kerncomponenten bouwen. De meest gebruikte onderdelen worden als eerste uitgewerkt in ontwerp én code, inclusief hun toestanden.
Documenteren. Per onderdeel wordt vastgelegd waarvoor het bedoeld is, hoe het wordt gebruikt en welke eisen eraan gesteld zijn.
Invoeren en uitbreiden. Bestaande pagina’s worden stapsgewijs omgezet naar de systeemcomponenten, en het systeem groeit mee met nieuwe behoeften.

Wanneer heb je dit nodig?

De duidelijkste aanleiding is doorlopende doorontwikkeling. Als er elke maand nieuwe schermen bij komen, loont het om niet telkens opnieuw te beginnen. Bij een site die eenmalig wordt gebouwd en daarna vijf jaar ongewijzigd blijft, wordt de investering nooit terugverdiend.

Een tweede aanleiding is meerdere mensen of teams die aan hetzelfde product werken. Zodra twee ontwerpers los van elkaar schermen maken, ontstaan er verschillen, en die vermenigvuldigen zich. Datzelfde geldt bij organisaties met meerdere sites of merken die familie van elkaar moeten blijven.

Ook zichtbare inconsistentie is een signaal: als collega’s zelf al opmerken dat de site er per pagina anders uitziet, is de wildgroei het punt voorbij waarop losse correcties nog helpen. En bij strenge toegankelijkheidseisen loont het om die eisen één keer per component goed te regelen in plaats van op elke pagina opnieuw.

Wat levert het op?

De duidelijkste opbrengst is snelheid bij het bouwen van nieuwe schermen. Als de bouwstenen klaarliggen en getest zijn, kost een nieuwe pagina samenstellen aanzienlijk minder tijd dan hem van de grond af ontwerpen en bouwen. Daarnaast levert het consistentie op zonder dat iemand daar telkens op hoeft te letten, en het maakt onderhoud goedkoper: een wijziging aan een component werkt overal door in plaats van op vijftig plekken handmatig.

De keerzijde is dat de kosten vooraan zitten en de opbrengst achteraan. Een designsysteem opzetten kost weken tot maanden, en in die periode gaat de gewone doorontwikkeling langzamer. Organisaties die het aanschaffen omdat het gangbaar is, zonder dat er doorlopend aan de site wordt gewerkt, houden vooral kosten over. Bovendien vergt het onderhoud: een systeem dat niet wordt bijgehouden, loopt uit de pas met de werkelijke site, en op dat moment gaan mensen er weer omheen werken. Dan is de investering grotendeels verloren.

Waar let je op als je dit uitbesteedt?

Vraag of het systeem zowel in ontwerp als in code wordt geleverd, en hoe die twee gelijk worden gehouden. Een bibliotheek die alleen in ontwerpsoftware bestaat, wordt in de praktijk door developers alsnog geïnterpreteerd, met verschillen als gevolg. Vraag ook naar de documentatie: componenten zonder uitleg over wanneer je ze gebruikt, leiden tot verkeerd gebruik dat de consistentie alsnog ondermijnt.

Let vooral op wat er na oplevering gebeurt. Vraag wie het systeem bijhoudt, hoe een wijziging wordt aangevraagd en wat het kost om er een component aan toe te voegen. Vraag ook of je het systeem in eigendom krijgt en of het bruikbaar blijft als je later met een ander bureau werkt: een systeem dat vastzit aan de werkwijze of infrastructuur van één partij, beperkt je meer dan het oplevert. Vraag ten slotte hoe bestaande pagina’s worden omgezet, want dat is een aparte klus die vaak buiten de offerte valt.

Veelgemaakte fouten

Designsystemen mislukken zelden op de techniek, maar bijna altijd op invoering en onderhoud.

Te veel vooraf willen bouwen. Een systeem met tachtig componenten waarvan er twintig worden gebruikt, kost maanden en levert vooral onderhoudslast op.
Geen eigenaar aanwijzen. Zonder iemand die verantwoordelijk is voor bijhouden en beoordelen van wijzigingen, loopt het systeem binnen een jaar achter op de werkelijkheid.
Ontwerp en code uit elkaar laten lopen. Als de bibliotheken niet gelijk blijven, vertrouwt niemand ze meer en valt iedereen terug op eigen oplossingen.
Bestaande pagina’s niet omzetten. Een systeem naast een ongewijzigde oude site levert twee werelden op, wat de inconsistentie eerder vergroot dan verkleint.

Wat bepaalt de prijs?

De prijs volgt uit het aantal componenten en uit de vraag of er zowel ontwerp als code wordt geleverd. Documentatie is de post die het vaakst wordt onderschat, terwijl die bepalend is voor of het systeem daadwerkelijk gebruikt gaat worden.

Wat de prijs opdrijft	Waarom het meetelt
Aantal componenten	Elk onderdeel moet ontworpen, gebouwd, getest en gedocumenteerd worden in al zijn toestanden.
Ontwerp én code	Een codebibliotheek is een apart bouwtraject naast het ontwerp, inclusief testen en versiebeheer.
Diepte van de documentatie	Richtlijnen over correct gebruik kosten aparte tijd, maar bepalen of het systeem in de praktijk wordt gevolgd.
Omzetten van bestaande pagina’s	Een bestaande site laten aansluiten op het nieuwe systeem is een eigen klus naast het bouwen ervan.

Designsystemen worden vaak in fases aangeboden: een projectbedrag voor de opzet en de eerste set componenten, gevolgd door een maandelijkse of periodieke post voor onderhoud en uitbreiding. Die tweede post is essentieel en wordt door opdrachtgevers regelmatig geschrapt, met als gevolg dat het systeem stilstaat. Vraag bij een offerte expliciet naar de kosten van doorontwikkeling, en naar wat het kost om er later een component aan toe te voegen.

Designsystemen en aanverwante diensten

Een designsysteem raakt aan zowel de ontwerp- als de bouwkant en hangt daardoor tussen meerdere diensten in. UI-design levert de componenten waaruit het systeem bestaat, en is in de praktijk de directe voorloper. Frontend-development bouwt diezelfde componenten als werkende code en beheert de codebibliotheek. Branding en huisstijl levert het fundament aan kleur, typografie en beeldtaal waarop de tokens zijn gebaseerd. Digitale toegankelijkheid wordt bij voorkeur op componentniveau geregeld, waardoor het systeem de meest efficiënte plek is om aan de eisen te voldoen. En webdevelopment is de afnemer die de bouwstenen gebruikt om nieuwe schermen samen te stellen. In de praktijk bieden vooral grotere bureaus dit als aparte dienst aan, omdat het zowel ontwerp- als ontwikkelcapaciteit vraagt over een langere periode.