Guides · March 10, 2023
Design Tokens for E-Commerce UIs
Design tokens turn scattered hex codes and pixel values into a single named source of truth, so a store's colors, spacing, and type stay consistent across every page and theme. Here is how to think about tokens as a merchant or designer, and why we build our Figma themes around them.
By Polo Themes
Design tokens are named, reusable values — a color, a spacing unit, a font size, a border radius — that stand in for hardcoded numbers throughout a design or codebase. Instead of a button using #1a73e8 in one file and #1a72e7 in another, both reference a single accent token, so changing the brand color once updates it everywhere. For e-commerce UIs specifically, tokens are what keep a storefront looking like one coherent product instead of a collection of pages that were each styled slightly differently.
This matters more in commerce than in almost any other kind of site, because an online store has an unusually large surface area: home page, collection grids, product detail pages, cart, checkout, account pages, blog, and often a handful of app-injected widgets from review tools, upsell apps, or a subscription platform. Without a token system, each of those surfaces tends to drift — a slightly different gray here, a spacing value that is 14px instead of 16px there — and shoppers feel that inconsistency even if they cannot name it. Our Figma theme collection is built with token discipline in mind precisely because a design file that hands off cleanly to development saves weeks of back-and-forth later.
What a Token System Actually Is
At its simplest, a token is a variable with a name and a value. color.accent might resolve to a specific blue. space.md might resolve to 16px. radius.card might resolve to 8px. On their own, this sounds like nothing more than variables — and it is, in the same sense that a spreadsheet formula is nothing more than arithmetic. The value comes from what the naming and layering enable once a project has more than a handful of screens.
Two tiers: primitive tokens and semantic tokens
Most mature token systems split into two layers. Primitive tokens are the raw palette — every color swatch, every spacing step, every type size the brand might ever use, named plainly (blue-600, space-4, font-size-14). Semantic tokens are named for their job rather than their appearance — accent, surface, text-muted, border — and each one points at a primitive. A button does not reference blue-600 directly; it references accent, which happens to resolve to blue-600 today.
The payoff of this split shows up the first time a rebrand, a dark mode, or a seasonal palette swap comes up. If every component referenced primitives directly, a color change means hunting down every instance of blue-600 and deciding, file by file, whether that particular use was decorative or functional. If components reference semantic tokens, you repoint accent to a new primitive once, and every button, link, and focus ring updates together — because they were all expressing the same intent, not coincidentally sharing a hex code.
Common token categories in a storefront
- Color: background/surface levels, foreground/text levels, accent and its hover/active states, borders, and status colors (success, warning, error) for stock levels or form validation.
- Spacing: a consistent scale (commonly 4px or 8px increments) used for padding, gaps, and margins so nothing is eyeballed per component.
- Typography: font family, a defined size/weight/line-height scale for headings and body copy, so a product title on the PDP and a heading on the blog share the same rhythm.
- Radius and elevation: corner rounding and shadow depth, kept consistent between cards, buttons, and modals rather than varying by whoever built that screen.
- Motion: duration and easing values for transitions — hover states, drawer opens, add-to-cart feedback — so interactions feel like one system rather than a mix of instant and sluggish.
Why Tokens Matter More for Commerce Than for a Brochure Site
A five-page marketing site can survive without a token system because a designer can hold the whole thing in their head. An e-commerce storefront cannot, for a few reasons specific to the category.
Surface area and repetition
A single product card design gets repeated hundreds or thousands of times across collection pages, search results, the cart drawer, and recommendation carousels. If that card's spacing or color is hardcoded rather than tokenized, a single tweak requires touching every instance — and inconsistencies creep in as new sections get added by different people at different times. A token-based card pulls its padding, radius, and colors from the same handful of named values used everywhere else, so one update propagates cleanly.
Theme and seasonal flexibility
Merchants routinely want a seasonal palette shift, a dark mode option, or the ability to reuse a theme across sub-brands with different accent colors. That is straightforward when the theme's components reference semantic tokens — swap the token values, keep the components untouched. It is a rebuild when every component has its own hardcoded values baked in. This is exactly the gap a well-structured Figma theme is meant to close: the design file should hand off with named color and type styles that map directly to development variables, not flattened, ungrouped shapes.
Design-to-development handoff
Commerce projects almost always involve a handoff — a designer working in Figma, a developer implementing in a theme framework or a custom storefront. Named tokens make that handoff a translation exercise instead of a guessing game: a developer can map color/accent in the design file directly to a CSS variable or a design-system token in code, rather than sampling pixels from a screenshot and hoping the value matches elsewhere. This is one of the reasons we build our Optics Figma theme and the rest of our Figma library around named styles and components rather than one-off artwork — a merchant's team, or their agency, can pick the file apart and understand exactly what each style is for.
A Practical Way to Start, Even on a Small Team
You do not need a full design-systems team to benefit from tokens. A useful starting point looks like this:
- Audit what you already have. Pull every color, font size, and spacing value currently in use across your storefront's key pages. It is common to find a dozen near-identical grays or three different "medium" spacing values that were never meant to diverge.
- Consolidate into a small primitive scale. Cut the near-duplicates down to a deliberate set — a handful of neutrals, one or two accent colors with hover/active variants, a type scale of five or six sizes, and a spacing scale in consistent steps.
- Name the semantic layer around intent, not appearance. Define surface, surface-muted, foreground, text-muted, accent, border, success, danger — and map each to a primitive. This is the layer components should actually consume.
- Apply the semantic tokens to your components, not the primitives directly. Buttons, cards, badges, and form fields should reference accent or border, never a raw hex value or a specific pixel number.
- Document the mapping somewhere both design and development can see. Even a simple shared table of token name, value, and usage note prevents the slow drift back into one-off values.
The goal is not perfection on day one — it is having a named layer to point at the next time something needs to change, instead of re-deriving the right value from scratch every time.
Where Tokens Show Up Across a Real Storefront
Tokens are easiest to appreciate by walking through where they actually matter on a live store. On the home page, hero banners and featured collection blocks should share the same surface and spacing tokens as the rest of the page, so a promotional section does not look like it was dropped in from a different site. On collection and category pages, the product grid's card spacing, hover states, and badge colors (sale, low stock, new) all draw from the same small set of values, which is what makes a grid of forty different products still read as orderly.
On the product detail page, the token discipline matters most around the buy box — price, variant selectors, add-to-cart button, and trust badges all need consistent color and spacing so the eye can find the primary action quickly. A theme like our Medical Figma theme, for a health-adjacent category where shoppers are already cautious, leans on this consistency to keep trust signals legible rather than visually competing with the rest of the page. In the cart and checkout flow, token consistency is what keeps a shopper's confidence steady through the last, most conversion-sensitive steps — a checkout that suddenly uses different spacing or a slightly different accent color reads, even subconsciously, as less trustworthy.
Where Polo Themes Fits
Our Figma theme catalog is built around named color styles, type styles, and component variants rather than flattened artwork, which is what lets a merchant or their developer repoint a handful of values and get a coherent theme change rather than a page-by-page rebuild. It is also why a single Figma theme can pair cleanly with its Shopify counterpart — the token structure in the design file is meant to map onto the settings and CSS variables the live theme actually exposes, so a color or spacing decision made in Figma is not lost in translation during build. If you are evaluating themes for a new store, it is worth asking any vendor, including us, whether their file is built on named styles or on one-off shapes — the answer determines how much rework you will do the first time you want to change anything.
Frequently Asked Questions
Do I need design tokens if I am using an off-the-shelf theme?
You benefit from them either way. A theme built on tokens lets you change your brand colors, spacing, or type through a small number of settings rather than hand-editing CSS across dozens of files, which matters even if you never touch a design tool yourself.
What is the difference between a design token and a CSS variable?
A design token is the concept — a named, reusable value that captures a design decision. A CSS custom property (variable) is one common way to implement that concept in code. In a well-connected workflow, a token named in a design file maps directly to a CSS variable of the same name, so the two are two views of the same underlying value.
Can a small store justify setting up a token system?
Yes, and arguably a small team benefits more, since there is no dedicated designer to manually enforce consistency by memory. Starting with even a modest semantic layer — a handful of color and spacing tokens — pays off the first time you redesign a promotional banner or add a new page and want it to look like it belongs.
How does this connect to choosing between a Shopify theme and a Figma theme?
A Shopify theme gives you tokens already wired into a working store through the theme editor's settings. A Figma theme gives you the design-layer tokens to customize freely before development, which suits teams planning a custom build or a different platform. Either path benefits from the same underlying discipline — named values over hardcoded ones.