Smart design betyder at designe med orden: Når tingene har samme navn for alle, fungerer teamet problemfrit, og leverancerne forløber uden problemer. I Figma betyder dette, at man anvender en klar nomenklatur for lag, komponenter, stilarter, variabler og tilstande, så alle kan forstå, hvad hver ting er med det samme. Etablering af ensartede navngivningsregler øger hastigheden, undgår forvirring og opretholder visuel konsistens. i ethvert projekt, fra et simpelt UI-kit til et modent designsystem.
Igennem denne guide vil du se, hvordan du opbygger en komplet taksonomi, der dækker alt fra elementtyper og deres egenskaber til navngivningsgrammatik, struktur og rækkefølge. Du lærer også, hvordan du bruger Figma AI til at omdøbe lag i bulk og implementere variabler som genanvendelige tokens til avanceret design og prototyping. Ideen er, at I ender med et fælles arbejdssprog, som I kan skalere problemfrit..
Det grundlæggende: hvorfor nomenklatur er vigtig i et designsystem
Før vi går i detaljer, er det værd at etablere rammerne: et designsystem i Figma samler komponenter, stilarter og regler, der artikulerer grænsefladen. Det er afgørende at definere navne ensartet på tværs af systemet for at opretholde konsistens og effektivitet.På den måde bliver dit bibliotek ikke et virvar af knapper, der er næsten identiske, men kaldes med tusind forskellige navne.
Inden for dette system er egenskaber og deres værdier nøglen: farve, typografi, afstand, størrelser, tilstande, tilstande… Jo mere konsekvent du er i navngivningen af hver egenskab og hver værdi, desto lettere vil det være at anvende og vedligeholde det overordnede udseende. i alle dele af produktet.
Praktisk organisering af komponenter og stilarter
Når du arbejder med komponenter, sparer du tid ved at bruge beskrivende og forudsigelige navne på at søge efter og forstå instanser. For knapper, for eksempel, skal du skelne mellem type og formål (primær, sekundær); og tilføj tilstanden (f.eks. normal eller svævende), hvor det er relevant.
Med ikoner er det bedst at undgå generiske ikoner som "Ikon 123". Vælg genkendelige navne som "mail", "indkøbskurv" eller "netværk" De bør forklare, hvad de handler om, uden at åbne laget. Den klarhed værdsættes, når man filtrerer i biblioteket og inspicerer fra udviklertilstand.
For interaktive komponenttilstande, navngiv dem, så de entydigt kan skelnes: for eksempel skal en hovedknap i hviletilstand og dens svæveversion tydeligt adskilles. Brug af et suffiks eller en tilstandsmodifikator gør tricket (f.eks. primary/primary-hover).
Hvis du administrerer mere end ét designsystem parallelt, skal du markere deres hierarki. At skelne mellem et "hoved"-sæt og et "sekundært"-sæt forhindrer at dele, der ikke hører sammen, blandes.især i organisationer med flere brands eller vertikaler.
Fordele ved at afstemme navne mellem design og udvikling
At hele teamet bruger det samme sprog reducerer friktion: Når en udvikler læser lagets navn, og det matcher tokenet eller klassen i koden, er implementeringen mere ligetil. Nomenklaturen er limen, der holder samarbejdet mellem discipliner sammen. og forkorter gennemgangscyklusserne.
Derudover er det ligetil at identificere og gruppere elementer, når det er tid til at revidere eller skalere systemet, hvis navngivningsreglerne er blevet anvendt konsekvent. Nominel konsistens resulterer i vedligeholdelse og omkostningsbesparelser over tid.
Trin til at opbygge din designsystemfil i Figma
At opbygge et solidt system er ikke et spørgsmål om tid, men der er en klar vej, du kan følge, så du ikke farer vild undervejs. Start med det væsentlige og dokumenter hver beslutning, så den er delbar.
- Opgørelse over nøgleelementerDefiner hvad du vil standardisere (palette, skrifttyper, afstandsskalaer, kritiske komponenter såsom knapper, input, kort…). Tydelig omfang forhindrer senere omarbejde.
- Fil dedikeret til systemet: opretter en specifik fil, der fungerer som en kilde til sandhed. Adskillelse af biblioteket fra projekter sikrer, at ændringer kontrolleres og versioneres bedre..
- Komponentiser med kriterierstrukturerer komponenterne og deres varianter efter den valgte konvention. Navnet skal afspejle type, formål og status, når det berører.
- Definer stilarterTekststile, farver og effekter med ensartede navne, så de er lette at finde. Den anvender den samme grammatik og ordsammenføringsmønstre..
- Dokumentér brugenTilføj noter om, hvornår hvert element skal bruges, begrænsninger og eksempler. En klar vejledning gør det nemmere for hele organisationen at designe "ved samme temperatur".
Taksonomi: komponenter, objekter, egenskaber og værdier
For at en ordliste kan fungere, skal du først vide, hvilke dele du taler om, og hvordan de hænger sammen. Denne taksonomi vil fungere som et kort for at sikre, at du ikke efterlader nogen løse ender..
Komponenter: base og forbindelser
I Figma-termer er en komponent en blok med sin egen visuelle identitet i UI-kittet (som et kort). En basiskomponent er et stykke designet til at blive indlejret inden i andre. (For eksempel den numeriske knap, der kun findes i en datovælger). Nogle biblioteker mærker dem som aktiver, snippets, dele, elementer eller underkomponenter: ideen er den samme.
Objekter: beholdere og elementer
Et objekt er en del af en komponent. Der er to hovedgrupper: beholdere (kasser, sektioner) og elementer (indhold)Blandt elementerne finder du tekst (etiket, titel, undertitel, billedtekst), andre komponenter (ikoner, illustrationer, knapper, tabeller), vektorer (cirkel, rektangel, polygon) og medier (billede, gif, video).
Egenskaber og værdier
Egenskaberne er de variable dele (størrelse, tilstand, farve, tæthed osv.). Hver ejendom tilbyder et sæt mulige værdierFor eksempel kan "state"-egenskaben for en knap være normal, pegemus, trykket ned, deaktiveret...
Der er to familier af værdier: varianter og booleske værdier. Én variant understøtter mere end to muligheder (xs/s/m/l eller info/warn/error), mens en boolsk værdi repræsenterer et typisk ja/nej (Sand/Falsk, Til/Fra, VisIcon/SkjulIcon).
Navngivningsstruktur: modifikatorer og deres placering
Når du er klar over, hvad du navngiver (komponent, objekt, egenskab eller værdi), skal du beslutte, hvordan du vil markere deres forskelle. Modifikatorer hjælper med at skelne mellem varianter, tilstande og kontekster.
Typer af modifikatorer
Der er flere måder at ændre et navn visuelt. Du kan bruge ikoner, symboler eller nøgleord. for at styrke din læsning:
- Ikon: for eksempel et symbol foran, der angiver funktionalitet eller status (kun hvis din computer understøtter og forstår det).
- Tegnsætningstegn: præfikser eller separatorer såsom ._Base eller underniveaumarkører.
- Ord, akronymer og forkortelser: suffikser såsom Item-List, Cell-Header, ShowIcon, BC_…
Det vigtige er, at konventionen er tydelig og dokumenteret. Hvis du kombinerer modifikatortyper, skal du definere prioriteter og brugsscenarier. for at undgå kaotisk blanding.
Modifikatorposition
Rækkefølgen skal være ensartet i hele systemet. Du kan placere modifikatoren før (Item-List) eller efter (List-Item)Det vigtigste er ikke at skifte mellem de to mønstre uden en klar strategi.
Substantivernes grammatik: type, tal, initialer og foreninger
Standardisering af grammatik gør navne læsbare og forudsigelige. Beslut én gang og anvend det altidEllers vil undtagelser, der er svære at huske, vokse.
Termtype
Vælg om navnet skal være et verbum, adjektiv eller substantiv, og i hvilken form det skal konjugeres. Gyldige muligheder: participium (skjulet), nutid (skjulet), tillægsord (skjulet), navneord (skjulet) eller kombinationer som “er sammenklappelig”, “vis sammenklappelig”, “ikon før”.
Ental eller flertal
Definer, om du navngiver i ental eller flertal, og behold mønsteret. Brug af Knap/Knapper eller Størrelse/Størrelser konsekvent gør søgning og læsning nemmereDu kan også indstille en generisk ("handlinger"), hvis det bedre grupperer flere elementer.
Initialer og visuel stil
Angiv, hvordan du bruger store bogstaver: Store bogstaver + store bogstaver (ikon før), små bogstaver + små bogstaver (ikon før), Store bogstaver + små bogstaver (ikon før) eller små bogstaver + store bogstaver (ikon før). Store bogstaver er en del af systemet, ikke en mindre detalje.
Ordparringer
Måden du kombinerer termer på, definerer læsbarhed og tilpasning til koden. Almindelige valgmuligheder: intet mellemrum (iconBefore), med mellemrum (icon before), punktum (icon.Before), bindestreg (icon-before), understregning (icon_before)Undgå kombinationer, der forringer læsningen, hvis de ikke tilfører værdi.
Foruddefinerede stilarter (Case Styles) er under udvikling, der kombinerer initialer og foreninger: camelCase (ingen mellemrum og alle ord skrevet med stort undtagen det første), PascalCase (alle ord skrevet med stort og ingen mellemrum), kebab-case (bindestreg og små bogstaver) og snake_case (understregning og små bogstaver)Vælg den, der passer bedst til din stak, og vær konsekvent.
Sådan sorterer du: alfabetisk, sekventielt og hierarkisk
Ud over navnet er måden, lange lister er ordnet på, også vigtig for at finde ting hurtigt. Tre tilgange fungerer godt på biblioteker:
- Alfabetisk: a–zoz–a (f.eks. bund, venstre, højre, top).
- Sekventiel: 0–10 eller 10–0 (f.eks. standard/hover/aktive størrelser eller tilstande).
- Hierarkisk: fra mest til mindst eller omvendt (f.eks. primære, sekundære eller info/advarsel/fejl-alvorlighedsniveauer).
At anvende de samme sorteringskriterier på alle samlinger forhindrer hvert hold i at sortere "på deres egen måde". Definer dine præferencer og dokumenteksempler for tvetydige tilfælde.
Implementering: revision og oprettelse af ordlisten
Når reglerne er fastlagt, er det tid til at føre dem ud i livet. Du har to veje, som du endda kan kombinere. for at sikre landing:
Indholdsrevision
Gennemgå, hvad der allerede er bygget: inventarkomponenter, objekter, egenskaber og værdier med deres nuværende navne. Målet er at nå til enighed om et enkelt taksonomisk system med design og udvikling. og planlæg migreringen uden at ødelægge prototyper eller overdragelser.
Oprettelse af ordliste
Uanset om du starter fra bunden eller allerede har udført revisionen, skal du definere strukturen, grammatikken og rækkefølgen for hver type element (komponent, objekt, egenskab og værdi). Ordlisten bliver din "officielle ordbog" over navne og i en ressource for nye medlemmer.
Figma AI til kontekstuel omdøbning af lag
Det er kedeligt at omdøbe hundredvis af lag manuelt. Her kan Figma AI spare dig tid ved at bruge indhold, position og lagrelationer til at foreslå kontekstuelle navne. Værktøjet analyserer dit valg og anvender ensartede navne, hvor det registrerer standardmønsteret..
Der er bevidste begrænsninger: Figma AI omdøber kun rammer, grupper, tekstlag, rektangler (og afrundede) med billedfyld og visse instanser, der stadig bevarer standardnavnet på hovedkomponenten (kun containeren uden at røre underlag). Hvis et lag allerede har et navn, er låst eller skjult, eller er en individuel vektorform (ellipse, polygon, stjerne, maske) uden et billede, vil det ikke blive omdøbt..
Du kan starte omdøbning på flere måder: fra kontekstmenuen med et højreklik, fra Handlinger i værktøjslinjen eller via hurtige handlinger ved at skrive "Omdøb lag". Hvis alt allerede er korrekt navngivet, vil du se meddelelsen "Ingen grund til at omdøbe lag" med muligheden for at "Omdøb alligevel", hvis du vil gennemtvinge det..
En nyttig detalje: Hvis du har identiske, unavngivne lag i flere topniveau-frames, vil Figma AI omdøbe de matchende. Dette hjælper med at bevare smarte animationer og scrollpositioner i prototyper ved at opretholde nominel korrespondance.
Variabler i Figma: genanvendelige tokens til design og prototyping
Variabler gemmer værdier, som du kan genbruge i designegenskaber og prototypehandlinger, og de sameksisterer med andre designværktøjer som f.eks. 3D-designprogrammer til Mac. De er den naturlige bro til implementering af designtokens og opbygning af interaktiv logik uden at duplikere frameworks..
Nogle praktiske anvendelser: opret og anvend tokens (farver, skrifttyper, mellemrum), skift mellem enhedsstørrelser med øjeblikkelige afstandsjusteringer i henhold til din skala, se forhåndsvisninger af tekster på forskellige sprog med en ændring af kontekst, eller byg en indkøbskurv, der beregner ordretotaler. Alt dette uden at multiplicere unødvendige variationer.
Der er tre hovedområder, hvor de udmærker sig: design og designsystemer, avanceret prototyping og API'er. At mestre disse tre giver dig mulighed for at forbinde design, interaktion og automatisering. i en konstant strøm.
Variabler for design og systemer
Brug variabler og tilstande til at repræsentere tokens og alternative kontekster (lys/mørke, brands, regioner). Farve og antal er grundlaget for paletter, størrelser og tætheder.og du kan knytte dem til samlinger og tilstande for at skifte med et hurtigt blik.
Typiske ressourcer på dette område omfatter introduktionsvejledninger, vejledninger til samlinger og tilstande samt sammenligninger mellem variabler og stilarter, der kan hjælpe dig med at beslutte, hvornår du skal bruge hver enkelt. Kort sagt: stilarter fungerer som visuelle forudindstillinger; variabler indkapsler parametriserbare værdier med tilstande.
Variabler til avanceret prototyping
I prototyper lagrer variabler tilstande og egenskaber, der ændrer sig gennem interaktion. Du kan bruge handlinger til at ændre deres værdier og dermed ændre udseende, indhold eller synlighed uden at duplikere rammer..
Kombination af variabler med udtryk og betingelser åbner døren for dynamiske strenge, matematiske operationer og boolske evalueringer. Med flere handlinger og if/else-logik stabler du komplekse adfærdsmønstre i den samme trigger..
Variable tilstande spiller også en rolle i prototyper: sæt værdier efter kontekst (f.eks. tema) og brug dem i udtryk til at skifte udseende i realtid. Antallet af skærme, der er nødvendige for omfattende scenarier, reduceres drastisk.
Variabler og API (REST, plugins og widgets)
Variablerne er tilgængelige i både plugin-API'en og REST API'en. Du kan se, oprette, opdatere og slette variabler samt linke dem til komponenter fra plugins.Dette muliggør værktøjer som importører/eksportører eller stil-til-variabel-konverterere.
Widgets tilgår variabler via plugins API'en (læsning og oprettelse), med den undtagelse at de ikke direkte kan linke widget-egenskaber til variabler. For at synkronisere med repository'et er der eksempler på GitHub-handlinger, der forbinder Figma-variabler til din kodebase., udover fællesskabs-sandbox-filer til risikofri øvelse.
Gode navngivningspraksisser for lag og komponenter
Angiv et præfiks for typen (f.eks. Btn, Kort, Input) og et suffiks for tilstanden (hover, fokus, deaktiveret) eller størrelsen (sm, md, lg). Den anbefalede rækkefølge er normalt Type/Formål/Størrelse/Tilstandog brug ensartede separatorer (kebab-case eller PascalCase, alt efter hvad der passer til din stak).
Oprethold konsistens mellem lag og instanser: instanscontaineren skal arve mønsteret fra masterkomponenten. Undgå improviserede lokale variationer, da de forstyrrer søgning og erstatning.Når det er tid til at ændre, så gør det i masterversionen og publicer en ny version.
For boolske egenskaber skal du navngive egenskaben, ikke værdien: "Ikon" med Til/Fra- eller Sand/Falsk-værdier; undgå "medIkon/udenIkon", hvis dit system bruger boolske til/fra-knapper. Dette justerer sproget med prototypens og kodens logik..
Hvis dit projekt omfatter mere end ét domæne (f.eks. backoffice og kunde), skal du tilføje et omfang til samlingen eller mappenavnet. Adskillelse efter kontekst reducerer semantiske kollisioner og fremmer passende genbrug.
Almindelige fejl og hvordan man undgår dem
En af de mest almindelige fejl er ikke at dokumentere konventionen og lade hver person navngive tingene "på sin egen måde". Uden vejledning bliver biblioteket fragmenteret, og teamets hastighed falderGiv klare eksempler og grænsetilfælde for at fjerne tvivl.
Endnu en fejl: at blande sammenføjnings- og store bogstaver inden for den samme komponentfamilie (kebab i nogle, camel i andre). Dette komplicerer filtre, forespørgsler og læsning af lagpanelet.Definer en standardstil og anvend begrænsede og begrundede undtagelser.
Undgå betydningsløse navne (“Frame 27 Copy 3”, “Rectangle 12”). Hvis Figma AI ikke kan hjælpe, fordi navnene allerede er tildelt, skal du omdøbe dem manuelt eller på komponentniveau. og benytte lejligheden til at konsolidere den valgte konvention.
Duplikér ikke varianter, der allerede er løst af en variabel eller en boolsk værdi i komponenten. Den gyldne regel: færre skærme, mere parametriseringDu ender med et lettere og mere overskueligt bibliotek.
Adoptionsplan for teams
Start i det små med et sæt af komponenter med stor effekt (knapper, input, typografi, palet). Del konventionen, indsaml feedback og forbedr den, før du udruller den til andre.Derfra migreres efter moduler og version.
Hvis du ønsker at accelerere din mestring af disse praksisser, kan du overveje intensiv, produktorienteret træning. Programmer undervist af aktive fagfolk hjælper med at omsætte teori til praksis i virkelige tilfælde. integrerer allerede Figma med udviklingsprocesser.
Nøglen til alt ovenstående er at behandle nomenklaturen som en del af designet, ikke som en eftertanke. Med en klar ordliste, grammatik- og strukturregler, Figma AI-understøttelse og veldefinerede variabler opnår dit system hastighed, konsistens og skalerbarhed.Og dit team, kvalitetstid til at fokusere på brugerproblemer og ikke på at skændes om navne.
