The Design System Studio (DSS) is a tool for designing and configuring styles for Skuid applications and pages.


API version 1 components can’t be styled by configuring a design system in the Design System Studio, they must be styled using themes.

Why use a Design System?

Enforce brand

The DSS lets you make your company’s brand watch dogs happy—without using HTML or CSS. Style Skuid components with custom colors, fonts, and sizes to match your company’s style guide and branding criteria.

Need even more flexibility? The DSS allows builders to leverage variables within style variants in individual components and subcomponents, and even create new variants for increased customization.


Got something very specific that can’t be done via the DSS? Expand with CSS …

Streamline app development

Even if you are only creating internal apps, style choices (“What color should I make this button? Does the padding for this need to be wider?”) take time—time you could devote to creating a more satisfying user experience (and therefore a more effective app).

Plus, if each individual developer on a team is spending time styling, that means a lot of aggregate time lost, inconsistent results, and confusion for new hires or members trying to get up to speed quickly.

Instead of making global style decisions every time you build a new app, create a design system and then reuse it for faster and more efficient development. Build once: use as needed.

Create a consistent user experience

Every time you build an app, you need to think about the UX. (You are thinking about the user experience, aren’t you?)

Is the app self-explanatory? Is the workflow intuitive and easy to follow? Are calls to action clear?

Once you solve these issues and launch the app, the app is essentially training user expectations using visual cues provided by DSS styles. So, when you build the next app, why force users to learn new cues? Leverage their familiarity with other applications you’ve built by reusing the DSS.


The Design System Studio supports the creation and customization of a design system. A design system is a file containing the variables and style variants that compose overarching style rules for all visual elements.

A design system consists of two elements: variables and style variants. Understanding how these two concepts interact within a design system and how a design system connects to Skuid components in the Composer is key to making a functional and appealing UI for your app.

How they work together

To better understand these concepts, think about customizing a house:

This house is a base model.


No fancy decorations, no cool colors. Just functional.

Imagine you buy a house like this in a neighborhood filled with houses of the same design (congrats!).

Now, you want to put your mark on it—customize it and make it yours.

Start with a The Design System

First, get a “plan” This is the design system.
You don’t just randomly wander down the aisles of a improvement store, plucking things off the shelf. You start with a vision for how you want to update and customize this house: you want and what you need. If you have style or brand guides, they’re the for the DSS. But even if you don’t, the DSS reflects a consistent idea of what you are trying to do with the app.

And then use DSS variables

Next, make some larger decisions These are the DSS variables.
Such as: What colors to paint the rooms? You could select an off-the-shelf option—or mix your own. What flooring materials to use? Hardwood? Carpeting? A combination of each? Crown moulding? Chrome fixtures or brass? and so on … Similar to CSS style rules, variables are global style declarations separated by categories, based on purpose of the variable (Color, Typography, etc.). Think of these as the foundation of the app’s styles or “base variants” that serve as starting points. A new design system comes with default variables, like colors, borders, opacity, shadows, and typography. Some default variables can be modified and new ones created.

Here’s an example:

Decide on a color palette Create a new color variable
Let’s say: sage green, mulberry, and cream. You pick the foundation colors so you can then use them in different ways throughout the house. Same with your flooring options, fixtures, etc. The variable is called “Logo Fuchsia” and it can be used in component style variants throughout the DSS, as well as within the Composer to provide more granular style configurations.

Finally: Component/subcomponent style variables

After larger decisions, “get specific” Think: style variables.
What color—or colors—will you use for the master bedroom? The guest room? Carpeting seems best for the bedroom but wall-to-wall or a rug? What color? If a rug, what size? To get things the way you want them, build on the original decisions with more specificity. Style variants are design variations for a specific component made by applying custom variables and configurations to a base set of visual design properties. Every component in the DSS comes with default style variants—what component looks like “out of the box.” Use the base variables you created (along with component-specific property configurations) to create unique component style variants. These can be used as selectable options in the component’s Style tab within the Composer.

More examples:

Using colors Using variables
Remember that color pallet you selected? You can use those colors in different ways in each room of the home: sometimes darker or lighter hues of the colors, sometimes alongside an accent wall. (But you’re always using the selected colors.) When styling buttons, leverage color variables to set a consistent look and feel for primary, utility and destructive buttons across multiple pages. Then use the style variants to tweak other aspects of the buttons: borders, labels, and states such as focus, hover and active.

Once you’re done customizing the house, the result will be a home that meets your specific design.


Though the functionality is the same, it looks (and feels) completely different from all the other houses in the neighborhood.

DSS Best Practices

  • Always start by configuring the design system’s variables before moving onto component-level configuration. Setting the high-level design choices found in the variables section allows for a consistent palette of custom color, text, border, and other options based on a company’s style guide before even selecting a DSS component to style.
  • The Design System Studio is built with consistency and reusability in mind. If a change is made to the Primary Border Size variable, that change will appear in any style variant using that Primary Border Size variable. Therefore, consider the overall styling of the app—via the variables—before creating component style variants. The assigned Design System will act as a living style guide for all apps associated with it.