Foreslå nytt design eller forbedringer
Vi setter pris på at du hjelper oss å forbedre komponenter og design i Figma. De beste løsningene kommer gjennom samarbeid.
Ny komponent
Ønsker du å foreslå en ny komponent setter vi pris på om den blir registrert i Github.
Når en ny komponent blir foreslått må vi vurdere om den er verdifull nok til å være en del av designsystemet. Vi ønsker ikke å ende opp med hundrevis av komponenter med små forskjeller, da vi kan risikere uønsket kompleksitet, vedlikehold, samt design- og teknologigjeld.
For nye komponenter som tas inn må vi:
- Identifisere og utforske liknende behov hos andre produktteam og offentlige aktører. Hvor mange produkter/etater vil ha bruk for den?
- Vurdere problemet komponenten skal løse og verdien dette gir.
- Tenke på om den kan lages fleksibel og gjenbrukbar nok.
- Tenke på om den er i tråd med designprinsippene og om den passer inn i helheten
Registrere feil eller mangler på en komponent i Figma
Har du funnet en svakhet med noen av de eksisterende komponentene i Figma, setter vi pris på om du enten legger igjen en kommentar i Figma sammen med den aktuelle komponenten, eller at du oppretter en bug-report i Github som forklarer feilen, eventuelt en feature-request som forklarer ønsket tilleggsfunksjonalitet.
Lage en komponent i Figma
Komponenter under arbeid ligger i egne arbeidsfiler. Når designet er ferdig flyttes komponenten til Designsystemet - Core UI Kit. Denne filen blir delt i Figma Community.
Det er et par ting å tenke på når komponenter lages i Figma:
-
Snakk med en utvikler om spesifikasjon, krav, tilgjengelighet, egenskaper og varianter. Bli enige om scope for komponenten og dokumenter dette i komponentens Github-sak.
-
Alle styles (farger, avstander, størrelser, skygger, osv) skal være koblet opp mot korrekt tokens. Bruker du stilene som finnes, er disse allerede automatisk koblet mot tokens. Trenger du nye stiler, må disse også lages som tokens.
-
Bruk typografi-komponentene for all tekst som skal eksistere i komponenten.
-
Autolayout: Innholdet skal skalere som forventet ved størrelseendring. Tenk over om innholdet skal wrappe under hverandre dersom det ikke er plass i bredden. Kan det være hensiktsmessig med en min- eller max-width? Og kanskje truncate (...) på teksten dersom den blir for lang?
-
Varianter og "component properties": Bruk varianter for ulike varianter, farger, states, størrelser, og liknende. Bruk Component properties for å vise/skjule lag, instance-swap (F.eks bytte et ikon) og bytte text. Properties navngis på samme måte som props i Storybook. Vi bruker
Variant,Size,Color,State. -
Hvilke størrelser skal komponenten eksistere i? Tenk over at komponenten passer med størrelsene på de andre komponentene. For eksempel bør et medium text-field være like høyt som en medium button, da de skal kunne plasseres på siden av hverandre. En medium komponent bør bruke typografi-size medium, og en small komponent bør bruke typografi-size small.
-
Er komponenten interaktiv? I så fall må ulike states eksistere som varianter av komponenten, og disse kobles opp med "Change to".
-
Multibranding. Tenk over i hvilken grad komponenten skal støtte ulik theming og legg til rette for dette ved å bruke brand-farger fra tokens.
-
Navgivning og organisering: Pass på at lagene i komponenten har fornuftige navn og at det ikke finnes unødvendige grupperinger eller lag.
-
Tenk over hvordan en annen designer vil ta i bruk komponenten. Er den intuitiv å bruke? Er den fleksibel nok slik at de ikke trenger å detache den? Kanskje bør den settes opp med slots slik at det er mulig å bytte ut innholdet i den og legge inn andre komponenter uten å måtte detache. Bruk gjerne også "Preferred values" for å femheve komponentene vi tror kommer til å bli mest brukt som innhold.
- Sjekk at du har gode nok kontraster
- At du har tenkt over hvordan tastaturnavigering skal fungere dersom du lager en ny komponent som ikke er standard. (Standard HTML-elementer har tastaturnavigasjon allerede definert).
- Instruksjoner eller informasjon som er essensiell for brukeren skal ikke være kun markert visuelt. Eksempel kan være å bruke ikon eller tekst i tillegg til rødfarge som indikerer at noe feiler.
- Focus: Alle elementer skal ha en visuell markør som blir synlig når elementet får tastaturfokus. Fokusmarkøren skal ha god nok konrast til bakgrunn, for å oppnå dette bruker vi en sort border (2px) og en gul outline (3px) i tillegg.
-
Når komponenten er klar markeres den som "Ready for review". Den blir testet av andre og etter eventuelle justeringer markeres den som "Ready for development". Når den er utviklet som en React-komponent lenker vi til komponentsiden i Storybook.
Oppdatere tokens
For å kunne endre eller opprette nye tokens må du lage en ny branch i pluginen Tokens Studio for Figma. Du trenger Pro-versjonen av pluginen for å gjøre dette.