De belangrijkste lessen die ik heb geleerd bij het maken van een populair ontwerpsysteem

Illustratie door de super getalenteerde Maya Ealey

In 2012 begon ik een klein zijproject om de ontwerppatronen en gebruikerservaring van 12 softwareproducten bij Atlassian te standaardiseren. In de loop van de volgende 3 jaar, veranderde dit kleine zijproject in een zeer groot project dat mijn fulltime baan werd, waarbij verschillende versies van het Atlassian Design System werden gemaakt en verzonden, en het Design Platform-team werd opgericht (dat vandaag nog steeds bestaat, maar met nog veel meer) mensen) om systemen te onderhouden en te benutten in de hele Atlassian-productsuite.

Met de opkomst van discussies over ontwerpsystemen in de afgelopen jaren, werd ik af en toe gevraagd om tips of inzichten uit mijn ervaring met het ontwerpen van het ontwerpsysteem bij Atlassian. Als u heeft overwogen er een voor uw product of bedrijf te maken, bezig bent er een te maken, of hebt geprobeerd en opgegeven, hopelijk helpen deze inzichten u bij het creëren van een beter ontwerpsysteem voor uw bedrijf.

Bij Asana staan ​​we aan het begin van onze reis om een ​​holistisch ontwerpsysteem te bouwen. Ik heb gemerkt dat het nadenken over deze lessen ons heeft geholpen het team en het bedrijf klaar te stomen voor succes, zodat we de echte waarde van een ontwerpsysteem kunnen leveren.

1. Begin met dingen te doen die niet schalen

De allereerste versie van het Atlassian Design System bestond uit ongeveer 20 statische HTML-bestanden die ik onder mijn bureau op een Mac Pro hostte. Er waren geen sjablonen in deze bestanden, geen versiebeheer, ik had de CSS uit onze producten geïmporteerd en ik schreef zelf de opmaak voor elk onderdeel. Deze versie was smerig om bij te werken en was niet schaalbaar, maar genoeg mensen vonden er waarde in dat ik werd geïnspireerd om meer tijd en moeite te investeren die ons op weg hielden om het Atlassian Design System te creëren.

Zonder iets te doen dat niet was geschaald, hadden we er misschien veel langer over gedaan om aan de slag te gaan. Wanneer u aan uw systeem werkt, probeer dan niet te geobsedeerd te raken door over-engineering van een naadloze, perfecte workflow, maar zoek in plaats daarvan naar slordige manieren om te beginnen en blijf gewoon vooruitgang boeken als het werkt.

2. Wapen uw richtlijnen niet

Als u een ontwerpsysteem maakt zodat anderen geen fouten maken die u (en alleen u!) Later moet oplossen, benadert u dit mogelijk niet met de juiste mindset.

Het doel van een ontwerpsysteem is om uzelf (en uw ontwerpteam) op te schalen om producten sneller te bouwen en iedereen in staat te stellen betere ontwerpbeslissingen te nemen.

Een ontwerpsysteem is een hulpmiddel voor empowerment, geen wapen om het ontwerp te beheersen.

Het is echt belangrijk om het regelboek niet naar mensen te gooien en het dood te bewaken. Probeer in plaats daarvan het systeem te benaderen met de filosofie dat een ontwerpsysteem een ​​hulpmiddel is om ontwerp in uw hele bedrijf te democratiseren. Deze aanpak opent echt de deuren zodat mensen willen bijdragen en er deel van uit willen maken. Vergeet niet dat een ontwerpsysteem een ​​hulpmiddel is voor empowerment, geen wapen om het ontwerp te beheersen.

3. "Laten we het allemaal opnieuw ontwerpen"

Weersta de drang om dit als een kans te gebruiken om uw product opnieuw te ontwerpen. Het creëren van een systeem en het tegelijkertijd opnieuw ontwerpen van uw app zal u aanzienlijk vertragen. Het is veel gemakkelijker om te documenteren wat je vandaag hebt, zowel de goede als de slechte patronen, en daarna de slechte patronen te repareren met een herontwerp van de beeldtaal.

Atlassian heeft veel pogingen ondernomen om de productsuite opnieuw te ontwerpen voordat de basis voor het documenteren van onze systeemcomponenten bevredigend was. Het heeft lang geduurd om de architectuur van het systeem te bouwen, maar het maakte het gemakkelijker (en sneller) voor Atlassian om de beeldtaal later te vernieuwen omdat de basis stevig was.

4. Krijg cross-functionele ondersteuning voor uw ontwerpsysteem

Ik geloof dat het creëren van een ontwerpsysteem geen academische oefening is. Als niemand het systeem gebruikt of als het uw team niet heeft geholpen sneller te gaan en betere beslissingen te nemen, verspilt u mogelijk uw tijd.

Door anderen te laten volgen wat u doet en bij te dragen aan het verbeteren van de patronen en richtlijnen, krijgt u de buy-in en ondersteuning die u nodig hebt om echt het verschil te maken en geweldige producten te bouwen. Ik kan niet genoeg benadrukken hoe cruciaal dit is voor het succes van uw systemen.

In 2013 lag de verhouding van ontwerper tot ingenieur in het bereik van 1 ontwerper tot elke 15-20 ingenieurs. Terwijl ik vandaag bij de gedachte aan dat aantal huiver, probeerde ik toen die onbalans in mijn voordeel te gebruiken. Iets dat me hielp de engineeringorg aan mijn zijde te krijgen bij Atlassian was om een ​​praatje te maken voor nieuwe starters tijdens hun eerste week van onboarding bij het bedrijf. Ongeveer 15 mensen zouden er elke week zijn en ik zou ze kunnen laten begrijpen wat we vanaf dag 1 probeerden te doen. Ik zou bijvoorbeeld een geschiedenis doornemen van hoe we vroeger 44 verschillende vervolgkeuzelijsten hadden menu's (niet overdreven), maar we hebben er nu een en hier is hoe je het zou moeten gebruiken.

In de loop van 2013, en met bijna elk jaar een verdubbeling van de Atlassian, had ik ongeveer 500 mensen ingelicht over het belang van ons ontwerpsysteem en hoe ze het kunnen gebruiken. Ik vond dit een zeer effectieve manier om de bedrijfscultuur met betrekking tot design te veranderen.

5. Ga verder dan een stijlgids

Een ontwerpsysteem (of richtlijn) verschilt van een stijlgids. Het is relatief eenvoudig om alle componenten in een Sketch-bestand te hebben - alle primaire knoppen hebben dezelfde kleur of u gebruikt een 8px-raster. Maar wanneer gebruik ik een primaire knop in plaats van een secundaire knop? Wat voor soort labels moeten de knoppen hebben? Wanneer een primaire en een secundaire knop samen zijn, welke bevindt zich links?

Deze vragen zijn het soort dingen dat een ontwerpsysteem zou moeten oplossen, niet alleen het documenteren van de pixelwaarden van uw componenten. Veel ontwerpteams missen dit aspect bij het maken van hun systeem en missen uiteindelijk een krachtige bijwerking van systeemwerk.

Zoals ik hierboven al zei, was het Atlassian-ontwerpteam begin 2013 relatief klein (~ 13 personen) in vergelijking met het engineeringteam (~ 300 personen). Een van de voordelen van het opnemen van schriftelijke richtlijnen was dat ingenieurs enorm veel vooruitgang konden boeken zonder een ontwerper daar. Het betekende dat we konden stoppen met het ontwerpen van schermen in Sketch en in plaats daarvan op een whiteboard springen en over een stroom brainstormen, of beginnen te werken aan veel grotere productproblemen die stroomopwaarts bestonden.

6. Laat iemand het systeem overzien, maar zorg ervoor dat iedereen bijdraagt

We gebruikten een gecentraliseerd model waarmee elke ontwerper in het bedrijf kon bijdragen. We hadden ook een rotatieprogramma van ~ 3 maanden waarbij ontwerpers en ingenieurs uit hun respectieve producten werden gehaald en samen met het Design Platform-team het systeem vooruit zouden helpen. Ze zouden een grote bijdrage leveren terwijl ze in ons team zaten, en dan terugkeren naar hun oorspronkelijke productteams die voorstander zijn van het systeem.

Iemand toezicht houden op het systeem is heel, heel belangrijk. Deze persoon (ik bij Atlassian) is waarschijnlijk een Designer-maanlicht als Product Manager. Ze moeten het systeem beschermen, maar moeten heel voorzichtig zijn om geen omgeving te creëren waarin mensen het afwijzen en schurkenstaten worden. Vergeet niet dat het doel van het systeem is om iedereen binnen het bedrijf een betere ontwerper te maken.

Wilt u meer weten over Asana? We hebben een nette site op https://asana.design met een beetje over wie we zijn en wat we doen. We nemen ook Design Managers en Product Designers aan in ons kantoor in San Francisco, een van de beste plekken om te werken in 2018 in de VS! (We kunnen u verplaatsen als u zich momenteel niet in de Bay Area bevindt.)

Als je dit bericht leuk vond, wil je misschien onze publicatie volgen voor meer verhalen van Asana Design