DEV Community: Yurick Hoang

Managing variables in a design system: a three-layer structure for products with dark mode

Yurick Hoang — Sun, 25 Oct 2026 07:48:36 +0000

I once opened a design system file and found the same gray typed in by hand in more than a dozen places, each a few hex codes off. Rebranding meant fixing every layer one by one. Figma variables exist to end that, but only if you organize them on purpose. This post is how I build and manage variables for a mobile product design system with dark mode, along with the conventions I think are worth keeping.

Three layers, one direction of reference.

Start with the file structure, not the colors

Before creating any variable, I organize the file. The foundation pages come first: Color, Typography, Spacing, Corner Radius, Shadows, Backdrop Blur, plus Anatomy and Design annotations. Core Components follow, grouped with divider pages so the Pages panel is easy to scan.

This order is not just for looks. Components depend on foundations, so putting foundations first reminds the whole team that when a component needs changing, you look up first to see whether the tokens are enough.

Foundations first, components after.

Layer 1: Primitives, raw colors with no meaning

The first collection holds raw values only. Each hue has a scale from 100 to 900, with 500 as the base color. Grey alone adds 0, 850 and 950 because dark mode needs more dark steps. This collection has a single mode and one rule: designers never bind primitives directly to components.

A name like color/Primary/500 tells you what the color is, but not where to use it. The question of "where to use it" belongs to the next layer.

Primitives: 93 color variables, one mode.

Layer 2: Semantic tokens, named by role

This is the most important layer. Each token describes a role: bg-surface, text-secondary, icon-disabled, stroke-brand-primary. This collection has two modes, Light and Dark, and each mode points to a different primitive.

A few things I found useful when building dark mode:

The more a stacked background rises, the lighter it gets. Canvas uses Grey/950, container uses Grey/900, surface uses Grey/850 and secondary surface uses Grey/800.
Light subtle backgrounds do not need a new color. In dark mode I reuse the base color at roughly 15 to 20 percent opacity.
Status colors go one step darker: for example, Error uses Red/500 in Light and Red/600 in Dark so it does not glare on a dark background.

That way a button only needs to bind to Colors/Main/Primary/solid. Switch the layer from Light to Dark and everything changes automatically.

One token, two modes. The table below shows how tokens point back to primitives.

One job per collection

I split variables into several collections instead of putting everything into one. Each collection holds exactly one type of value: raw colors, theme colors, typography, spacing, stroke, radius, icon size, date and time formats, data formats and title styles. This has three benefits: it is easy to find things, easy to control who can edit, and easy to publish in parts.

Three small conventions keep the Variables panel tidy:

Prefix names with 01 to 10 so Figma sorts them in the right order.
A collection that starts with an underscore is an internal set, not meant for library users to pick.
Name by role (text-secondary), not by color (grey-600). When the color changes, the name stays correct.

11 collections, one job each.

Number scales are variables too

Not just colors. Spacing, corner radius, stroke weight and icon size are all Number variables. Spacing has 18 steps from 0 to 256, radius has 8 steps up to 999 for circles, stroke has 3 steps, and icon size has 13 steps from 10 to 128.

The biggest benefit is discipline: designers pick from an existing scale instead of typing odd numbers like 13 or 22. To change the feel of the whole product, for example softer corners, you change a few radius variables instead of editing every layer.

Spacing, radius, stroke, icon size.

Typography: size and line-height as pairs

The typography collection has 36 variables: two font family variables (heading and body), four font weight variables, and a font size and line-height pair for each text role. Figma text styles simply bind to these variables. When you need to adjust the type scale, you edit in one place and every text style updates.

Type scale: one size and line-height pair per role.

Use modes to switch a whole type set

My favorite is the "Title Type" collection. It has four modes (32, 24, 20, 16), each pointing to a matching title size, line-height, letter-spacing and subtext size. One title component, and switching mode switches the whole set. No need for four variants, and no need to remember to adjust letter-spacing by hand.

One component, four modes.

String variables for display data

Variables come in four types: Color, Number, String and Boolean. I use String too. One collection stores sample strings for data formats such as phone numbers or emails, with three modes: fully shown and two masking styles. Another collection stores date and time formats in two locales. Every mock-up pulls its sample data from here, so the design and the real product follow the same convention and you never see a different date format on every screen.

Values shown are illustrative.

Use styles for shadows and blur

Variables cannot store effects yet, so shadows and blur stay in Effect styles. I name them on the same xs, sm, md, lg, xl scale so they are as easy to remember as the other scales. Shadows in this system are very light, with opacity only from 3 to 9 percent.

Effect styles: shadows and backdrop blur.

A checklist for managing variables

Once it is built, the hard part is keeping it from breaking over time. I use this list:

Never bind primitives to components. Always go through a semantic token.
Set a scope for every variable. Background variables should only appear when picking a fill, spacing variables only for gap and padding. The picker list gets noticeably shorter.
Rename instead of deleting. Figma binds variables by ID, so renaming does not break links, while deleting a variable in use does.
Check both modes whenever you add a token. A new token missing its Dark value is the easiest bug to miss.
Scan for hand-applied colors. Select a whole frame, open Selection colors, and replace any color not bound to a variable with a token.
Document changes. Each time you publish the library, write a few lines of notes so the team knows what just changed.
Keep the reference chain short. Primitive, semantic, then stop. The more intermediate layers, the harder it is to trace back.

Conclusion

Variables do not make a design system good on their own. What makes the difference is convention: what each layer holds, how things are named and who can edit them. If you are just starting, do three things first: separate primitives from semantic tokens, name by role, and build Light and Dark from day one. The rest can be added gradually.

If you are building a design system and want to chat, you can reach me at yurickart.com.

Originally published at yurickart.com.

Is AI making designers lazy thinkers?

Yurick Hoang — Sun, 25 Oct 2026 07:12:51 +0000

I think AI is doing something good for design: it makes the field more accessible than ever. Someone who has never opened Figma can still build an interface. A PM with no design background can make a prototype to get an idea across. A developer can get fairly polished screens from a few lines of prompt.

I don’t see anything wrong with that. Technology is helping more people turn ideas into something they can see, click and test. But it also left me with a question: when making an interface becomes this easy, are we starting to take the thinking behind it too lightly? This post is what I think about that question, with two studies for extra perspective.

When the answer arrives before the question

Before AI, getting a design request meant understanding the problem, looking at similar products, analyzing information and trying several options. Some tasks that looked simple took a long time. Should people log in with email or phone first? Should we ask them to create a password right after the OTP step? If we add one more step to the sign-up flow, is it still a reasonable length? One icon family for everything, or split by role?

Sometimes I tried one direction, dropped it and started over. That process wasn’t always fun, but looking back, I learned a lot from the times I had to find the answer myself.

Now AI can propose a solution almost instantly. Describe a sign-up screen and it returns a full layout with a form, buttons and the familiar error states. It can look good, make visual sense, and sometimes beat the first option I would have come up with. What bothers me isn’t the visual quality. It’s that when an answer arrives this fast, it is very easy to skip asking my own questions.

Instead of asking what users need, I start asking AI how to design it. Instead of thinking about how to solve the problem, I tweak a solution that already exists.

A design that looks reasonable doesn’t mean I understood the problem.

The worry is not being able to explain my own decisions

I have received very short requests from PMs, sometimes just a reference image and one line: “See which one is usable.” That is a perfectly normal situation in product design. The PM may already picture what they want to see, but not necessarily how to organize the information or the interaction. A designer’s job is not to recreate the reference, but to understand which parts of it actually fit the product.

Another example is choosing icons for the first version of an app. The team had several icon families: 3D Clay, 3D Glossy, 2D and line. AI can build all four on the same screen in minutes, and all four look fine. For the first version, the team temporarily picked two: 3D Glossy for things you can tap, minimal line icons for information.

The icon families and the rule for the first version of the app. The mockup, colors and content have been changed to protect the project’s confidentiality.

The rule sounds simple, but behind it are questions I have to be able to answer: why split by role instead of by screen, do people looking at a 3D icon understand it is something to tap, what happens when an info item later becomes tappable, and why this is only a temporary choice for the first version.

AI can make a better icon set than I can. But if I can’t explain those things, I am only picking an option that looks fine, not making a design decision. I think the ability to produce an interface will make less and less difference. The ability to explain and defend a design decision is what is worth investing in.

Everyone can make UI. Is that a good thing?

I think yes, but not entirely. AI is removing part of the technical barrier in the field, and I support that. Not everyone with a good idea needs to master Figma. Not every PM needs to become a designer to present an idea. If AI helps someone visualize their thinking quickly, collaboration across teams can get more effective. The more accessible the tools, the wider the room for creativity.

The problem starts when we confuse knowing how to make an interface with knowing how to design a product. Anyone can make a very professional-looking login screen without ever thinking about validation, error states, accessibility, or how to organize information across a whole app. On simple screens that is not a visible problem. As the product gets more complex, the gaps in knowledge show up:

If users drop off midway and come back, where do they continue from?
If a phone number is already linked to another account, what do they see and what do they do next?
Do a new device and a familiar device follow the same flow?
If the product has many states, how does the interface respond?

Take the sign-up flow of a super app I am working on: the main steps are just phone number, OTP, password, basic info, face and PIN. The hard part is the remaining branches: what a user sees when blocked because the phone number is already linked to another account, which step a user returns to after dropping off, and why a device only becomes trusted after the whole registration is complete. Those screens rarely appear in a nice screenshot, but without them the product can’t be used.

A registration flow with blocked, leave-midway and resume branches. Illustrative mockup, content changed to protect the project’s confidentiality.

I don’t think only designers are allowed to answer those questions, but anyone making design decisions should care about them. Two products looking alike doesn’t mean the two people who made them understand the same things. I think this will be a big challenge when evaluating designers in the future.

Beginners improve faster, but may miss important lessons

If I were starting to learn design today, I would probably use AI a lot: asking about layout, hierarchy and typography, generating many options to compare. That is an advantage earlier generations didn’t have. But beginners can fall into a trap: getting a good result before understanding how it was made.

Before AI, getting a layout wrong forced me to find out why. I read, looked for examples, tried and adjusted. Those slow tasks built my design intuition. With AI, some of those hard stages can be skipped. That is not necessarily bad, because nobody needs to do everything the hard way just to prove they have skills. But if we keep skipping the parts that need thinking, I wonder where our knowledge will grow from.

Lee et al. (2025) surveyed 319 knowledge workers who use generative AI at least weekly. People who trusted AI more reported using less critical thinking, while people more confident in their own ability reported more critical thinking [1]. This is self-reported data and does not show that AI reduces intelligence, but it is worth reflecting on how we spend our thinking effort.

New designers need AI just as much as experienced ones. But more than a correct answer, they need the ability to recognize why the answer is correct.

The first option is hard to let go of

Working with AI, I noticed that the first option tends to have a lot of influence. When AI gives a fairly complete layout, the easiest thing is to keep editing it: change a color, swap a component, adjust spacing, add or remove a few elements. In the end there is a new interface, but the structure of thinking is almost the same as the first option. From the outside the designer is still working, but inside, the range of exploration may have narrowed very early.

Wadinambiarachchi et al. (2024) ran an experiment with 60 people: the group using an AI image generator for ideation fixated more on the initial example, known as design fixation [2]. The result doesn’t represent every UI design situation, but it points to a real risk: tools that suggest ideas can also limit the directions we think of next.

How I want to use AI

That is why I am changing how I use AI. Instead of always asking AI to propose a design, I ask more about my own assumptions: what is the weakness of this option, is there a completely different approach, if I removed its main element would the goal still be met, in which case would the current solution fail? I want AI to play the critic, not only the one who hands out answers.

I also don’t think the future of UI/UX is a race to see who makes the most screens in the shortest time, because if speed is the standard, AI will keep gaining the advantage. I hope technology helps designers cut repetitive work so they can spend time on things worth thinking about: understanding users, talking with PMs, understanding the business context, weighing trade-offs, checking usability, working with developers to get the solution into the real world. These things rarely show up in a pretty screenshot, but they directly affect product quality.

When PMs or developers can build prototypes themselves, designers get more material to discuss. Instead of saying “that’s not your job”, I would rather ask: how do we turn that first prototype into a solution with real value? But AI helping more people take part in making products doesn’t mean every option created should become a product. That makes evaluating design even more important.

Conclusion

Any technology that makes work easier can make us dependent on it, and AI is no exception. I don’t see that as a reason to limit AI, but as a reminder about how I work. If AI saves me two hours of building an interface, do I spend those two hours understanding the problem better? If AI gives me five options, do I really evaluate them or just pick the prettiest? If a screen is generated almost complete, do I still have the patience to ask whether it needs to exist at all?

When making an interface is no longer rare, designers need to find their value in deeper skills. Not to prove we are better than AI, but because a good product always needs more than a good-looking interface.

If you are thinking about this too and want to talk, message me through the contact section!

References

Both studies below have limited scope and do not replace my own point of view.

Lee, H.-P., Sarkar, A., Tankelevitch, L., Drosos, I., Rintel, S., Banks, R., Wilson, N. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. CHI 2025.
Wadinambiarachchi, S., Kelly, R. M., Pareek, S., Zhou, Q., Velloso, E. (2024). The Effects of Generative AI on Design Fixation and Divergent Thinking. CHI 2024.

Originally published at yurickart.com.