Hoe we een Atomic-ontwerpsysteem hebben gebouwd met Sketch-bibliotheken @Capital Float

Geleerde lessen bij het opzetten van een modulair ontwerpsysteem in een FinTech-bedrijf.

Omdat we een startup waren met een paar ontwerpers, werkten we aan verschillende producten en hoefden we elkaar nooit te kruisen! Maar al snel begonnen onze producten er anders uit te zien! Of het nu interne dashboards zijn of klantgerichte mobiele applicaties, de meeste van onze ontwerpen waren afhankelijk van het raamwerk om te passen bij onze snelle productontwikkeling.

We realiseerden ons al snel dat we onze producten moesten verenigen. De enige manier om dat te doen was om een ​​visuele richtlijn te definiëren. Maar hoe en waar te beginnen?

Weinig brainstormbijeenkomsten en een maand later hebben we onze eerste stijlgids opgesteld.

Onze eerste stijlgids

We gebruikten Sketch-sjabloon als onze boilerplate, we hebben nog geen symbolen gemaakt! Nadat we dit bestand enkele weken hadden gebruikt, werden we geconfronteerd met problemen. Als startup werkten we aan meerdere functies en zagen we de inconsistentie in ontwerpen omdat onze ontwerpen veel meer waren dan alleen kleuren en typografie. Ook was het moeilijk om synchroon te blijven via het delen van bestanden. Het was zonde van het beheer van zoveel bestanden. De moeilijkheid van het overbrengen van ontwerp naar ontwikkelaars was een andere uitdaging. Ons doel om een ​​ontwerpsysteem te bouwen is niet gelukt!

Tijd om het echte ontwerpsysteem uit te voeren en te bouwen

Als computeringenieur die UX-ontwerper werd, kende ik de kracht van modulariteit. Maar hoe het te doen voor het ontwerp, ik had geen idee waar ik moest beginnen! Omdat ik een grote Google-ontwerp bewonderaar was, begon ik reverse-engineering en ondervroeg ik hun materiaalontwerpsysteem. Ik heb ook Bootstrap en Angular framework onderzocht om te begrijpen hoe ze componenten hebben gedefinieerd.

Doelstellingen van onze bibliotheek

Om een ​​deel van het denken dat bij onze beslissingen is betrokken te begrijpen, volgt hier een kort overzicht van wat we probeerden te bereiken met ons ontwerpsysteem:

  1. Gestandaardiseerde elementen en een uniform ontwerpsysteem voor al onze producten, ongeacht het platform.
  2. Creëer een 1: 1 match zoveel mogelijk met onze gecodeerde componenten en schetssymbolen, zowel visueel als structureel.
  3. Makkelijk te onderhouden. Componentenupdates of -toevoegingen moeten eenvoudig zijn, zodat ontwerpers en ontwikkelaars zonder veel wachten op de hoogte blijven.

Eerste ding eerst

Voordat we verder gaan met wat we allemaal moeten toevoegen, moesten we bepaalde regels definiëren om elementen in ware zin herbruikbaar en atomair te maken. Dus besloten we te kiezen voor een geneste bibliotheek in plaats van een enkel bronbestand. Hierdoor konden we dingen zoals kleuren en pictogrammen in verschillende Sketch-bestanden splitsen en vervolgens naar symbolen over die bestanden verwijzen. Als u een update uitvoert voor een symbool in een van de bestanden, wordt deze nog steeds doorgevoerd in de andere bestanden die naar dat symbool verwijzen. (Geweldige functie, Sketch! )

We hebben bepaalde patronen / regels geschetst om "werkplekhygiëne" te handhaven

  1. Bestands- en mapstructuur
  2. Pagina's en Art-boards management (Art-board als variant van een scherm, Pages als functies)
  3. Herhaal jezelf niet (gebruik symbolen)
Bestands- en mapstructuurPagina's en tekengebiedbeheer

Niveau 0: Quarks en elektronen

Het toevoegen van een laag onder het Atomic-systeem lijkt misschien een vreemde zet, maar het maakte het bestand gemakkelijker te gebruiken. Het hielp ons ook een balans te vinden tussen vooraf gebouwde ontwerpelementen en herbruikbaarheid. Ik beschouw kleuren en pictogrammen niet als atomen, maar meer als attributen van elementen zoals elektronen en quarks. Kleuren kunnen overal worden gebruikt, als achtergronden, tekst, randen enz. Kleuren behandelen als elementbestandpictogrammen worden consistenter. Dit zijn symbolen, maar worden meestal gebruikt als overbruggingen in symbolen op atomair niveau.

Download voorbeeldbestand: https://goo.gl/9WdLYR
We hebben het formulesymbool gedefinieerd om variatie van een kleur te genereren en opnieuw gebruiken om een ​​palet te genereren. Zodat we ons gewoon zorgen moeten maken over basiskleuren. Formules zijn niets anders dan een overlay op een basiskleur en werken op dezelfde manier als Shades & Tint.

Niveau 1: Atomen

Atomen vertegenwoordigen enkelvoudige elementen van UI-ontwerp die unieke functionaliteit dragen. Bij het definiëren van atomen houden we ook rekening met hoe deze elementen zich gedragen in HTML.

Alles dat individueel kan worden gedefinieerd en gebruikt, zijn atomen. Bijvoorbeeld kaart, knopinfo, schaduw, scheidingslijn, knop, logo's, cursors etc.

Veel van deze elementen hebben verschillende toestanden en variaties waaruit de ontwerper kan kiezen. Al deze staten worden precies genoemd hoe het wordt gebruikt bij de ontwikkeling. Atomen worden waarschijnlijk ook gebruikt als overschrijvingen, tenzij u een aangepaste gebruikersinterface maakt.

Niveau 2: Moleculen

Dit is het gedeelte waar de meeste magie gebeurt! Moleculen helpen ons om ons herhaalde werk te verminderen en zorgen voor consistentie in het ontwerp. Elke molecule is gebouwd om uitwisselbare inhoud te bieden, b.v. knopstatussen veranderen, waardoor sommige elementen worden verwijderd / verborgen.

Het hele idee van moleculen is om generiek te denken.
Variaties van een generiek component

Moleculen bestaan ​​meestal uit meerdere elementen (tekst, afbeeldingen, symbolen) maar zijn toch ontworpen om abstract en herbruikbaar te zijn. Ze hebben een gemiddeld niveau van complexiteit, zoals tabbladen, statusbalk, actiebalk, lijstrijen, modals, waarschuwingsberichten enz.

Niveau 3: Organismen en pagina's

Op dit moment bevat dit niveau zeer weinig elementen zoals paginakopteksten, tabellen, Play / App Store-modellen, datumkiezers, toetsenborden enz. De reden hiervoor is dat ik het moeilijk vind om zin te zien in het leveren van vooraf gebouwde organismen, omdat dit niveauontwerp vaak afhangt van het project waaraan we werken en de functies en inhoud die moeten worden weergegeven.

Natuurlijk heeft elk project herhalende organismen in pagina's, maar ze zijn vaak afgeleid van individuele behoeften en vereisten. Dus het is beter om hier symbolen te gebruiken.

Pagina's of sjablonen zijn de werkelijke uitvoer van een ontwerpproces, dus hebben we besloten om dit niveau niet op te nemen in het Atomic-ontwerpsysteem.

Laatste woorden

Schetsbibliotheken zullen zeker de manier veranderen waarop we vandaag ontwerpen. Hier zijn enkele andere dingen die we hebben geleerd tijdens het bouwen van een atoomsysteem ..

  1. Volgorde van lagen in uw symboolkwestie. Omdat ze in dezelfde volgorde in het paneel Override verschijnen. U kunt ook enkele lagen vergrendelen om rommel te voorkomen.
  2. Gebruik Sketch runner om symbolen te zoeken en in te voegen, omdat dit een betere preview heeft dan wat Sketch momenteel heeft.
  3. Gebruik Sketch Styles Generator om gedeelde tekst en laagstijlen te genereren.
  4. Als u een niet-programmeerachtergrond hebt en wilt weten hoe ontwikkelaars ontwerpelementen zien, gebruikt u de plug-in Sketch Measure om uw ontwerpen te exporteren. Het helpt ook bij het vergemakkelijken van de overdracht van het ontwerp.
Ongetwijfeld is schets ons ontwerpproces aan het verbeteren, maar er ontbreken nog enkele belangrijke ontbrekende functies, zoals ...
  1. Gedeelde tekst- en laagstijlen kunnen niet buiten uw bestand worden gedeeld!
  2. Activa exporteren van symbolen met overschrijvingen is lastig! Bekijk deze thread voor meer info.
  3. Versiebeheer voor bibliotheken. (In tegenstelling tot het versiebeheer van de ontwikkelaar, staat Sketch toe om alleen naar de hogere / laatste versie van een component te gaan)
  4. Symbolen als een masker

changelog

Beschouw onderstaande opmerking als mijn open brief!

Ik zou hier willen vermelden / erop wijzen dat het bovenstaande artikel bedoeld is om onze bevindingen en het proces van het bereiken van het Atomic Design te presenteren. Het betekent niet dat ik mijn eigen creatie ben! Dit is een bescheiden poging om het concept 'Atomic Design' van Brad Frost te implementeren.

Hartelijk dank aan Alexandre Trimoulet, Brad Frost en Oliver Jahn voor hun inspiratie om aan de slag te gaan met Design System.

Bovenstaand artikel valt onder CC0 - geen rechten voorbehouden. Ik zie af van alle auteursrechten en aanverwante rechten voor zover toegestaan ​​door de wet.

Als u feedback / vragen hebt voor de implementatie van een ontwerpsysteem of andere dingen wilt bespreken, kunt u reageren.