Within the last few years, Sketch has taken the UI design industry by storm and has become the go-to design tool for many professionals. During that time, Bohemian (the team behind Sketch) has pumped out an incredible amount of updates, adding features, changing the way things used to work and fixing a dizzying pile of bugs.
Unfortunately, Sketch’s meteoric rise, combined with the constant updates has led every designer to develop their own ways of using Sketch picking up features differently and bedding it into an array of different workflows. There simply hasn’t been enough time for everyone to agree on what best practice looks like when it comes to Sketch, so people tend to evolve their own processes through practice, trial & error and reading online.
The result is a hot mess of varying practices that lead to inefficiencies, files that are only really understood by their creators and are hard to share due to similar modules having been built in incompatible ways. Should you use symbols for text styles or rely on using the built-in text styles functionality? What about object styles? Should you be using Sketch’s built-in resizing constraints, or use a plugin like Auto Layout to make your workflow more efficient? If yes, what happens when a new member of the team without the plugin installed tries to open your document? Or when one of the frequent Sketch updates breaks the plugin?
At RMA we got together to discuss some of the issues we encounter when working with Sketch, both as individual design professionals and as part of a design team. During a one hour discussion, we highlighted some core issues and proposed some initial ideas on how we could go about overcoming them. In no particular order, these issues were:
- Reusability of components / Single source of truth
- Communicating resizing constraints to devs for responsive designs
- Producing design specifications in an easily maintainable way
1. Reusability of components / Single source of truth
We’ve all been there. You are given a new requirement for a brand/app/website you’ve been working on, so you open up Sketch and get working. Before long, you need that primary CTA (or that masterhead, footer, dropdown or whatever) and you know you’ve designed it before. So what do you do? You open up the latest Sketch file you were working on for that client and simply copy-paste the CTA. In some cases, this this won’t cause any problems, but this action comes with a number of risks. Maybe the CTA you just copied from the previous document wasn’t quite correct, maybe it’s using an outdated colour or font, or maybe the guidelines have changed but you haven’t seen the new update for some reason. Then you realise you need a dropdown, a table and maybe a calendar widget, so you hunt for the documents you used all these before and paste them over to your working file. Occasionally you fail to find some of them in previous documents so you end up creating them from scratch based off the guidelines document.
If this sounds like a messy process, it’s because it is. There’s too much room for error, too many inefficiencies and too much repeated work. Enter Sketch Libraries.
The solution: Sketch Libraries
In Sketch 47, Bohemian has added a much needed feature to our favourite design tool: Libraries. These are essentially Sketch files full of symbols that can be used across different files. And believe me, Libraries are a much bigger deal than they sound. If there’s one common issue in all teams I’ve worked with, it’s this – the dream of having a single source of truth. Having all the guidelines, design components and all its pieces in a single document, accessible to all designers of the team. It promises to alleviate inconsistencies in design by ensuring everyone is using the latest components, speed up the design workflow by eliminating the need to re-create or hunt for the commonly used elements and allow the designer to focus on solving the problem rather than worry about being brand compliant.
A number of plugins and 3rd party apps offer to do this sort of thing already, but they tend to be clunky or break when a new update (yes, one of those again!) comes out. Now Sketch is offering a native solution that promises to take care of sharing symbols across documents.
Here’s how it works:
- Create a new Sketch file and put all the symbols for your brand in it. CTAs, form elements, icons, anything that you’ve turned into a symbol and can be reused in other designs.
- Use clever naming for your symbols to make using them a breeze. I suggest something along the lines of object/style/state so for example “button/primary/hover”. If you use forward slashes in the name, Sketch will automatically organise the symbols in folders. So, to follow our example, it will create a folder called “button”, with a subfolder called “primary” in it. If you create another button for a pressed state and name it “button/primary/pressed”, it will be placed in the same folder as the ‘hover’ button.
- Save your Sketch file with all its nicely named symbols
- Open Sketch preferences, go to the Libraries tab and click “add library”
- Find the file you just saved and add it as a Library
Congratulations! You have now imported a library in Sketch!
Every time you open Sketch now, you’ll have access to that library’s symbols. Also, because you were so careful with the naming, the symbols are nested in some nice and tidy fly-out menus, which means less time hunting for that symbol you need.
You can enhance this functionality even further if you put the library file on a shared drive (like dropbox, google drive etc) that your whole team can see. Now everyone has access to the library that contains the single source of truth. And you know what the best thing is? Every time a symbol is updated in the library file, anyone who has used that symbol in one of their files will get a little notification in Sketch, telling them what symbols have been updated and asking them if they want to push the update to their file and all instances of that symbol! Simple, efficient and works a dream.
2. Communicating resizing constraints to devs for responsive designs
This is such a common and frustrating issue. You spend hours on your design, making sure to cover all breakpoints for the responsive website you are working on and send all the specs to the developers. When it’s time to QA the implementation, you see that although the design looks great at the breakpoints you specified, it doesn’t behave the way you wanted it to in the resolutions between the breakpoints. Text wraps before it’s supposed to, buttons resize weirdly and icons jump around in the page.
How could something like this happen? Why couldn’t the front-end dev read your mind and implement exactly what you were thinking? That’s a silly question to be asking yourself, so a better one might be “how can I communicate this better to the developers?” Of course you aren’t going to produce hundreds of different designs for all possible resolutions, but fear not… there is a way…
Here is a neat approach to capturing how the design should work between breakpoints; courtesy of George Voke, one of our visual designers.
The solution: Sketch resizing constraints (and a bit of QuickTime)
- Use Sketch’s resizing constraints to define how elements should behave when resized. You can let elements resize proportionally to their parent, pin them to one of the 4 edges (top, bottom, left, right), fix their width or height, or use any combination of these.
- Ensure your module behaves exactly how you want it to when resizing it.
- Record a video of you resizing that module inside Sketch using QuickTime, showing exactly what is pinned where, when does text wrap, what scales proportionally etc.
- Share the short video with the devs and walk them through it
Now the developers have a visual artefact they can refer back to and check their implementation against, while the designer was forced to think more about how the design behaves.
Importantly, using this technique also makes you think more deeply about how your design will behave when implemented. This is because the way that resizing constraints are applied in Sketch, starting from the lowest layer in the hierarchy and defining how it resizes in relation to its parent group, then how that group resizes in relation with its parent group, and so on, is very similar to how front-end developers define divs and resizing constraints in the implementation (unless, of course, they are using CSS Grid – but then that’s probably another blog post 😉). This means the designer has to think more like a developer and consider how their design behaves across a large number of resolutions rather than simply producing a polished PNG of two or three breakpoints and calling it a day.
3. Producing design specification in an easily maintainable way
The last issue we discussed was that of specs. Especially for UX specs, shifting from Axure to Sketch came with a few compromises. Whereas in Axure you could show how a component should behave by using dynamic panels with different states, logic and even animations, in Sketch you are confined to a flat design with no interactivity or logic. Sure, you can use Marvel or InVision to make a clickable prototype, but this is simply stringing a series of screens together and offers none of the complexity and functionality that Axure does.
What we end up doing is designing every single state of a component, export them as PNGs and use something like inDesign or Omnigraffle to produce a spec document with annotations that detail how each component works. In doing that, we tend to go back and forth between Sketch and inDesign when something needs to change in the design. Edit, export again, import in inDesign, export PDF once more. Sometimes we re-use an exported PNG in multiple pages in that documentation, so we need to make sure we aren’t forgetting any outdated ones. This whole process is quite messy and time-consuming, so we tried to come up with a better alternative.
One suggestion was to do the documentation inside Sketch instead of using other software. Sure, we’d lose some document editing features, like auto-generating a table of contents or a page count, but we gain something powerful: symbols. Now instead of exporting a PNG, we can create a symbol of a component or an entire page. With nested symbols, we can quickly create all the variations of that component as instances of the symbol. If we need to make a quick change, we just need to update the parent symbol and all the instances will magically update too.
This approach needs to be tested more before we can recommend adopting it as a standard practice, but it does show some potential for saving time and effort.
It’s great to see Sketch addressing a lot of the issues and adding some highly requested features to their product. These new additions and fixes have the potential to make our jobs as designers a lot easier, by reducing overhead, increasing collaboration and simplifying workflows. Improvements like the addition of libraries and resizing constraints, can drastically reduce the time we spend on mundane tasks, like ensuring we are using the latest style of a component. And the less time we spend on these kind of tasks, the more we can focus on designing great experiences.