[Update] Dit artikel is geschreven in een tijd dat Sketch nog groter was in gebruikers dan Figma. Daarom is de inhoud van dit artikel wat gedateerd.
Bij Pixelpillow zijn we altijd op zoek naar verbeteringen in ons werkproces. Hier besteden we dan ook veel tijd aan, en deze kennis delen we graag met iedereen. In deze blogpost gaan we in op ons ontwerpproces en de vertaling naar de ontwikkeling.
Al vanaf het moment dat er meerdere designers bij Pixelpillow aan de slag zijn lopen we vaak tegen hetzelfde probleem aan. Effectief samenwerken in Sketch. Elke ontwerper heeft natuurlijk zijn eigen werkwijze. Bij Pixelpillow is dat niet anders. Vaak merken we dat wanneer een bestand overgedragen wordt naar een andere ontwerper, er bijna een handleiding bij moet omdat die persoon een hele andere manier van werken heeft. Daarom zijn we gaan kijken hoe we dit ontwerpproces kunnen stroomlijnen zodat we effectiever kunnen samenwerken en het voor iedereen makkelijker wordt om een document op te bouwen.
Wanneer er met meerdere ontwerpers aan een project gewerkt wordt is het van belang dat je goed van elkaar weet wat je doet. Anders kost het veel tijd om bestanden over te dragen en elkaar up-to-date te houden. Ook wanneer je voor een langere tijd niet aan een project hebt gewerkt is het soms weer even zoeken als je weer door het bestand heen gaat. Daarom is het handig om een duidelijke en uniforme manier van werken te hebben, die voor iedereen hetzelfde is, om zo min mogelijk tijd te verspillen.
We hebben niet alleen gekeken hoe we het ontwerpproces konden verbeteren, maar hebben het direct doorgetrokken naar front-end. Alles wat wij designers maken komt uiteindelijk bij de front-end developers terecht. Als ontwerpers weer eens een super mooie animatie hebben bedacht, die iets complexer blijkt te zijn dan gedacht krijgen we van onze front-end collega’s op onze kop ???? Dus betrokken we onze technische collega’s en verbeterden we samen het proces, van ontwerp tot front-end. Win-win voor iedereen dus.
Het programma waarin wij al onze ontwerpen maken is Sketch. Sketch is een programma wat gemaakt is voor digitale ontwerpen. Oftewel, perfect voor ons werk. Bijna perfect tenminste, want als dat zo was dan had ik dit artikel niet hoeven schrijven. Natuurlijk zijn er alternatieven. Behoorlijk veel zelfs. Hiervan hebben we er meerdere uitgeprobeerd. Denk bijvoorbeeld aan Figma, Framer, InVision Studio en Adobe XD. Allemaal hebben ze hun sterke en zwakke punten. Maar onder de streep komen we toch telkens weer bij Sketch uit.
Dit heeft vooral te maken met het feit dat we al onze projecten nu in Sketch gemaakt hebben. Mochten we overstappen naar een ander programma moeten we alle bestanden overzetten wat veel tijd in neemt en mogelijke problemen met zich meebrengt. Voor projecten waar je vanaf nul begint is dit niet zo’n probleem. Maar veel projecten waar we aan werken hebben een looptijd van maanden of zelfs jaren, waardoor een overstap niet zo makkelijk is als het lijkt.
Bij Pixelpillow wordt Sketch al bijna sinds versie 1 gebruikt, al jaren dus. Zelf ben ik pas sinds een jaar fanatiek Sketch gebruiker. Pas toen ik bij Pixelpillow kwam werken ben ik het voor het eerst gaan gebruiken. Inmiddels is het niet meer weg te denken uit mijn proces. Ik gebruik nu bijna overal Sketch voor. Voorheen was ik juist groot fan van Adobe Illustrator, InDesign en Photoshop, maar deze gebruik ik nu nauwelijks nog. Het enige moment waarop ik nog een Adobe programma gebruik is als ik iets als drukwerk moet ontwerpen, wat bij Pixelpillow maar erg weinig voorkomt.
De afgelopen tijd hebben we eens kritisch gekeken naar hoe we werken in Sketch en hoe we dit kunnen verbeteren. Omdat elke designer bij Pixelpillow anders werkt hebben we gekeken naar wat deze verschillen zijn en deze hebben we in kaart gebracht. Vervolgens hebben we ook het development team erbij gehaald en gekeken waar zij tegenaan lopen.
Waar we als ontwerpers keer op keer tegenaan lopen is het gebruik van symbolen en de opbouw hiervan. Symbolen zijn ‘herbruikbare stukjes ontwerp’. Denk bijvoorbeeld aan een input veld of een button. Deze zijn vaak door het hele ontwerp hetzelfde, dus bespaart het veel tijd als je hier direct een symbool van maakt. We hebben gemerkt dat de designers in ons team hier allemaal verschillend mee om gingen. De een maakt al vanaf het begin symbolen, de ander pas als het echt nodig is en de stijl vaststaat. Wanneer je dan verder werkt in het document van een collega, en er zijn geen symbolen gemaakt voor veel voorkomende componenten, dan is het lastig om snel verder te kunnen ontwerpen, of je loopt het risico op inconsistenties in het ontwerp.
Om dit in de toekomst te voorkomen hebben we duidelijke richtlijnen voor het maken en gebruiken van symbolen opgesteld. Om te beginnen hebben we besloten dat als je een element vaker dan drie keer gebruikt, je er een symbool van maakt. Zo voorkom je wildgroei en extra werk. Stel dat je later dat element moet aanpassen, dan hoef je niet je hele document te doorzoeken om te kijken of alles wel hebt aangepast.
Ook de opbouw van symbolen is belangrijk. Stel bijvoorbeeld de constraints goed in, deze zorgen ervoor dat je symbool goed schaalbaar is en daardoor niet stuk gaat. Ook is het handig om in te stellen wat je wel en niet kan overriden in het symbol. Wanneer dit allemaal goed ingesteld is kom je later niet in de problemen en voorkom je dat je hele ontwerp omvalt wanneer er iets gewijzigd wordt.
Elk symbool, kleurstijl en tekststijl krijgt zijn eigen naam in het ontwerp, maar hoe noem je deze dingen nu? Stel je hebt een knop ontworpen, dan ligt het voor de hand deze ‘button’ te noemen. Klinkt logisch. Maar vervolgens krijg je hier variaties op, en daar begint het lastig te worden met naamgeving. Hoe noem je een button met een icoon? Hoe noem je een hover variant? Hoe noem je een secundaire button? Daar liepen we steeds tegenaan.
Om dit te tackelen hebben we een naamgeving structuur bedacht. Ten eerste willen we niet doorslaan in het structureren van elementen. Je wilt bijvoorbeeld niet meer dan 3 lagen diep hoeven zoeken naar een symbool of tekststijl want dan kost het teveel tijd.
Ook hebben we ervoor gekozen om kleuren altijd een unieke naam te geven en deze altijd in meerdere tinten op te bouwen. Zo zijn deze in front-end ook makkelijker te gebruiken en zijn ze altijd in lijn met het ontwerp. Als de ontwerper het dan over een bepaalde kleur heeft, weet de developer direct welke je bedoeld.
De problemen die hierboven genoemd zijn maken het ook voor de front-enders lastig om een ontwerp makkelijk te implementeren. Als wij ontwerpers telkens andere namen bedenken in onze ontwerpen weet een front-ender op een gegeven moment ook niet meer precies hoe alles opgebouwd is. Daarom hebben we bij het zoeken van een oplossing ook het front-end team nauw betrokken. Zo maken we het niet alleen onszelf makkelijk, maar helpen we ook de front-enders een beetje mee. En misschien nog wel belangrijker, de kwaliteit van ons werk is constant. En dat zorgt voor een geweldige gebruikservaring.
Bij het bedenken van de naamgeving structuur hebben we daarom ook gedacht aan de implementatie in front-end. Hierbij hebben we gekeken naar hoe in bijvoorbeeld CSS tekststijlen en kleuren worden opgebouwd. We zorgen er nu voor dat deze opbouw in Sketch hetzelfde is als in de code. Zo geven we bijvoorbeeld duidelijke namen en benoemen we varianten op dezelfde manier als hoe dat in SASS gebeurt. Zo hoeven de front-enders niet het hele Sketch bestand te ontleden om te kijken welke kleuren en tekststijlen er voorkomen, maar is er gewoon een duidelijke lijst die 1-op-1 overgenomen kan worden.
Het enige wat we op dit moment erg missen in Sketch is de mogelijkheid om samen te werken in hetzelfde bestand. Nu vraag je je misschien af, waarom stappen jullie niet over op Figma? Dat hebben we zeker overwogen, meerdere keren zelfs. Deze stap is alleen vrij groot en best lastig te maken. Het kost tijd voor iedereen om zijn weg te vinden in een nieuw programma en dat willen we liever niet. Daarnaast zit je natuurlijk met het feit dat alle bestanden omgezet moeten worden en dat gaat niet altijd even goed. Kortom: een hoop gedoe, dus dan moet ‘t wel de moeite waard zijn.
Samenwerken in hetzelfde bestand is op dit moment nog niet mogelijk in Sketch. Het zit er wel aan te komen, en wij kunnen niet wachten. Maar tot die tijd hebben we een tijdelijke oplossing bedacht. Namelijk het gebruik van libraries. Een library is een extern bestand waarin je alle symbolen en stijlen kan plaatsen. Deze functionaliteit zit alweer een tijdje in Sketch maar we zijn er nooit echt ingedoken, tot nu. We zijn er eens goed ingedoken en het blijkt best handig te zijn. We kunnen nu deels samenwerken aan projecten. De ene ontwerper maakt alle symbolen op orde en werkt in de library, de ander is bezig met het ontwerpen van het product. Zo werk je eigenlijk in twee verschillende bestanden, maar zijn ze wel aan elkaar gekoppeld.
De meeste tijd gaat bij ieder project zitten in de eerste opbouw van het document. Eigenlijk heb je altijd dezelfde set aan basiselementen nodig die in iedere website voorkomen. Dit zijn de ‘symbolen’ die hierboven genoemd zijn. Keer op keer zijn we uren bezig om al deze elementen op orde te krijgen en hier goede symbolen van te maken, terwijl ze in de basis vrijwel altijd hetzelfde werken.
Om dit proces zo makkelijk mogelijk te maken hebben we een voorbeeld document gemaakt welke volledig is opgebouwd volgens onze richtlijnen. In deze toolkit vind je alles wat je nodig hebt om een project op te zetten. Kleuren, typografie, alle mogelijke buttons, inputs en ga zo maar door. Als je het dan even niet meer weet, kun je gewoon kijken hoe het ook alweer zat. En natuurlijk kan je het document ook als basis gebruiken voor ieder project. Dan hoef je ook niet telkens helemaal opnieuw te beginnen met het opbouwen van een document.
Bij Pixelpillow wordt Sketch al bijna sinds versie 1 gebruikt, al jaren dus. Zelf ben ik pas sinds een jaar fanatiek Sketch gebruiker. Pas toen ik bij Pixelpillow kwam werken ben ik het voor het eerst gaan gebruiken. Inmiddels is het niet meer weg te denken uit mijn proces. Ik gebruik nu bijna overal Sketch voor. Voorheen was ik juist groot fan van Adobe Illustrator, InDesign en Photoshop, maar deze gebruik ik nu nauwelijks nog. Het enige moment waarop ik nog een Adobe programma gebruik is als ik iets als drukwerk moet ontwerpen, wat bij Pixelpillow maar erg weinig voorkomt.
Na al deze ophelderingen zijn we bezig om deze richtlijnen ook te implementeren in onze dagelijkse werkzaamheden. We zijn ons bewuster van hoe we te werk gaan en hoe we een project beginnen. We zijn nu al een tijdje bezig om de best practices te volgen en hebben gemerkt dat het samenwerken een stuk soepeler verloopt dan voorheen. In de toekomst kan het alleen maar beter worden!
