Acht dingen die u moet weten over ontwerpsystemen

Ik heb heel wat lezingen bijgewoond, dus dat hoeft niet.

Het staat op elke functiebeschrijving. Je ziet het overal in de nieuwste versie van de ontwerptool. Je hebt misschien zelfs je familie het horen noemen op Thanksgiving. Maar wat zijn de feiten op deze "ontwerpsystemen" waar de hele branche over praat?

Het overbruggen van ontwerp en engineering is van groot belang geweest sinds ik ben overgestapt op ontwerp van software engineering, dus ik wilde alles leren over ontwerpsystemen zodra ik hoorde dat het krachtige hulpmiddelen waren voor ontwerpteams en hun belanghebbenden bij de engineering. Gelukkig hebben RETHINK en SF Design Week de afgelopen maand heel wat evenementen over dit onderwerp georganiseerd en ik heb geprobeerd ze allemaal te bezoeken.

Dat betekent dat ik meer dan vijftien verschillende lezingen van ontwerpers in verschillende organisaties heb bezocht. Elke ontwerper bracht unieke, bruikbare inzichten over ontwerpsystemen. Daar zijn ze.

Dit is een langere tijd, dus ik heb wat liberale vetgedrag toegepast als je de belangrijke stukjes wilt scannen.

1. Waarom ontwerpsystemen belangrijk zijn.

Bron. Figma’s designsystems.com is hun bron voor het leren van ontwerpsystemen.

Diana Mounter, Design Systems Manager @ GitHub, vatte het vrij goed samen:

  • Ontwerpsystemen brengen orde in chaos. Iedereen wordt op dezelfde pagina gehouden, dus het hele product blijft consistent en gepolijst.
  • Ontwerpsystemen verbeteren de gebruikerservaring door herhaaldelijk gebruik van bekende en bewezen patronen. Alles vanaf nul ontwerpen laat ruimte voor fouten, dus probeer te gebruiken wat al werkt.
  • Ontwerpsystemen verbeteren de workflow-efficiëntie. Productteams weten precies hoe componenten van nieuwe functies eruit moeten zien en hoe ze te implementeren.

Noah Levin, Head of Design @ Figma, reed echt het laatste punt naar huis. Hij predikte de filosofie van herhaalbaarheid in zijn toespraak en legde uit dat het beste wat je kunt doen nadat je je tijd hebt besteed aan het bouwen van een nieuw pictogram, is om die oefening voor de volgende persoon te automatiseren. Hiermee heeft u niet alleen waarde aan uw eigen werk gebracht, maar ook aan het werk van de hele organisatie. Voor Noah, Gedrag = Motivatie * Vermogen * Trigger. Wanneer iemand in uw team wordt geactiveerd om een ​​ontwerp te voltooien, kunnen we weinig doen om hun motivatie te veranderen, maar we kunnen zoveel doen door ontwerpsystemen om hun vermogen te verbeteren. Het eindresultaat is gedrag dat zoveel sneller een consistenter, bewezen ontwerp oplevert.

2. Wat een ontwerpsysteem is.

Karri Saarinen, Design Systems Lead @ Airbnb, gaf deze definitie:

Een reeks gedeelde, geïntegreerde patronen en principes die het algemene ontwerp van het product bepalen

Als je weinig ervaring hebt met ontwerpsystemen, kan een zo brede definitie als dubbelzinnig of nutteloos worden opgevat. Het gebrek aan detail is echter cruciaal. Ontwerpsystemen vereisen geen specifiekere definitie. Ze hebben de ruimte nodig om te zijn wat een organisatie nodig heeft voor ontwerp en de implementatie ervan om snel te kunnen bewegen zonder dingen te breken.

Maar hier is een beetje meer info, rechtstreeks van de man:

Blader door bestaande ontwerpsystemen om beter te begrijpen wat ze in de praktijk zijn. Hier is het materiaalontwerp. Dit is Protocol door Mozilla. En hier zijn de iOS Human Interface Guidelines, die we officieel geen ontwerpsysteem noemen om een ​​genuanceerde Apple-reden, net zoals waarom we de HomePod geen slimme luidspreker zouden moeten noemen. Al deze systemen zijn anders gebouwd, maar begrijpen hoe ze allemaal binnen de grenzen van Karri's definitie passen.

Je vraagt ​​je misschien af ​​waarom de componenten die je in Sketch hebt samengevoegd slechts worden beschouwd als "patroonbibliotheken", "stijlgidsen" of "UI-kits". Mike Dick, Design Technologist @ SurveyMonkey, begon eigenlijk met een van deze UI-kits toen hij de elementen ging samenstellen, maar hij ging terug naar de tekentafel toen hij het aan engineering begon te tonen. In plaats van een systeem van componenten voor ontwerpers te bouwen, implementeerde Mike een enkele bron van waarheid voor ontwerp om te integreren met engineering. Ontwerpen die met dit ontwerpsysteem zijn gebouwd, kunnen gemakkelijk worden vertaald naar CSS, de taal die wordt gebruikt om de stijl te definiëren, en kunnen daarom snel ontwerpwijzigingen in hun front-end componenten trapsgewijs doorvoeren. Met voldoende middelen kunnen grotere organisaties zoals AirBnb tooling implementeren die schermen die met hun ontwerpsysteem zijn gebouwd rechtstreeks naar code vertaalt (dit is waarom Framer X zo belangrijk is).

Terugkijkend op de definitie van Karri zien we een vermelding van principes. Dit wil zeggen dat ontwerpsystemen regels en richtlijnen bevatten die gebruikers informeren over hoe de patronen en stijlen die in het systeem zijn georganiseerd, kunnen worden geïmplementeerd. Rich Fulcher, hoofd materiaalontwerp @ Google, legde uit waarom principes een bepalend onderdeel van het systeem waren: omdat een ontwerpsysteem alleen echt bestaat als het zonder de maker kan worden gebruikt.

3. Elk ontwerpsysteem is beter dan helemaal geen ontwerpsysteem.

Diana Mounter, GitHub

Het ontwerpsysteem van GitHub, Primer, werd intern en privé vernieuwd. Dat deed Diana, deels omdat haar team geconfronteerd werd met het Imposter-syndroom dat Primer vergeleek met de systemen van volwassen en grotere organisaties zoals de DLS van AirBnb, de Polaris van Shopify en het Amerikaanse Web Design System. Primer voelde in vergelijking ongepolijst. Veel componenten zijn verouderd.

Maar weet je wat erger is dan weten dat een onderdeel is verouderd? Niet wetende en die wreedheid naar productie duwen.

Primer en andere systemen gebruiken vlaggen om snel aan te geven of componenten al dan niet zijn verouderd.

Dat is de reden waarom Diana zegt dat je je geen zorgen moet maken over het vergelijken van je ontwerpsysteem met het systeem van een andere organisatie, want dat is niet wat het succes bewijst. In plaats daarvan zegt Diana, duw je ontwerpsysteem eruit en analyseer je het gebruik om het succes ervan te meten. Chaos zal een natuurlijk onderdeel zijn van iets dat zo nieuw is in de praktijk als ontwerpsystemen, dus focus op wat belangrijk is en profiteer van de chaos. Gebruiken mensen het ontwerpsysteem in hun workflow en dragen ze eraan bij om het te verbeteren?

Er is geen twijfel dat systemen zoals Polaris, iOS HIG en Material Design opmerkelijk grondig en zelfs cool zijn om naar te kijken. Maar deze systemen zijn niet alleen gebouwd door bedrijven met enorme middelen, ze zijn vooral gericht op externe belanghebbenden die er niet onder werken. Het komt gewoon met het territorium.

Diana toonde deze grappige blunder. Idealiter zouden componenten de leesbaarheid van de geïllustreerde code niet belemmeren.

Diana beëindigde haar toespraak met een tweet om Primer te delen met de wereld, fouten en zo. Op deze manier biedt het systeem van GitHub belanghebbenden: 1. Toegang tot zijn middelen, en 2. Mogelijkheden om de tekortkomingen van het systeem te verbeteren.

4. Hoe aan de slag te gaan op een ontwerpsysteem.

Het eerste wat je ziet bij Shopify's Polaris.

Allereerst heb je een hippe naam nodig. Zodra je Polaris leest, weet je dat je naar je goed ontworpen redding wordt geleid.

Grapje. Material Design had pas officieel een titel tot een maand voordat het werd gepubliceerd. Rich Fulcher zei dat het meestal intern bekend stond als ‘Quantum Paper’.

En begin ook niet met een schetsbestand! Michael McCombie, Systems Designer @ Mozilla, maakte die fout eenmaal. Zodra hij andere belanghebbenden had aangetrokken, moest hij opnieuw beginnen. Een ontwerpsysteem is een stuk ontwerp dat gebruikersproblemen oplost. Begrijp eerst het probleem en de gebruikers.

Toen Jordan Girman, Sr. Director User Experience @ Glassdoor, het eerste ontwerpsysteem van Glassdoor wilde maken, liet hij het team beginnen met deze vragen:

  1. Wat is de noodzaak voor dit systeem?
  2. Hoe wordt ontwerp nu geïmplementeerd?
  3. Hoe moet het worden geïmplementeerd?

Van daaruit stellen ze doelen en vereisten voor hun ontwerpsysteem die aansluiten bij de rest van de organisatie. Die afstemming, zoals uitgelegd door Mike Dick, berust op een relatie. Zonder een relatie met uw stakeholders, zult u een aantal uitdagingen tegenkomen:

  • Niemand zal dezelfde taal spreken. "Stijlgids" betekent twee verschillende dingen voor ingenieurs en ontwerpers. Hoe weet u of uw terminologie en documentatie door iedereen worden begrepen?
  • Iedereen aan boord krijgen met uw ontwerpsysteem zal een stuk moeilijker zijn. Uw mensen zullen de waarde niet begrijpen van iets dat ze niet hebben helpen creëren.
  • Niemand zal weten wat de bron van waarheid is. Kus je consistentie vaarwel.
Wat een ingenieur denkt als je zegt: 'stijlgids'

Mike raadt vooral aan om een ​​tegenpartij te vinden die je vaardigheden aanvult met een gedeelde passie voor het overbruggen van de kloof tussen ontwerp en techniek. Als je geen goede programmeur bent, maak dan vrienden met iemand die een uitstekende programmeur is met een diep begrip van de technische stacks. Daardoor kon Mike begrijpen dat het documenteren van CSS, in plaats van het opnieuw definiëren van systeemcomponenten, cruciaal was voor engineering om het systeem optimaal te gebruiken.

Ik raad je aan Medium te zoeken naar bronnen over welke hulpmiddelen je moet gebruiken en hoe je ze kunt gebruiken om je ontwerpsysteem te bouwen. Je wilt het niet van mij horen, want ik ga gewoon iets zeggen over Figma.

5. Ontwerpsystemen documenteren alles.

Microsoft's vloeiende documentatie over keuzerondjes.

Nadat u de doelen en vereisten van uw systeem met belanghebbenden hebt vastgesteld, is het een goede plek om uw overkoepelende, leidende ontwerpprincipes te bepalen. Met geweldige ontwerpprincipes kunt u uw systeem uitbouwen met een consistentie die overeenkomt met uw doelen, en ze kunnen een snelkoppeling zijn naar de vloeiendheid van uw gebruiker door het hele systeem. Nogmaals, ik raad je aan een kijkje te nemen in bestaande, robuuste ontwerpsystemen zoals Polaris om de beste voorbeelden van principes in de praktijk te vinden. Wanneer je begint met het maken van je eigen, hadden Rich Fulcher en Selene Hinkley, Content Strategist @ Shopify, een paar dingen om in gedachten te houden:

  • Velen willen zelfs geen principes lezen; als ze lezen, kunnen ze scannen. Als ze scannen, begrijpen ze het misschien niet. Als ze het niet begrijpen, zullen ze zeker niet van toepassing zijn. Dus begrijp uw publiek bij het maken van uw exemplaar en inhoud!
  • Wees leidend, niet normatief. Laat ruimte voor creativiteit door een spectrum te geven van wat acceptabel is. Principes moeten een leidraad zijn voor de besluitvorming.
  • Beperk het aantal principes. Shopify begon met 13, maar ze hebben het nu teruggebracht tot 4. Ze hebben de principes van 'top down' en 'middle management' verwijderd die niet veel deden voor degenen die het ontwerp dagelijks uit de eerste hand ontwierpen en implementeerden werk. Grassroot-principes zijn goud.
  • Geef je principes weer in wat je creëert. Voor het type gebruiker dat verwijst naar het ontwerpsysteem in context en dit leert door middel van voorbeeld, zal dit veel doen om uw principes te verankeren en consistent te blijven.
  • Ze kunnen uw merk- of productprincipes niet beperken. Ontwerpsystemen moeten subsystemen van uw organisatie zijn, dus zorg ervoor dat ze binnen het geheel passen.
  • Blijf je principes evolueren. Pas gebruikersgericht ontwerp toe op het creëren van uw principes, zodat deze uw systeem en realiteit nauwkeurig weerspiegelen. Anders wordt de consistentie afgebroken naarmate andere gebruikers uw principes toepassen.

Voeg daar de componenten van uw ontwerpsysteem toe en zorg ervoor dat u hun specifieke principes documenteert. Dingen zullen zoveel sneller gaan, geen idee hoe teamgenoten je lastig vallen, en je naam zal niet worden vervloekt als je er niet bent. Dit is wat Selene te zeggen had over het documenteren van je ontwerpsysteem:

  • Breek alinea's op in opsommingstekens en lijsten.
  • Gebruik waar mogelijk visuele voorbeelden.
  • Houd zinnen kort en uitvoerbaar.
  • Gebruik dos / don'tts.
  • Maak uw zaken minder voor de hand liggend. Modelleer ze naar realistische fouten die kunnen voortvloeien uit een verkeerde interpretatie
Bron: material.io

6. Ontwerpsystemen moeten toegankelijkheid integreren.

Bekijk deze tool voor het controleren van toegankelijke contrastverhoudingen op WebAIM.

John Cassidy, Senior Designer @ Google, begon zijn toespraak met een dikke stat:

1 op de 7 mensen is gehandicapt. Dat zijn meer dan een miljard mensen.

Toch had John meer te zeggen. Een gebruiker wordt uitgeschakeld zodra zijn handen vol zijn met boodschappen. Als ze merken dat ze in een vreemd land reizen zonder lokale taalvaardigheden, zijn ze uitgeschakeld. Als je lang genoeg leeft, zul je waarschijnlijk op een dag permanent uitgeschakeld worden.

Als je nog niet overtuigd bent, heeft John dit advies voor het toegankelijk maken van je ontwerpsysteem.

  • Pas toegankelijkheidsgerichte ontwerpbeperkingen toe. Zorg ervoor dat uw componenten rekening houden met scenario's die toegankelijkheid nodig hebben, zoals het formaatformaat voor verziendheid en alt-tekst voor schermlezers. Vergeet tijdelijke handicap niet; wat als uw product wordt gebruikt door chauffeurs bij helder daglicht?
  • Meer informatie over de toegankelijkheidstechnologie die beschikbaar is voor uw gebruikers. OS-technologie zoals iOS Vergrootglas en Windows Narrator zijn het meest beschikbaar, maar add-on producten zoals de Xbox Adaptive Controller bestaan ​​ook. En sommige technologie is niet beperkt tot gebruik door gehandicapte gebruikers, vooral stemassistenten.
  • Test uw componenten met deze toegankelijkheidstechnologieën ingeschakeld. Erg makkelijk. Schakel technologieën zoals iOS VoiceOver in en zorg ervoor dat ze op een nuttige manier met uw systeemcomponenten werken.
  • Test uw product met gebruikers met verschillende handicaps. Natuurlijk moet u uw product zichtbaar maken voor gebruikers met een spectrum van verschillende mentale, fysieke en situationele handicaps.
De Xbox Adaptive Controller van Microsoft is een van de nieuwste toegankelijkheidstechnologieën voor gebruikers.

7. Kleur en illustratie kunnen en moeten systematisch zijn.

Shopify's Polaris-kleurenpalet

Uw organisatie heeft misschien al merkkleuren die handig zijn voor het invullen van uw gebruikersinterface, maar niet zo snel. Kies uw UI-kleuren niet door uw merkkleuren te kopiëren en te plakken. Merkkleuren houden geen rekening met bruikbaarheid, hoewel het afleiden van uw basiskleuren van uw branding waarschijnlijk de beste plaats is om te beginnen. Linda Dong, Design Manager @ Lyft, beveelt aan dat u spectrums van merkkleuren met overlaytekst maakt om te kiezen voor UI-kleuren die voldoen aan toegankelijke kleurverhoudingen. Test dit allemaal natuurlijk in de situaties waarin uw product wordt gebruikt. Lyft moet in het holst van de nacht en op de helderste dagen voor chauffeurs werken.

Wanneer u kiest voor uw kleuren, verwijs dan niet naar die kleuren in uw ontwerpsysteem met hun hex-code of hun "officiële" naam. Linda wees hierop met een grappige quiz voor het benoemen van kleuren. Blijkt dat die duif een middelgrijze kleur heeft. Noem me ongefundeerd, maar ik denk dat Pidgeon is wat je zoekt.

Definieer in plaats daarvan uw kleurenschema door middel van kleurtokens. Michael McCombie en het Protocol-systeem gebruiken basiskleurnamen zoals $ color-red, terwijl Linda en Lyft een $ ColorName-Value-indeling gebruiken vanwege hun kleurenspectrum. Neem natuurlijk al uw stakeholders mee terwijl u uw kleursysteem bouwt - en adverteer het wanneer het klaar is - om acceptatie te garanderen.

Jennifer Hom, Experience Design Manager van Illustration @ Airbnb, kwam aan boord om hun illustratiesysteem te vernieuwen. Eerder had Airbnb illustraties gedeeld over verschillende formaten of verschillende illustraties tussen verschillende formaten. Jennifer veranderde illustraties in systematisch verhoogde vectorgewichten en detail naarmate de exportgroottes toenamen (1x, 2x, 3x), waardoor een consistent maar platformgeschikt ontwerp tussen apparaten mogelijk werd.

Jennifer moest ook rekening houden met deze principes voor je illustratiesysteem:

  • Zorg ervoor dat uw illustraties geaard zijn. Illustraties zouden de meeste, zo niet iedereen, betrekking moeten kunnen geven op uw product en zonder na te denken over minutae.
  • Laat uw illustraties niet in de schijnwerpers staan. Ze moeten de vreugde vergroten zonder de gebruiker van hun doel af te leiden.
  • Gebruik toegankelijke kleuren. Controleer uw kleurverhoudingen!
  • Wees divers, maar realistisch. De illustraties van Airbnb zijn gebaseerd op echte mensen, dus ze "kenmerken" Donald Glover en de willekeurige Facebook-vrienden van Jennifer. Airbnb sprak ook met organisaties en autoriteiten over handicaps die hen op het idee brachten om een ​​subtiel signaal zoals een koptelefoon te gebruiken.
  • Test je illustraties. Oh man, kun je het geloven? Dit ontwerp moet ook worden getest. Door de China-specifieke illustraties aan het kantoor in Beijing te laten zien, kon Jennifer erachter komen dat Chinese mannen met een dikke borst niet de meest betrouwbare waren.

8. Hoe een ontwerpsysteem te schalen.

Karri Saarinen: Hoe een ontwerpsysteem met schaal evolueert.

Wat is dat? Uw bedrijf heeft zojuist een serie C aangekondigd! Binnen 3 maanden wordt van je verwacht dat je een volledig pakket met apps op elk platform hebt en een team van Not-Yous dat elk beheert.

Wees niet bang. Anderen hebben de overkant gehaald. Zo denkt Karri dat je je ontwerpsysteem kunt schalen:

  • Gebruik gedefinieerde primitieven. Definieer de kleurenschema's, tekststijlen, rasters, enz. Die de bouwstenen zullen zijn voor elke toevoeging aan uw ontwerpsysteem. Alle kerncomponenten en teamspecifieke bibliotheken van Airbnb zijn gebouwd met dezelfde set primitieven.
  • Bouw je componenten met behulp van die primitieven en bouw je patronen met die componenten. Dit zorgt voor consistentie en biedt tegelijkertijd een zekere flexibiliteit en kneedbaarheid.
  • Blijf flexibel. U hebt flexibiliteit nodig om ruimte te bieden, tekst af te kappen, verschillende tekstgroottes voor toegankelijkheid en internationalisering, verschillende kleurkeuzes, aangepaste componenten en goede creativiteit.
  • Maak uw ontwerpspecificaties platform-agnostisch. DLS definieert hun componenten in JSON, een alomtegenwoordige datastandaard die automatische vertaling mogelijk maakt naar platformspecifieke stijlen zoals CSS.
  • Voeg teamspecifieke bibliotheken toe, maar houd ze onder controle. Airbnb beperkt hun teambibliotheken tot experimentele en specifieke componenten. Dus, teambibliotheken worden gemonitord en componenten worden de keten in gestuurd als ze geschikte kerncomponenten zijn. 70 componenten vormen 60% van de front-end van Airbnb op alle platforms!

Grote dank aan de ongelooflijke sprekers: Diana Mounter, Noah Levin, Karri Saarinen, Rich Fulcher, Michael McCombie, Linda Dong, John Cassidy, Jennifer Hom, Selene Hinkley en Jordan Girman. En dankzij Julie Stanescu (samen met haar team bij Rethink) en SF Design Week voor het organiseren van hun geweldige lezingen!

Ten slotte, dankzij Jasmine Rosen en Jodee Cherney voor het bewerken en de rest van Tradecraft voor hun voortdurende steun, en Tyler Heucke voor mijn "technische tegenhanger".