Copied to clipboard
series
Series
Insights

Our symbols guidelines in Sketch

We defined an approach on how to set up and organise symbols. Making sure a designer could quickly and completely understand which components are used throughout a product, and how they behave.

17/7/2023
6
min read

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?” “Aaaaargh!”


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 is 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!


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.


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 1 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 check mark 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.


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.




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)


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.

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.


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


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..



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 5 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 / _M
  • Navigation-Drawer / Default / _XS

Template symbols and colours

All symbols that are designer tools, like status bars, browser url bars, keyboards, color 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.


And 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.


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!

Bert Hofmans

UI Designer

Bert Hofmans

UI Designer

17/7/2023
6
min read

We help companies
succeed in the digital age

Stay up-to-date with November Five

Follow us on LinkedIn for insights, learnings, use cases and more.

Looking for a partner that thinks beyond delivery?

We help companies
succeed in the digital age

Let’s get to know each other better and explore how we can help your business embark on a journey towards digitally enabled success.

CONTACT US
Series
DISCOVER MORE INSIGHTS
Chevron
About Fast Company’s ‘Best Workplace for Innovators’

November Five was named one of Fast Company’s global 100 Best Workplaces for Innovators in both 2020 and 2021. This annual list, developed in collaboration with Accenture, recognises and honors the top 100 businesses from different industries that inspire, support and promote innovation at all levels. For the consecutive year, November Five was the single Belgian workplace listed.

Fast Company is the world's leading progressive business media brand, with a unique editorial focus on innovation in technology, ethical economics, leadership, and design. Written for, by, and about the most progressive business leaders, Fast Company and FastCompany.com inspire readers and users to think beyond traditional boundaries, lead conversations and create the future of business.

Jeroen Van Winckel

Product Strategy Designer

Ralph Van Tongelen

Finance Director

Office

Office

Dario Prskalo

Associate to the executive team

Brecht Spileers

Chief of Staff & Director Corporate Strategy

Emily Stewart

Senior Content Writer

Rindert Dalstra

Brand & Marketing Director

Robin Van den Bergh

Managing Director at Appmiral

Maarten Raemdonck

Co-founder & Managing Director at Spencer

Phillip Vandervoort

Executive advisor - Strategy

Vincent Bruyneel

CFO & COO

David Du Pré

Executive advisor

Marc Wojciechowski

Assistant Director

Muriel Mwema

Director Product Management & Delivery

Nick Verbaendert

Co-Founder & Director Business Operations

David De Bels

Product Owner at Appmiral

Tom Vroemans

Co-founder & CEO

Veronique Verhees

Talent Manager

Jens Reynders

Engineer

Michiel Van Nueten

UI Designer

Samuel De Pooter

Engineer

Bert Hofmans

UI Designer

Stijn Symons

Director Architecture

Vincent Pauwels

Co-founder & Director Experience Design

Thomas Van Sundert

Co-founder & Director Engineering

Justin Mol

Director Client Partnerships

Leslie De Cuyper

Client Partner

Ruben Van den Bossche

Chief Operating Officer

Nikki Jacobs

Managing Director at The Market