A few months ago, I wrote about the dangers of shallow knowledge among UX designers. To really know how the UX should function, you need to know the subject matter at a deep level. I also opined that designers should learn development, at least as a process, if not the actual practice.
This post kinda ties those two together, in an odd way, leaning on my experience as a carpenter and a developer.
When I worked construction, I learned the importance of jigs. A jig is a custom tool, usually constructed by the carpenter who uses it, to do the same function over and over again. For example, a couple boards with a hinge and a long bolt and nut makes cutting a 23º angle on a table saw remarkably easy. The boards/hinge/bolt thing is a jig.
I also learned the different requirements for a jig and a template. A jig is when you are going to make maybe a dozen of something and a template is when you are going to make a thousand. I knew one carpenter who was tasked with putting cabinets into several hundred condos. He made a template and spent days just cutting stiles and panels to that template before he started assembling any cabinets.
Figma, interestingly, has now given designers tools to make jigs with their variables option.
Here’s a list of the current (March 2024) variables in Figma:
| Color | Solid fills | Fill colors Stroke colors Shadow effects |
| Number | Number values | Text layers Corner radius and individual corner radius Minimum and maximum width/height Padding and gap between Shadow and blur effects: X, Y, blur and spread values Layout grids Grid sizeRow and column count, width, height, margin, offset, and gutter Stroke weight: all, top, bottom, left, and rightLayer opacity |
| String | Text strings and variant names | Text layers Variant instances Layer visibility, if the string has a value of “true” or “false” |
| Boolean | True/false values | Layer visibility Variant instances with true/false values |
This ability to assign variables is different from the Styles aptitude. Variables can be used to define other variables or styles, but styles are one use objects and can’t be used as the foundation for other styles (yet. Old hands with Quark XPress remember well the variants of styles in that software).
These variables can be used to build styles which, in turn, are completely up to the designer to adjust, either in the style instance or at the base variable level. This makes for a very interesting capability to make a template template, wherein the basic template for a style is abstracted and saved separately.
But there’s more. Tokenization. Here, my experience with programming comes in handy, as I understand tokenization.
Tokenization is an idea borrowed from programming and security. The idea is fairly simple – use a token as a pointer to separate variable. Why? For inheritance and hierarchy. I can define a style to use a particular color on text, and define another style to use the same color on a border, but if I want to change the color, I need to change both styles. However, if the style or variable uses a token to point to a variable, I can change everything by changing the original variable to which everything is pointing.
Even more interesting – you can add a bit of meaning into your tokens by giving the colors/variables semantic labels:
In the above example, I’ve defined “Primary Brand” as the pointer to the color “Purple” and wherever I use the token “Primary Brand” it will take the color I’ve pointed to. If I want to change the brand color selection, I can either point to another variable (preferred) or change the variable it points to.
I’ve also defined “Warning” and “Emergency” colors, so throughout the design, if I am putting in an alert, I don’t need to think what colors these should be, I just assign “Emergency” and move on. These variables can then be communicated to the developers to define in their code.
Similarly, with the String variable, I can build a basic lexicon of actionable words and important reused phrases.
This will eliminate the inevitable questions and or drift that happens in every design studio – “Are we using ‘Submit’ or ‘OK’ or ‘Go’ or what?” or “Are we logging in or signing in?” I find it a good QA question to ask each member of a team if the project uses ‘Login’, ‘Log in’, ‘Sign in’, ‘Sign on’ or ? If the team has been properly briefed, each and every member of the team should be able to answer with confidence, however, once this becomes commonplace, they can remain ignorant and just point to the token for “Lexicon-Sign In”.
I’m sure, if you are a seasoned UX designer, or you noticed the headline, you know where this is going:
I can make a Figma Jig!
I can make über Figma files with all the generic elements (text, colors, buttons, page layouts, buttons, forms, images with captions and alts, videos) for websites, mobile devices, kiosks, and even watches built on tokenized variables and then edit/apply as necessary to create new websites/software.
I have my Figma Jigs in progress (one for websites and one for iOS/Android), and am curious if other designers have one to share. How complete is it? Any elements you were able to abstract? Please let me know in the comments.
UX UNbound 