(More) Tips for Building Your Sketch UI Library

An example of how one of our simpler views breaks down into shared, reusable components

I recently read this excellent article by Hudl on their tips for building usable Sketch Libraries — and was relieved to find that I’d been following a similar path in creating our UI Libraries over at Help Scout. So for those of you deep in the trenches, I wanted to share a couple of additional things that have made my life immeasurably easier when creating and maintaining our shared components.

But first, read Hudl’s article. I’ll wait.


Embrace “nested” Libraries

Whilst it’s a conceptual nightmare, nested Libraries (as popularised by Pablo Stanley) are a godsend. Hudl detail how you can use them to share colors for masks, which I would strongly suggest building into your own Libraries— this is our primary usage. But in addition to color, you might consider also putting generic icons, OSX elements (radios, dropdowns etc), avatars and regularly-used building-block components (see Guides, below) into a nested Library.

Whilst there’s definitely a bit of extra work required in creating scalable, re-sizable, well-named Symbols — it’s worth it. When your team are all using the same avatars and colors across the board to create pixel-perfect UI, you don’t just get the benefit of maintainability, but also the beauty of consistent screenshots and PR images, too.

The rule of thumb for me is that if I ever use anything more than once, I’ll make it a shared element.

A few of the faces available in our common UI Library. Team (left) and Customers (right)

At a macro level, I strongly recommend naming building block elements, like color, prefixed the with ↳ symbol. This makes dealing with the Overrides panel so much easier further down the line, especially with larger more complex Symbols.

Nod to Bradley for this tip

Padding and guides as Symbols

Hudl’s ‘spacing block’ is a great idea — which we take one step further in our more generic Symbols with padding and guides. These operate as visual aids to help designers know how to align and resize Symbols, and can additionally be used to signal measurements to developers.

Of course, these guides are also Symbols — so they can be turned on and off in the Overrides panel, and are also named using the same convention as colors (above) to make it clear which parent object they belong to.

Example usage guides

Interestingly if you copy a Symbol from a Library file and paste it into a new document — that Symbol will be duplicated into your new file rather than remain linked to the Library. This small, but pretty significant quirk can be the difference between your team effectively using shared Library components, and everything falling apart into a mess of duplicated Symbols after a couple of months.

The Example usage file for our Beacon components

So as an effective workaround, we put an Example Usage.sketch file next to the main Library, and use that as an area to document specific patterns and common usages. Better still, when anyone copy/pastes from that example file, the Symbols will remain linked. It’s also a nice proof-of-concept to be sure your Symbols are as generic and usable as possible.

There shouldn’t be a single Symbol in your Library (with the exception of Base components) that aren’t represented by example usage.

As a final touch, we also export all Example Usage Artboards into a folder, which also sits alongside the Library. This serves as an up-to-date reference of the UI for anyone who doesn’t have Sketch installed (or just wants a quick peek) and is used for documentation, below.

Version control & documentation

It’s important that your Library remains the single source of truth, even for those who don’t have Sketch — this is where GitHub comes in handy. We pull the master Library, Example Usage.sketch and all exported example images (above) into a team GIT repository and update it when necessary. Not only is this good practice from a versioning standpoint, GitHub also comes with Wiki’s — which we use to store up-to-date documentation.

GitHub has been a real timesaver for up-to-date documentation

In GitHub we create a bunch of Wiki pages that reference the raw image files, produced from the example usage flow from before. This is incredibly handy because any time a new export is pushed, the Wiki automatically shows the latest version of the file — no caching, updating of stale image files or off-site documentation! Just make sure you reference the image like below:

![Example Usage](https://github.com/.../blob/master/Examples/Forms.png?raw=true)

I also find it useful for the Pages in GitHub Wiki to match the same structure as pages in your Example Usage file — for ease of maintainability.

Smaller tips & tricks

I’m sure there are hundreds of tiny tricks and plugins that people use to keep their sanity, but here are a couple that I continue to find useful:

Multiple text layers

Quite often our Symbols contain two or more text layers to allow for different states, like a placeholder and input value that both have different attributes (like color and weight). In the Overrides panel, we simply put a space in the input that’s not needed. This, combined with nesting (like the State layer, below) allows for one Symbol to extend to multiple uses.

Type. Don’t bother

Sketch is horrible at typography. Like, Keynote bad. You may disagree, but I’m willing to die on this hill. So whilst it might help address obvious situations like the placeholder thing above, I don’t share type patterns (h1, paragraph etc) in any of my Libraries as they make scaling and overflow incredibly difficult to manage in nested Symbols. I’m only saying this so you don’t feel bad about skipping type too.

Library thumbnails

Even though it’s trivial, custom Library thumbnails are a nice touch. Just make sure the first Artboard of the first Page in your Library is 600x480.

Yeah, our Beacon library is called Blue

Finally, keep it simple!

For me, creating Symbols is like coding. Everything makes perfect sense when you’re in-the moment smashing out code… but without careful consideration up-front, everything can quickly become very complex after even a brief period away from the codebase. The same applies to Libraries — so the key to success is to keep it simple.

This means being extra mindful not to over-complicate your Libraries with Plugins, weird naming conventions or by hacking/leveraging Sketch quirks. I can’t stress this enough. Not only will it over-complicate matters and make collaborative usage difficult (Libraries need to be easy for anyone to pick up and use effectively), but there may also come a time when you might want to move away from Sketch.

If the key to successfully using your Library is locked away in your head, or requires some kind of on-boarding, setup or installation process — you need to work harder at simplification.


Want to see all this in action? Head to Help Scout and drop your digits in the form — you’re going to love it. Alternatively you’re building out UI Libraries and have tips and tricks of your own, I’d love to hear from you!