Our symbols guidelines in sketch

Move fast, and don’t break things

At November Five, we create multiple design systems a year. Doing so, we’ve noticed that every designer approaches the organisation of their Sketch file a little differently. This means working in someone else’s file wastes time.

We’ve found ourselves endlessly scrolling through a symbols list or even messing up certain components. Sounds familiar?

Okay, maybe this is a bit dramatic. A meeting with the previous designer usually sorts most things out, but let’s be honest: it’s not a bullet-proof system.

Especially when your team designs multiple design systems a year, it’s important to have every designer on the same page on how to organise things, regardless of the project they’re working on.

“What are the components used in this design? How do they behave?” “Where can I find this symbol?”

THE GOAL

Our goal was to define an approach on how to set up and organise symbols.

We also wanted to make sure a designer could quickly and completely understand which components are used throughout a product, and how they behave.

We already have a sticker sheet where all the different components and their behaviours are layed out, but we believe that this overview should also be clear when you open your symbols menu.

With the guidelines we eventually defined, any of our designers are able to hit the ground running when they’re assigned to, for example, design the UI of a new feature for an existing product.

So, today we’ll have a closer look!

1. WHEN TO CREATE A SYMBOL

Only create a symbol if we really benefit from it. Obviously, a button is a component we’re going to use a lot, making it an appropriate symbol. A symbol is also convenient if you want to see how a change to a single thumbnail impacts the overview of 6 thumbnails. etc.

But not every component should be a symbol. There’s no use in building a fully responsive and complex date picker as a symbol. It’s important that the behaviour of these complex components are displayed and explained on the sticker sheet.

2. KEEP THINGS SIMPLE

When ‘Nested Symbols’ were first introduced to Sketch, we immediately explored every possibility. We soon realised they’re not always worth the effort.

When setting up a symbol, we got caught up in making sure to show all the possible states of a component within one single symbol. This sounds very efficient, but we quickly realised it can cause confusion when trying to create a particular state of a component using only overrides of one symbol.

In most cases, it also takes more time to build these kinds of symbols instead of just building three symbols for three states of a symbol, for example.

More importantly, it’s more clear for a designer to have a set of symbols he knows he can use instead of one he should modify.

As we always say, technology is an enabler, not a dictator — which in this case meant that just because we could, didn’t mean we should ;)

Let’s give an example. Say we’re building the symbol for a toast component. This component usually has some different states with different content. For instance, a toast with a success message will be green and have a checkmark icon, while a toast with an error message will be red with an exclamation mark icon. Following the rule described above, these states should exist in separate symbols.

3. LOCK NESTED SYMBOLS

We lock nested symbols, like icons or text layers, that musn’t be overridden within the component. This is appropriate when, for example, we want to make sure an error toast always has the same ‘undo button’ next to the message.

4. KEEP LAYER NAMES CONSISTENT

If a text layer may be overridden, we make sure that the layer names are the same across the different symbols. This way, the text of our override will not change when we’re switching between states (this is especially helpful when dealing with interaction states like hover states or clicked states).

5. GROUP BY COMPONENT

We’re big believers of Brad Frost’s ‘Atomic Design’ and our gut feeling told us we should separate all our symbols into Atoms, Molecules and Organisms.

After testing this approach for a few months, we realised we often spent a substantial amount of time on deciding if a symbol was an Atom or a Molecule. This obviously didn’t benefit our workflow, so we decided to group all symbols according to the used components of a product.

And as Brad himself says, it’s a helpful mental model, not a rigid dogma!

Extra bonus: your fellow designers and yourself can easily see which symbols are used for which components just by opening the symbols menu.

6. USE COMPONENT GROUPS

There are components that we’d like to keep together to keep our symbols list organised. Form elements, for instance, is a good example of a component group. This way all components like text fields, dropdown menus, checkbox lists, … are kept together.

For icons, we always make sure to group them by size. This again allows our colleagues to easily see which sizes are used throughout the design. Also, when you do want to override a nested icon symbol, you’ll only be able to override with a symbol that has the same dimensions as the initial symbol.

7. NAMING SYMBOLS

To avoid confusion among the project team, it’s important to use the same component names as used on the sticker sheet.

Additionally, we like to use common naming conventions for components (if possible). Because we often work with components of Google’s Material Design system, we make sure to take a look at their naming conventions.

When there are different variations of a certain component with the same name, we use the suffixes “-01” and up. For example:

• Form-Elements / Search-Field-01 / Default
• Navigation / Search-Field-02 / Default

8. STRUCTURING THE NAME OF A SYMBOL

To maintain a clean symbol list, we always structure our symbols in the same way. To do this, we divide our symbol name in levels:

1. Component Group (if necessary): Form elements, Buttons, …
2. Component: Text field, Checkbox list, Primary button, Secondary button, Snackbar, …
3. State: Default, Hover, Clicked/Pressed, Disabled, Success, Warning, Error, …

Some examples:

9. BREAKPOINTS

As we all know, some components need a ‘different’ design for a different breakpoint. The most common example is a navigation bar. But because not all components need to be enhanced for all breakpoints, we nest all symbols/components for a specific breakpoint in a group named after that breakpoint.

We divide the breakpoints in five categories:

• _XL = Extra large
• _LG = Large
• _MD = Medium
• _SM = Small
• _XS = Extra small

For example, symbols of a navigation drawer for different breakpoints could be:

• Navigation-Drawer / Default / _XL
• Navigation-Drawer / Default / _MD
• Navigation-Drawer / Default / _XS
• …

10. TEMPLATE SYMBOLS AND COLOURS

All symbols that are designer tools, like status bars, browser url bars, keyboards, colour overlays etc., should be grouped in ⚡️.

For example:

• ⚡️ / browser / …
• ⚡️/ cursors / …
• ⚡️/ spacings /…
• …

We use the ⚡️ emoji for this group so it always appears on the bottom of our symbol list.

If you want to learn more about the way we handle our spacings with Anima and our own Spacer plugin, you can read about it here.

11. POSITIONING SYMBOLS

We want to make sure we position our symbols neatly on the symbols page of our Sketch file. We group them visually by component or component group and place a title above every group of symbols to keep things organised.

You could do this manually, or let the Symbol Organizer plugin do it for you.

AND THAT’S IT!

Well, not really :-) We’re always trying to up our game! These guidelines are just one of many things we do to make our UI design process more efficient and to enable our team to focus on more product-specific problems.

If this was helpful for you or have any thoughts: Holla at us! 👏👏👏
or share the article, so your friends can benefit from it too.

Curious for more insights on our way of working?

Check out our blog on “a better process for design reviews” too.