Hva er design tokens og hvordan bruker man det?

Design tokens har blitt det nye trend-ordet innen UI design. For noen utviklere er ikke uttrykket nytt, og måten en jobber med design tokens på har vært praktisert en liten stund. I takt med at gapet mellom design og utvikling blir mindre, så kommer også metoder som design tokens tettere på designere.

Hva er design tokens? Design tokens er et konsept innen designsystemer som brukes til å standardisere og håndtere designelementer som farger, typografi, avstander, størrelser og andre stilattributter. En design token er en representasjon for et designvalg. Denne representasjonen kan være fargevalg, radier, skrifttype osv. Man kan se på en design tokens som et kallenavn eller en representasjon av en bestemt verdi. I stedet for å hardkode verdier, som HEX-verdier direkte i designet eller koden, brukes design tokens til å definere dem som separate variabler eller egenskaper. Tokens er skalerbart og skaper helhet på tvert av enheter, som f.eks. nettsider og mobilapper, og de hjelper oss med å skape et felles språk og vokabular på tvers av fagdisipliner.

Metoden for hvordan man lager design tokens er skapt slik at verdiene skal være plattform-agnostiske. At en verdi er plattform-agnostisk betyr at den skal være tilgjengelig uavhengig av hva slags verktøy eller teknologi en velger å bruke, altså at det er skrevet på en måte som gjør at det er tilgjengelige på tvers av plattformer, verktøy, teknologier og fagdisipliner. Ved at det er plattform-agnostisk, så får design og utvikling et felles språk å forholde seg til når man snakker om tokens-verdier som farger og lignende. Designvalg kan da for eksempel lagres som en .json-fil. .json er et åpent standard filformat, som da enkelt kan i flere kodespråk.

Oppbygning og typer design tokens

Som nevnt, så er design tokens et uttrykk for et designvalg i form av en verdi. En design tokens har et navn og gjerne også beskrivelse forbundet til seg, i tillegg til verdien.

Et eksempel på en design token



Navnet på tokenen er radius.button. Navnet følger gjerne en konvensjon for navneoppbygging, slik at navnet forklarer hvor eller hvordan den skal brukes, uten at en trenger å vite verdien den representerer.

Verdien til tokenen kan for eksempel være “12”, som i dette eksempelet vil være antall pixler radien på knappen skal ha. Verdien kan også referere til en annen token, men mer om det senere.

I tillegg til dette, så er det gunstig å ha en beskrivelse og en kategori. Beskrivelsen er supplerende informasjon som i tillegg til navnet tydeliggjør hvor eller hvordan tokenen skal brukes. Kategorien gjør det enklere å holde oversikt over de forskjellige type tokens en har.

En fullstendig token kan da se sånn ut i kode:

Kjernetokens

Kjernetokens, primitive tokens eller global tokens som det kan kalles forteller oss hva slags egenskaper og verdier som finnes. Disse typer tokens har ofte rå verdier, som HEX-kode, prosent, tallverdier, osv. Kjernetokens brukes aldri direkte i et design eller i en komponent, men refereres til av andre tokens.

Aliastokens

Aliastokens fungerer som et bindeledd mellom kjernetokens og semantiske tokens de stedene det er behov for å skille tokens med et ekstra lag. Aliastokens referer til kjernetokens, og blir selv referert til av semantiske tokens. De hjelper med å relatere tokens til en kontekst, og en kan ha flere nivåer av aliastokens ved behov. I eksempelet under hjelper også aliastokenen med å vite hvor stor eller liten radiusen er i forhold til en annen, siden den har fått navnet “Radius.medium”. Hvis man da har en “Radius.small” og en “Radius.large”, så vet du at det er den midterste radiusverdien.

Semantiske tokens

Semantiske tokens er de tokensene som brukes direkte på komponenter. De referer alltid til en aliastoken eller en kjernetoken, og har ikke en hardkodet verdi tilknyttet seg. Navnet til en semantisk token forteller om hvor og hvordan den skal bli brukt. For eksempel “Radius.button”

Kompositt-tokens

Kompositt-tokens brukes i prinsippet likt som semantiske tokens, men skiller seg likevel ut på flere måter. Vanlige semantiske tokens referer bare til en annen token, mens kompositt-tokens er består av flere tokens som refererer til forskjellige verdier eller tokens. Detter er litt komplisert, men et bruksområde er der en enkelt token-verdi i seg selv ikke gir et komplett resultat. Et bruksområde for kompositt-tokens er i styling av tekst. For å sette opp en tittel-tekst, så har du skrifttype, vekt, størrelse, kerning, osv. For å slippe å legge på hver av disse tokensene enkeltvis for at tittelen skal bli riktig, så kan en heller lage en kompositt-token som består av flere tokens-verdier, som sammen styler teksten slik du ønsker og gir et komplett resultat.

Hvor starter jeg?

På samme måte som at komponenter skaper helhet, så sørger design tokens for det samme, men på et mer grunnleggende nivå. En slipper usikkerhet om hvilken av de X blåfargene som var den rette for å bygge opp en gitt komponent, siden fargetokensene er satt opp på en måte som gjør at du vet hvilken du skal velge.

Design tokens kan virke overveldende å begi seg ut på, men en må ikke implementere alt på en gang. Begynn med det som dekker det største behovet. Hvis for eksempel komponentbiblioteket til designsystemet har sklidd litt ut, og dere trenger en bedre måte å standardisere verdiene til komponentene på, så kan tokens være en fin måte å starte på det arbeidet.

Underveis som tokens blir implementert, så blir det lettere å gjenbruke tokens på tvers, og hastigheten øker. Dersom det skulle oppstå endringer på sikt, så vil også tiden det tar å gjennomføre endringen bli kortere. Da endrer du bare på den aktuelle token-verdien. Begynn gradvis og bygg etter behov. Alt behøver ikke å bli implementert på en gang.

Design tokens - Kreativ kontroll

What are design tokens and how can you use them?

Design tokens have become the latest buzzword in UI design. For some developers, the term is not new, and the way of working with design tokens has been practiced for a while. As the gap between design and development narrows, methods like design tokens are also getting closer to designers.

What are design tokens? Design tokens are a concept within design systems used to standardize and manage design elements such as colors, typography, spacing, sizes, and other style attributes. A design token is a representation of a design choice. This representation can be a color choice, radii, font, and so on. One can think of a design token as a nickname or representation of a specific value. Instead of hardcoding values, such as HEX values directly into the design or code, design tokens are used to define them as separate variables or properties. Tokens are scalable and create consistency across devices, such as websites and mobile apps, helping us establish a common language and vocabulary across disciplines.

The method of creating design tokens is designed so that the values are platform-agnostic. Being platform-agnostic means that they should be accessible regardless of the tools or technology one chooses to use, written in a way that makes them available across platforms, tools, technologies, and disciplines. By being platform-agnostic, design and development have a common language when discussing token values like colors and similar choices. Design choices can, for example, be stored as a .json file. .json is an open standard file format that can be easily read in multiple programming languages.

Structure and types of design tokens

As mentioned, design tokens are an expression of a design choice in the form of a value. A design token has a name and often a description associated with it, in addition to the value.

An example of a design token

The name of the token is "radius.button". The name typically follows a naming convention, explaining where or how it should be used without needing to know the represented value.

The value of the token can, for example, be "12," which in this example would be the number of pixels for the button's radius. The value can also refer to another token, but more on that later.

In addition to this, it is beneficial to have a description and a category. The description provides additional information that, along with the name, clarifies where or how the token should be used. The category makes it easier to keep track of the different types of tokens.

A complete token in code might look like this:

Core tokens

Core tokens, primitive tokens, or global tokens, as they may be called, inform us about the properties and values available. These types of tokens often have raw values, such as HEX codes, percentages, numerical values, etc. Core tokens are never used directly in a design or component but are referenced by other tokens.




Alias tokens

Alias tokens act as a link between core tokens and semantic tokens where there is a need to distinguish tokens with an additional layer. Alias tokens refer to core tokens and are themselves referred to by semantic tokens. They help relate tokens to a context, and multiple levels of alias tokens can be established as needed. In the example below, the alias token also helps understand how large or small the radius is compared to another, as it is named "Radius.medium." If you have "Radius.small" and "Radius.large," you know it represents the middle radius value.

Semantic tokens

Semantic tokens are the tokens used directly on components. They always refer to an alias token or a core token and do not have a hardcoded value associated with them. The name of a semantic token indicates how and where it should be used. For example, "Radius.button."

Composite tokens

Composite tokens are used in principle like semantic tokens but differ in several ways. Regular semantic tokens only refer to another token, while composite tokens consist of multiple tokens referring to different values or tokens. This might sound complicated, but one use case is where a single token value itself does not provide a complete result. A common use case for composite tokens is in styling text. To set up a title text, you have a font, weight, size, kerning, etc. Instead of adding each of these tokens individually to get the title right, you can create a composite token that includes multiple token values, styling the text as desired and providing a complete result.

Where do I start?

Just as components create coherence, design tokens ensure the same but at a more fundamental level. You eliminate uncertainty about which of the X blue colors was the right one to build a specific component because the color tokens are set up in a way that guides your choice.

Implementing design tokens may seem overwhelming, but you don't have to do it all at once. Start with what covers the most significant need. For example, if the component library of the design system has become a bit chaotic, and you need a better way to standardize the values of the components, tokens can be a good way to start that work.

As tokens are implemented, it becomes easier to reuse them across the board, increasing efficiency. If changes arise over time, the time it takes to implement the change also decreases. You only need to modify the relevant token value. Start gradually and build as needed. Not everything has to be implemented all at once.

Design tokens - Creative control

Herregud så lei jeg er av cookiebannere! De er i veien, de er irriterende og de ødelegger brukeropplevelsen og flyten på nettsiden. Ja - også er de aller fleste ulovlige også!

Det er en veldig enkel grunn til at cookiebannere finnes: ePrivacy-forordningen til EU krever samtykke før en nettside får lov til å skrive en fil til datamaskinen din.

Det skal være valgfritt for meg om nettsiden din skriver en cookie til maskinen min som f.eks. gjør det mulig for Facebook å spore hvilke nettsider jeg har vært inne på. Det tror jeg alle er enige om at burde være opp til meg, og ikke opp til de som driver nettsider.

Dessverre har mange som driver nettsider innsett at de er veldig avhengig av data som de fleste ikke egentlig ønsker å gi fra seg. Og det har ført til den situasjonen vi er i idag.

De fleste cookiebannere ser omtrent slik ut:

Og det er her vi støter på problemer. Cookiebannere baserer seg på samtykke. Etter både ePrivacy-forordningen og GDPR er samtykke veldig klart definert:

“en tydelig bekreftelse der den registrerte på en frivillig, spesifikk, informert og utvetydig måte gir sitt samtykke til behandling av vedkommendes personopplysninger”

Banneret over oppfyller ikke dette. For det første er det vanskelig å hevde at brukeren har vært informert. Hva betyr egentlig at informasjonen skal brukes til å gjøre brukeropplevelsen bedre? Og hvordan blir denne informasjonen brukt til markedsføring? Hvem deles det med? Hva er konsekvensene av dette?

Det brukes også et veldig vanlig “dark pattern” her: Handlingen nettsiden ønsker at vi skal ta er en knapp, den er grønn og plassert til høyre der vi forventer knappen for å gå videre. Det er ingen tydelig knapp for å si nei, i stedet må vi følge en lenke som mest sannsynlig tar oss til en side hvor det fortsatt er vanskelig å finne en knapp som sier “nei”.

Dette oppfyller ikke kravet til at et samtykke skal være gitt frivillig. Når det er så vanskelig å kommunisere at man ikke ønsker å samtykke er det lett å hevde at samtykket ikke egentlig var frivillig, og dermed er ugyldig.

Så hvorfor er det sånn? Det kan være flere grunner: Det å sette cookies som tillater målrettet markedsføring er veldig lukrativt for de fleste bedrifter. Derfor gambler mange på at de ikke kommer til å bli tatt, og at dersom de blir tatt så vil bøtene ikke overstige det de har tjent.

I tillegg er det i Norge for tiden en spesiell situasjon der ePrivacy-forordningen ikke er innført i norsk rett enda. Denne kommer som en del av den nye eKom-loven, men denne har ligget hos Regjeringen i lang tid uten å bli sendt til Stortinget. Først når denne er vedtatt vil det i norsk rett være helt klart definert at disse kravene gjelder. Inntil det er det mange som lener seg på at den gamle eKom-loven sier at det holder at nettleseren aksepterer tredjepartscookies for at dette skal være tillat.

Tiden for den særnorske situasjonen er uansett på vei mot en slutt, og i EU jobber blant annet organisasjonen til Max Schrems - none of your business - hardt for å få datatilsynene til å slå ned på ulovlige cookiebannere. Med litt flaks får vi i 2024 en skikkelig mulighet til å si “nei takk” til cookies.

16-Dec

Today's posts

Design tokens - Kreativ kontroll

Design tokens - Creative control

Cookiebanneret ditt er ulovlig