When building DSM design systems with Sketch, there are some key best practices that will ensure you have the best possible DSM experience. This guide will walk you through:
Architecting your master Sketch files
Building a Foundations Sketch file (colors and text styles)
Building a Components Sketch file (Sketch symbols)
A good structure for your master Sketch files will greatly improve efficiency in building and using your DSM design system.
File and page setup
Think about your Sketch file architecture as a reflection of your design system structure. We recommend first setting up Foundations and Components as separate Sketch files. There will be portions of your design system that don’t need to exist in Sketch, but it’s best to organize your page structure to match the way you are thinking about grouping Foundations and Components within DSM. This makes the setup process for your design system much faster, and it can help designers quickly find what they're looking for.
For example, if you organize your DSM components like this:
Then you might organize your Sketch file like this:
Artboard section: Primary
Pro tip: In both DSM and your Sketch files, you can use emojis to help clarify uses and group like items.
Single file vs connected files
Teams either build a single master Sketch file, or they use a set of linked files as their master.
When supporting a number of products that might need particular parts of a "core" design system but not others (e.g., colors and fonts but not a media card), teams tend to split their files and use shared Sketch libraries to connect. This is also more common for teams that have a number of designers maintaining portions of their master files. By splitting, it's easier to work on the system at the same time.
One thing to be cautious of is making sure all those files are connected and they live in the same place. It’s easy to create a scenario where a designer only has pieces of the Sketch library and is missing critical information.
Working with a single master file typically works well for small teams that need to support a single product. It's easier for small teams to maintain and distribute a single file vs multiple files. However, as the product landscape and teams grow, maintaining a UX library in a single file becomes unruly and calls for switching to a multi-file model.
Here are some reasons for splitting a master file into multiple connected libraries:
If there are multiple editors. Splitting the file helps avoid conflicts. One editor can update the icons file, while another updates the components file.
If the file size becomes too large. Working and syncing a single file becomes sluggish. Splitting it up into smaller files will speed up your work.
If you're supporting multiple products, each with some unique UX elements. To support multiple products, it's easier to maintain a file per product with its unique components and iconograph, thus helping reduce "noise." Product-specific files would use shared elements (symbols, styles) from a linked core library. Designers will be able to use elements from the core library, as well as product-unique elements.
If you're supporting multiple themes. If you're designing for multiple brands using the same UX elements, but with different styles, you can create a single core library of components—possibly a separate Icons file—and then create a file with styles per theme. This assumes you can meet the theming needs with layer styles and symbols.
Before any of the foundations are built, follow the pages setup instructions and:
Create a foundations Sketch file.
Create a single artboard for colors/layer styles and an artboard for text styles.
The following sections will cover why you should use a single artboard for colors and layer styles.
Order of operations
When building your master Sketch files from scratch, there is an ideal order of operations. Create your foundations in the following order:
Color and layer styles
Following these guidelines when building your files will help you get the most out of colors and layer styles in DSM.
Why use layer styles instead of colors?
Layer styles allow you to save set color attributes. Once you define a layer style, it can be reapplied to a number of different components or shapes. Not only does this save you the hassle of creating document colors or using an eyedropper each time you need to apply color to something, but it reduces errors by having a set of named layers that are consistent within your design system. It also makes the process of updating or scaling your system more convenient.
For example, to update your primary color, simply update the layer style. Every component that uses the corresponding primary layer style will be updated as well. There's no need to go component by component to make updates, and you can stop worrying if you've caught everything.
What should be included in layer styles?
Fills (colors, gradients, photo)
Shadows/elevation (inner and outer)
Are color swatches the same thing?
No. Color swatches are the antiquated way of handling color attributes. Rather than creating a workaround, layer styles solve for this as built-in Sketch functionality. We recommend replacing all color swatches with layer styles and applying those styles to each Sketch symbol.
Splitting layer attributes
With layer styles, Sketch allows you to combine a number of attributes as a single saved style. We recommend keeping fill, border, shadow, and gradient styles separate from one another.
For example, if you have a repeated style (like in a button) that includes a white fill and a blue border, we recommend saving those as two separate styles.
Why? If you ever want to use the white fill on its own, you’d need to create another layer style to account for it. That's because the white fill and blue border are attached as a single style and cannot be separated. Additionally, if you ever wanted to update that white shade, you’d have to do so in two places. By keeping layer styles separate, you can update them in isolation.
Component-agnostic layer styles
Many teams use layer styles to account for specific component states or single-use cases (e.g., button/primary/hover). This is acceptable, but not recommended.
We recommend naming your layer styles in a way that is component-agnostic. By doing so, you are setting up your system in a modular way that can account for future use cases of that same layer style. Use documentation within the system to detail particular use cases, but keep the layers universal.
Saved layer styles
After a layer style has been created, it’s possible for that style to become unsaved. This essentially means that an update has been made to a one-off use case of that layer style without updating the master layer style (e.g., changing the opacity, updating the hex value from one blue to another, etc.). Any time you see a layer style in the Appearance panel that is italicized with an asterisk, it is unsaved.
There are two main options when a layer style is unsaved:
Create a new layer style. Select this option if the change you made to the style is new and will now be reused apart from the original saved layer style.
Update the layer style. This option will replace the saved layer style with the changes that have been made in this one-off use case. Note that if you choose to update the existing layer style, it will replace all existing use-cases of this layer style with the new version you’ve created.
If the style is not saved, then users of the library cannot reuse the style. For example, if the one-off change is set on a symbol, when a user of the library uses the symbol via the Sketch library Insert option, they'll get the symbol with its "official" style, not the unsaved one.
Don’t name your layers styles by hex value. This is a common mistake that prevents those layers from easily being updated in the future when that hex value is no longer relevant.
Text styles allow you to save set text attributes. Once you define a saved text style, it can be reapplied to a number of different components. This reduces errors by having a set of named text styles that are consistent within your design system. It also makes the process for updating or scaling your system much more convenient.
Need to update your H1? Simply update the text style and every component that uses the corresponding style will be updated as well. There's no need to go component by component to make updates, and you can stop worrying if you've caught everything.
What should be included in text styles?
All text in your master Sketch files should be saved. This not only includes headings and paragraphs, but also placeholders, subtitles, footer text, and more.
Here are a few things to include in a text style:
Character, line, and paragraph spacing
Text transforms (all caps, all lowercase, or default)
Saved Text Styles
After a text style has been created, it’s possible for that style to become unsaved. This essentially means that an update has been made to a one-off use case of that text style without updating the master text style (e.g., changing the color, alignment, weight, size, etc.). Any time you see a layer style in Sketch's Appearance panel that is italicized with an asterisk, it is unsaved.
Over-engineering text styles
Because Sketch styles require unique saved text styles to account for alignment, color, weight, etc., it’s common to see design systems that account for every possible version of a text style.
Don’t create text styles that aren’t actually used within your system just because you think you might use it in the future. For example, if you never use right-aligned headers, don’t create H1–H6s that are right-aligned. Only create the styles that you'll actually use.
In your Sketch file, save icons as symbols and mark them for export in SVG format. This will allow you to easily add them to your DSM documentation site later.
Icons should be built at set sizes (e.g., 24x24, 48x48) to be available in the override panel for one-off use cases. If icons are built at slightly different sizes, they won’t appear in the Sketch override panel for use.
As with all colors in the Sketch file, icons should use saved layer styles to account for their fills and borders, not just Sketch colors or color swatches.
You can download any icon from the DSM documentation site as an SVG, so consider adding assets as icons that you might frequently download—logos, illustrations, etc.
Order of operations
When building your master Sketch files, build all your foundations first (layer styles, text styles, and icons) in a separate file. Once those have been built, use them to fill out your smallest atomic components, the elements that exist on their own or inside larger components. For example, build your buttons before you build a card that will contain a button.
Anatomy of a component
When building components, follow these guidelines:
Apply saved layer styles for all colors that exist within the components.
Apply saved text styles for all text that exists within the components.
Leverage Smart Layouts for all components that should be responsive.
Rename each layer and group within the symbol for ease of use in the override panel. For example: “Background Fill," “Title Text,” or “Image.”
Manage overrides in the master symbol that designers shouldn’t be able to adjust.
States and variants
When it comes to states or variants, there are many ways to approach building a component in Sketch.
For components that have designated states—like buttons or input fields—we recommend building unique saved symbols for each state rather than using overrides to account for states
We recommend this approach because:
The states and variants are then accessible through Sketch libraries.
If you need to change details of a specific state in the future (e.g., updating your primary button hover), you can do so efficiently, knowing that everywhere that state is used, it will be updated.
It speeds up delivery time for designers. They no longer have to pull down a master symbol and update layer and text styles to account for a specific state.
It maintains consistency of the system and ensures designers are using a component state properly. When using a single master with overrides, it’s easier for designers to inaccurately build a component’s state or to apply styles they aren’t supposed to use.
It makes it easier for developers to understand what component state is used in screen design. The symbol name will appear in Inspect when developers inspect a design to build.
The downside of this approach is that editors of the system will need to update all symbols if a property that's shared across all component states changes. For example, if the border radius of the button changes, you'll need to update all button symbols instead of just one.