Design tokens in no-code UI builders for consistent themes

Why teams drift into inconsistent UI

Inconsistent UI rarely starts as a “design problem.” It starts as a time problem. Someone needs a button now, so they copy one from another page and tweak it until it looks close enough.

That’s how tiny differences sneak in: two blues that are almost the same, a corner radius that changes from 6 to 8, a heading that’s “kind of bold,” and padding that depends on who built the screen. In no-code builders, it’s even easier to make small one-off edits because controls are right there and changes feel harmless.

As the product grows, the drift accelerates. More pages means more repeated patterns. More builders means more personal taste. More teammates means more “quick fixes” made in isolation. If one person builds the customer portal and another builds the admin panel, you end up with two different interpretations of the same brand.

“Eyeballing” shows up in everyday work: picking a color until it “looks right,” nudging spacing by a couple pixels because the screen feels “too tight,” creating a new button style instead of using an existing one, mixing font sizes because the default feels “a bit small,” or fixing one screen without checking the rest.

The cost shows up later. Reviews slow down because feedback becomes subjective (“make it feel more like the other page”). Rework piles up because changes are hard to apply everywhere. Web and mobile diverge because different people make similar but not identical choices.

Design tokens solve this by replacing “close enough” decisions with shared values. The UI stays consistent even as the team and the app grow.

Design tokens, in plain language

Design tokens are named decisions about your UI. Instead of saying “use this blue” or “make buttons feel roomy,” you give those choices clear names that anyone can reuse.

A token is not the raw value. The raw value might be 16px, #2563EB, or 600 (font weight). The token is the label that explains what that value means in your product, like space-4, color-primary, or font-weight-semibold.

That shift stops the eyeballing problem. When people pick values by feel, you slowly collect five different blues, three slightly different headings, and spacing that changes from screen to screen.

Tokens work best as a single source of truth. If every screen and component references the same set of names, you can change the look across the whole app by updating a few token values, not by hunting through dozens of screens.

Tokens also bridge design and build. Designers use token names in specs, and builders use the same names in a no-code UI builder, so the design survives the handoff.

Most token sets fall into a few categories: color roles (primary, background, text, danger), typography (font family, sizes, weights, line height), spacing steps (padding, margins, gaps), shape and depth (radius, border widths, shadows), and sometimes motion (durations and easing).

The token set most products actually need

Most teams don’t need a huge token library. They need a small, clear set that covers most screens so people stop guessing values. This matters even more in no-code tools, where “just this once” tweaks spread fast.

A practical starter set covers five groups:

• Color: a few brand roles (primary, secondary), a neutral set (text, background, border), and status roles (success, warning, error). Add hover and disabled roles if you use them often.
• Typography: one font family (two at most), a small size scale (like 12/14/16/20/24/32), the weights you actually use, and matching line heights.
• Spacing: a simple ladder (like 4/8/12/16/24/32) for padding and gaps.
• Shape and effects: a few radii (none/sm/md/lg), border widths, and a small shadow set (0-3).
• Motion (optional): only if your app uses animations, with 2-3 durations and 1-2 easing names.

One rule keeps the library sane: if a value shows up in three or more places, make it a token. If it shows up once, treat it as suspicious before it becomes “the new normal.”

Naming rules that prevent token chaos

Good token names prevent arguments before they start. If people can guess a token without searching, they’ll reuse it. If they can’t, they’ll create a new one, and your theme will split.

Use semantic names first (not colors)

Prefer names that describe the job a value does in the UI, not what it looks like. text-primary tells everyone when to use it. blue-600 is just a paint bucket.

A useful pattern is two layers:

• Base tokens: raw building blocks like color-blue-600, space-16, font-14
• Semantic tokens: UI roles like text-primary, bg-surface, border-muted

In a no-code UI builder, semantic tokens are what help non-designers pick the right value quickly without eyeballing.

Rules for adding new tokens

Most token libraries get messy because “new” is the default. Make “reuse” the default.

Keep rules simple:

• Add a token only if it’s used in 2+ places or supports a real state (hover, disabled, error).
• If it’s a one-off, keep it local to the component.
• If two tokens differ by tiny amounts, pick one and delete the other.
• If you can’t explain the token’s purpose in one sentence, don’t add it.

Then standardize naming. Pick one casing style (kebab-case works well), use stable prefixes (text-, bg-, border-, icon-, space-), and keep number scales consistent (space-4, space-8, space-12, space-16).

Step-by-step: define tokens from what you already use

Treat your current UI as evidence. Before creating anything new, do a quick inventory: gather screenshots, inspect styles, and write down every color value, font size, and spacing value you actually see in production (including “one-off” values that only appear on one screen).

Next, reduce duplicates on purpose. You’ll usually find the same gray used in five slightly different hex values, or spacing that jumps between 14, 15, and 16. Pick one value to keep, then map the old values to it. This is where tokens become practical: you stop arguing about taste and start agreeing on a small set of shared choices.

A solid first version can be built in one pass:

• Palette tokens: raw colors (brand, neutrals, feedback colors)
• Semantic tokens: meaning-based colors (text, background, border, success, warning)
• Typography scale: 6-8 sizes with clear roles (body, label, H1-H3)
• Spacing scale: 6-10 steps you can reuse everywhere
• Component basics: a few standard radii and shadows

For each token, add one sentence of guidance: where to use it and where not to use it. Example: “text-muted is for helper text, not for primary buttons.”

Finally, decide ownership. It helps to name one person (or a small group) to approve changes, with a simple rule: “Add a new token only if an existing one can’t fit.” That keeps the system stable while the product grows.

How to apply tokens inside a no-code UI builder

Start with defaults every screen inherits: a base text style (font, size, line height, color), heading styles (H1-H3), and a small set of layout spacing rules so pages don’t feel random.

Next, map tokens to whatever your tool calls theme settings: theme variables, global styles, style presets, or design system settings. The goal is that choosing “Primary” or “Space/16” selects a token, not a one-off value.

Keep reusable styles focused on patterns you use every day. A starter set might include a card style (background, border, radius, padding, shadow), a form field style (label, input, help text), button styles, and table row density and hover states.

States are where inconsistency sneaks in, so define them early. Each interactive component should have token-driven values for hover, focus, disabled, and error. Focus should use the same ring color and thickness everywhere. Error should use the same border and text color pairing.

Finally, plan sharing. If your workspace supports templates or reusable modules, put tokens and base styles in a “starter app” new projects copy from. That way, new screens start consistent by default.

Component variants that stay consistent

Variants are where a UI system either becomes calm and predictable or turns into a pile of one-off tweaks. Variants work best when they’re a thin layer that maps to tokens for color, type, and spacing.

Start with a small set of key components you use everywhere: buttons, inputs, badges, alerts, and cards. Give each of them the same two dimensions of choice: size and intent. Size should be mechanical (typography and spacing). Intent should be meaning (semantic colors).

Size and intent without guesswork

Size variants stay consistent when they only change a few token-based properties: font size, padding, and border radius. Intent variants should primarily change color roles (background, text, border) and never quietly change spacing.

A set that covers most products:

• Sizes: sm, md, lg
• Intents: primary, secondary, danger
• States: default, hover, focus, disabled

Interaction rules teams can follow

Define state rules that apply to every component, not just buttons. For example: focus always shows a visible ring, hover increases contrast in a consistent way, and disabled uses the same opacity and blocks clicks.

Add a new variant only when it represents a recurring meaning (like “danger”). If it’s a one-time layout need, it’s usually a new component or a wrapper, not a variant everyone will misuse later.

Keeping web and mobile themes aligned

When a product ships on web and mobile, “same brand” doesn’t always mean “same pixels.” The goal is for screens to feel like one family, even when platforms have different defaults.

Start with shared tokens that travel well: color roles (background, surface, text, primary, danger), a typography scale (sizes and weights), and spacing tokens (4, 8, 12, 16, 24). These remove guesswork and make updates predictable.

Then accept real differences. Mobile needs larger touch targets and often a bit more spacing. Web needs denser tables, sidebars, and multi-column layouts. Fonts can differ too: you might use a brand font on web but prefer platform defaults on iOS/Android for readability and performance.

A practical approach is two layers: global tokens that define meaning, and platform tokens that define how that meaning is rendered.

• Global: color.text, color.primary, space.md, radius.sm, type.body
• Web-only: type.family.web, control.height.web, space.tableRow
• Mobile-only: type.family.mobile, control.height.mobile, space.touch

Keep component names consistent (Button/Primary) even if sizes differ. Require contrast checks for both themes before release.

Governance: how tokens stay healthy over time

Tokens only work if they stay stable and understandable. Without lightweight governance, teams quietly add “one more blue” or “one more padding,” and you’re back to eyeballing.

A lightweight token change flow

Keep the process small, but real:

• Request: anyone can ask for a new token or change, with a screenshot and a reason.
• Review: one designer and one builder check impact across key screens.
• Approve: confirm naming, accessibility (contrast, tap size), and whether it’s truly new.
• Release: publish updates on a schedule (weekly or per sprint), not ad hoc.
• Communicate: share what changed and what to use instead.

Maintain a simple changelog with deprecations. If an old token is being replaced, say what to use instead, keep it working for a while, and mark it clearly so new screens don’t adopt it.

Cleanup is part of the job. Once a month, remove unused tokens and component variants (or at least flag them).

Make tokens usable for everyone

Non-designers need examples, not theory.

Do: use the spacing ladder for gaps, and use the Primary Button variant for the main action.

Don’t: set padding to “13px because it looks right,” or create a new button style to match one screen.

Tie token work to product priorities: new features, rebrands, and accessibility fixes should drive token updates, not personal preference.

Common mistakes and traps

The fastest way to lose the benefits of tokens is to treat them like a dumping ground. You start with good intent, then a few quick fixes pile up, and the team is back to eyeballing.

A common trap is creating too many tokens too early. If every screen gets its own color or spacing token, you’re not building a system - you’re cataloging exceptions. Only add a new token when you can point to at least two places it will be used.

Another quiet problem is letting raw values sneak into components. Someone sets button padding to 14px “just this once,” or uses a hex color directly in a card. Weeks later, nobody remembers why it’s different. Make it a habit: if it’s visible and repeatable, it should be a token.

Also watch out for mixing token types. Base tokens (like gray-900 or space-4) describe raw values. Semantic tokens (like text-primary or surface-muted) describe meaning. Problems start when one component uses base tokens and another uses semantic tokens for the same role.

States are another late-stage pain. Teams often define normal styles, then patch focus, hover, disabled, and error right before release. That’s how you end up with inconsistent focus rings and three different “error” reds.

Before you scale, do a quick trap check:

• Limit new tokens to shared needs, not one-off screens
• Avoid raw values inside components wherever possible
• Separate base vs semantic tokens and apply them consistently
• Define states (focus, error, disabled) early
• Leave room for dark mode or a future brand refresh by swapping semantic tokens, not rewriting components

Quick checklist before you scale

Before you roll your UI out to more screens, teams, or products, check whether your foundation is clear enough to copy without guessing.

• Color roles are semantic. Tokens cover text (default, muted, inverse), surfaces (page, card), borders (default, focus), and status (success, warning, danger).
• Type maps to a small scale. A short set of text styles (H1-H3, body, small) with defined size, weight, and line height.
• Spacing uses steps people remember. Common paddings and gaps come from a tight ladder (4, 8, 12, 16, 24). If “14” keeps showing up, that’s a sign your ladder needs work.
• Top components have variants. Your most-used components have size (sm/md/lg) and intent (primary/secondary/danger) that match token roles.
• Ownership is clear. One person (or small group) approves changes, with a lightweight routine: why, impact, and when to ship.

Example: stopping UI drift in a portal and admin panel

A small team is building two apps at once: a customer portal and an internal admin panel. Different people touch different screens, and they build fast inside a no-code UI builder. After a few weeks, the UI starts to feel “off,” even though no one can name a single problem.

Before tokens, review comments pile up: buttons are almost the same but not quite, spacing shifts from screen to screen, form fields don’t match, and the portal feels “friendly” while the admin panel feels “strict” by accident.

They fix it by introducing a small, practical token set. They define semantic colors (Primary, Success, Danger, TextMuted), a spacing scale (4, 8, 12, 16, 24), and button variants (Primary, Secondary, Ghost) with one radius and consistent states.

Now contributors stop picking random hex values and font sizes in each screen. They choose tokens and variants, so every new page inherits the same decisions.

Building gets faster because the choices are already made. Reviews shift from tiny visual nits to real UX issues. “Make this button the primary variant” replaces “Can you make it a bit more blue and slightly taller?”

Then a small rebrand hits: the primary color changes and the font scale tightens. With tokens, the team updates a few values once, and both the portal and admin panel refresh together.

Next steps: start small, then standardize

Pick one flow people use a lot and that has obvious drift, like onboarding, a settings page, or a simple form. Converting a single flow is the fastest way to prove the idea and stop eyeballing.

Start with a small, safe token set: primary/background/text/border/danger, a short type scale, a spacing ladder, and 2-3 radius and shadow levels. Then create a tiny component set that uses only tokens: one button, one input, one card, one alert. Add variants only when they solve a real need.

Run a short review with the team using two screenshots: one “before” screen with inconsistent padding and fonts, and one “after” screen built from tokens and variants. Agree on a couple rules (like “no hard-coded colors” and “spacing must be a token”) and fix the top inconsistencies first.

For rollout, convert new screens first, then backfill older ones as you touch them. When support asks for a new admin filter, rebuild that panel using token-based components and replace only what you’re editing.

If you’re building full products (backend, web, and mobile) in AppMaster, it helps to set tokens and reusable UI styles early so new screens inherit the same decisions. That way, visual consistency and app logic can move forward together without repeated cleanup later.