Sketch Libraries play a crucial part in design collaboration workflows across teams of all sizes and shapes: they enable designers to share styles and symbols with their colleagues to avoid building the same thing over and over again, to speed up the whole design process, and make room for everyone to participate. What a huge win for all teams!

But with great power comes great responsibility: with library files, it's more important than ever to keep them up to-date and available to all collaborators on a project. That's where your team can benefit from using Versions to manage your project files and libraries — it's a missing connector that propagates your design changes to everyone on your team and thus removing the hassle of the error-prone process of manually updating designs and libraries.

Versions supports and empowers all kinds of design workflows. Below, you can find a Q&A section that contains answers to the most common questions about collaborating on libraries in Versions we received from the community.

If you still have trouble integrating Versions into your workflow — don't hesitate to drop us an email at versions@sympli.io and we'll be glad to figure it out together!

The same way you would do without Versions: open Preferences > Libraries in Sketch and use the "Add Library…" button.

Whether or not to put your library files in a separate project depends on your team’s existing workflows and preferences.

If you're into Design Systems, then it's a good idea to make your libraries shareable across all your projects (say, iOS and Android application mockups) — i.e. to create a separate project in Versions just for those libraries. This way you can coordinate library updates and make sure that all of your designs are consistent across the whole company.

But if you don't share components/styles between multiple projects (say, your iOS components are no good in Web mockups) then it probably makes sense to keep your designs and libraries together in the same project so they stay in sync even if you switch branches back and forth often.

The rule of thumb here is:

You should always update your design components (library symbols, styles, etc) in the "Main" branch of your project and then propagate them to other branches you might have via the "Pull from Main" option. This way you'll avoid potential merge conflicts during the final merge into "Main".

To illustrate this rule, let's assume you're working on "The Project" that uses components from "The Library". One of your colleagues prefers to commit their changes directly to "Main" while you have your own branch "WIP" (created off "Main" some time ago) that you’re going to eventually merge back into "Main" when you're done with your changes.

💡 The key here is that both branches are under active development at the same time.

While you both work in your respective branches, "The Library" gets updated and some of your components are now out of date with this library. You want to update them to match the latest library revision.

To avoid introducing potential merge conflicts in the future, here's how you'd do it:

Unfortunately, there’s no other option at the moment other than going through all of these conflicts one by one and resolving them using the most recent revision of the conflicting components. In general, both “Main” and “branch” revisions presented on the conflicts resolution screen should be the same but beware that in some cases they’ll differ (e.g. when one of the branches was updated multiple times while the other one was updated just once — so the components revisions don’t match).

It's always a good idea to see how your components fit into their context, especially if you're still playing around and making quick changes to a library.

Let's assume that you already have a components library and a design file that incorporates those components in a different project. Now you want to enter a "playground mode" and make changes to the library components to see how they look in the context of the actual design.

Here are your steps:

When dealing with designs and libraries in different projects, the major obstacle is synchronization overhead.

It's easy to overlook the problem when you only work in Main but as soon as you start branching out, you'll notice that keeping your library branch in sync with the design branch is a lot of brain work.

And if you don't pay enough attention to what's going on in your projects, you may end up in a situation where your Main design starts referencing components that only exist in your own private branch of the library project (and thus will be overwritten by your coworkers in the most unexpected way anytime soon).