Sketch Symbol best practices

Lloyd Humphreys
5 min readAug 15, 2016

Symbols got a big upgrade in Sketch 39. They’re a lot more powerful than they used to be, and we’re all trying to figure out how best to use them.

There’s an updated version of this guide available:

At Tradeshift, we’re beginning to maintain a central Sketch document with all our symbols. In order to be added to this document, a Symbol needs to pass a few quality and consistency checks. Everyone designing for us will make use of this document, so we don’t want to be distributing anything but the best Symbols of our common UI components. Symbols should behave in similar ways, be small enough to be modular, be large enough to be useful, and be organised well for easy editing (or embedding in a document when detached).

Hopefully you’ll find my ideas for creating good quality Symbols useful, but this is definitely a living document and I’ll be updating it as we inevitably find better ways to do more complex things. I’m not entirely certain this is the perfect approach, but I’d like to start a conversation around Symbol quality.

Create the most basic components

Ideally, you shouldn’t be detaching Symbols often, because that defeats the purpose. Create the most basic version of a component, individual Symbols that you can combine later to create a more maintainable whole.

For example: at Tradeshift we have an icon-tab that looks like this, but you can see our component allows you to place an icon on top, outside the Symbol, which then allows you to easily toggle the Tab into Active/Inactive modes without having to detach or create too many variants of what is essentially the same Symbol.

Establish a naming convention

Name your layers appropriately. We try and stick to all lower case, separated by dashes. Sketch automatically organises Symbols into folders when you put a / in the name.

I recommend a control/definingproperty-state naming convention. Default states shouldn’t have a state — tab-inactive and tab-active is redundant. tab, tab-active is the way to go.

Example:

  • button/color-mouseover
  • tab/icon-active

Pete Lacey made a good point that names shouldn’t be too tightly tied to their physical attributes , since they’re likely to evolve. For us, we’re quite strictly green and blue, so it really is their defining property. But perhaps primary, secondary etc. would be more appropriate.

When using Sketch Runner, establishing a naming convention means you’ll always be able to quickly find what you’re looking for because there’s an organisational pattern to conform to.

Nobody likes to inherit a poorly organised Sketch file in general, so let’s not distribute poorly organised Symbols.

Use generic text

Give the layers generic placeholder text — not just the text you were using in the specific use case you had when you created this Symbol. Our placeholder text for buttons is “ACTION INTENT” as a passive reminder of how you should phrase your microcopy.

Give layers appropriate names

Give the layers themselves appropriate and consistent names. Backgrounds should always be called background and not mixed up with bg etc. Curse you if you leave it namedRectangle 100! If you detach the Symbol, it should remain a tidy and self-contained object.

Text is especially important. Ensure that Symbols you’ll regularly replace (i.e. with similar Symbols of different states) have the same Text Layer Names. You can edit text within a Symbol in the overrides editor — if you replace the Symbol, it will persist the text in the new Symbol if it shares the same Text Layer Name. It also shows the name of the Text layer, not the content, as the field identifier.

Implement a clean & consistent hierarchy

Put any editable text on top.

Group tidily, and make sure there are no extra groups or elements which serve no purpose (which can happen if you paste in an icon etc).

Symbols will be reused, detached and remixed — they should be really well organised, so anyone can quickly understand what’s going on when they look under the hood.

Ensure Symbols resize correctly

Play with your Symbols, test them and try to break them. You should aim to build something bulletproof. An extra few minutes of your time to perfect the Symbol will save headaches down the road, and make designers who have to maintain your Sketch files & Symbols happy.

Check out Peter Nowell’s Resize Cheat Sheet

Text should be fixed

Text should be fixed, and aligned correctly, so that when you resize a symbol it maintains its position & padding properly. Text should have a “Resize Object” resizing property.

Design the smallest version of a Symbol

It’s easier to design around stretching Symbols than compressing them.

For us, we want tab to have a minimum width of 99px, no matter what the text is. So the smallest version of tab is 99px wide, and we know to not make it any smaller.

Ensure Symbols you’ll be replacing have the same artboard size

Sketch will replace one Symbol with another, and compress/stretch the Symbol to fit into the same size. Perhaps this is intentional, perhaps it’s a bug — but ultimately, you should try and make Symbols you’ll regularly interchange the same size. If it does stretch them out, you can use right-click-> Set to Original Size to fix it.

Hit me with ideas and feedback! I’m not entirely certain this is the perfect approach, but I’d like to start a conversation around Symbol quality.

--

--