Figmagic file organization
Working effectively with Figmagic means understanding how and what it actually parses from a document.
In this lesson, we will demystify exactly how a Figmagic-compliant Figma file needs to look for it to work.
Required page names#
On a high level, there are three page names that Figmagic looks for:
Obviously, these correspond to what type of thing Figmagic should process them as.
You can certainly have any number of pages with other names than those within the same document. However, Figmagic itself will only process pages with the names I just listed.
No, you do not need all of those pages. Use the ones you need!
In upcoming lessons, we will delve into details on graphics and components, or "elements" as they are called in Figmagic nomenclature, so we will brush over those here.
Let's recap how we correctly outline our design tokens.
I'll rename the current page to Design tokens. Next, I'll create a frame, and into it, I will create a rectangle. I will rename the frame Colors because we will use this frame to contain our colors.
Make the rectangle a solid color, and then rename the rectangle into the name of my color.
These steps should be familiar from the last lesson. What we have done is create the basic structure required for Figmagic to create design tokens from our color swatches.
Colors are a typical first use-case and are easily demonstrable, but there are many more types of tokens we can use. At the time of making this course, they are:
And for animations, there are Durations, Delays, and Easing functions
The basic idea is the same for all of these, and they follow the pattern we have used a couple of times now for the colors:
Create a frame
Give the frame a name that matches its token type
Add something (typically a rectangle)
Adjust its value
Rename that something into its real name.
I am going to open up the Figmagic Design System template so that we can look at some other examples.
Uni-dimensional token values#
The approach used in Figmagic is to express values as "uni-dimensional," which in common parlance just means that every item (or design token) expresses only a single detail. The effect of this is that we get a very granular design system, but collecting tokens or details together—for example, assembling a more complex design—is something that we have to do in code from the individual tokens.
The opposite approach could be something like a text string that has advanced formatting, with a custom font, some particular size, some font variant, some color, some special kerning setting... and then we would need to either use all of those details together, or we somehow still need to disassemble each detail from this set of details.