A strong design system ensures consistency across your app, and Shaper provides built-in support for design tokens, global styles, and reusable components – all versioned in Git alongside your code. In Shaper, your design system isn’t separate from development; it is part of the codebase (truly “design system in Shaper”). This section covers how to manage tokens, styles, and components, plus recommended naming conventions to keep designers and developers in sync.

​
Design Tokens and Global Styles

Design tokens are the small, reusable style variables – colors, typography, spacing, etc. – that make up your brand’s visual language. Shaper lets you define and manage these tokens so that changes propagate throughout your project.
  • Color Tokens: You can define a palette of colors (for example: Primary, Secondary, Success, Warning, etc.). In Shaper’s interface, open the Token Editor (found in the design panel or project settings) to create or edit tokens. Assign names to colors instead of using hex codes everywhere. For instance, define color-primary: #1D4ED8 (a blue) as a token. Then, when setting a button background, use “Primary” instead of a random hex. All instances of that token are linked – update the token once, and every element using it updates too. Shaper stores tokens in the code (likely a JSON or a theme file), so they are version-controlled. This means designers and developers can both see token definitions in the repo, and any changes to tokens are tracked just like code changes (no more drifting style guides).
  • Typography & Font Styles: Shaper allows global text styles via tokens as well. Define font families, sizes, line-heights, etc. as tokens or presets (e.g., a “Heading1” style with a certain font size and weight). Use the Typography or Styles panel to manage these. For example, set up tokens like font-heading: Inter or font-size-large: 24px. This ensures all your headings use the same font and size values. If you decide to update the base font or scale up the size for accessibility, adjust the token and the change will apply everywhere. Tip: Combine tokens (e.g., a Heading component might use font-heading + font-size-large + a color token).
  • Spacing & Sizing: Similar to colors and fonts, you can create spacing tokens (for consistent padding/margins). For instance, define spacing units like spacing-sm = 4px, spacing-md = 8px, etc., and use those in your layout settings. This helps maintain rhythm and consistency. In Shaper’s layout or token editor, look for a way to manage spacing values. Many teams use an 8px grid – you can reflect that by making your base spacing token 8px and scaling multiples (4px, 8px, 16px, etc.).
  • State Styles: Your design system might include states (hover, active, disabled styles for buttons, links, etc.). Shaper supports designing these states – for example, you can set up a Button component with variants or states. Use tokens for state colors too (like color-primary-hover). This way, even interactive states remain consistent.
  • Versioning Tokens: Because tokens are essentially code (e.g., part of a Tailwind config or a CSS variables file), any token changes generate a Git commit. Tokens are synced and versioned like code – you can track who changed a color value, revert if a new palette doesn’t work, or review token changes in a pull request. This transparency makes collaboration easier: developers trust that design changes are traceable, and designers gain confidence to tweak a token knowing it can be undone if needed.
Best Practices:
  • Semantic Naming: Name tokens by purpose, not appearance. For example, use names like primary-bg, secondary-text, border-color-light instead of blue-500 or gray-200. This helps both designers and devs understand how a token is meant to be used. It also maps better to code (e.g., a CSS variable -color-primary-bg).
  • Organization: Group tokens logically. Shaper’s token editor might allow categories (Colors, Typography, Spacing, etc.). Keeping tokens tidy will help as your design system grows.
  • Consistency with Code: If your developers use Tailwind CSS or another system, align token naming with it. Shaper’s underlying code likely uses Tailwind classes or CSS variables. For example, if using Tailwind, a color token might sync with the Tailwind theme. Work with your devs to ensure the token changes in Shaper update the theme configuration so that class names remain consistent.