A step-to-step guide to making the most of Sketch, and how I used it to drastically increase my team's efficiency

When you work solo in a startup as a graphic designer, you don’t necessarily need a framework.

But hopefully, one day, your startup will grow. You’ll build up the team, you’ll bring in a Product Manager, Team Lead Front, Marketing Manager, and your freewheeling design days will have to go.

Then, like in any group setting, you’ll absolutely need guidelines – including a framework – to maintain uniformity across your designs.

This is what happened at CALLR. I had to swap my convoluted system of Photoshop + Illustrator + Marvel + Avocode, to something that would let multiple people quickly refer to the same designs, be on the same page and advance at the same rate.

In this post, I’ll explain why and how we revamped our design process, including our choice of switching to a high-element low-state way of using nested symbols in Sketch.

Going from a 4-app system to Sketch + Invision

When I was working as a one-man show, I would switch between Photoshop for the UX designs, and Illustrator for everything vector (logos, icons…). This already meant shifting between software on a pretty frequent basis.

Then, once I felt everything was done, I’d push it all to Marvel for interactive designs. I’d show the CEO and CTO, get their feedback and validation. Then, the final step was pushing all this to Avocode, so that the designs were exploitable for the front-end developer team to build.

While this worked fine in the beginning, the problem was that this was too cumbersome of a process to be sustainable as the company grew.

For example, if someone wanted to make a small adjustment to an icon, that icon had to be updated on all the files everywhere on all these software. That was painstaking and time-consuming. We also couldn’t store all elements of a design in one place – Photoshop files were in our Dropbox, but icons where somewhere else… It meant juggling between a few ‘most recent’ updated files, remembering if we were on version 5 or 6, rummaging through a bunch of different Dropbox folders…basically, it wasn’t efficient.

When it was just me, it didn’t matter so much (I thought) if my process was a bit of a mess. But, just like when you go from living alone to getting a flatmate, you realize that your messy ways disrupt other people – and when you finally get organized, you realize you prefer your cleaner self. At least, that’s what happened to me.

When we realized our design process was getting out of hand, our Product Manager and myself went looking for solutions.

What we found really appealing about Sketch was that:

Both Photoshop and Illustrator functions are available in Sketch. That means both UX design and vector work can be done in one interface, which was already a big simplification regarding how I was doing things before. If you use an add-on by Invision, you can also build interactive designs directly in Sketch, and then push to Invision to share the design with the developers – so I don’t EVER have to leave Sketch, whereas before I had to have 4 different apps to get this done.

Making the shift from a 4-app system to just Sketch plus an add-on cut down on a lot of busywork. It was much easier for the entire team to stay organized and on-task. However, it also opened up new organizational questions that were particular to Sketch – namely, how to use nested symbols.

Nested symbols: fewer elements is not always better

You’re probably already familiar with symbols in Sketch, but just in case, I’ll use the words of mobile UX designer Javier Cuello to sum up their interest:

The best thing about using symbols (instead of grouped, independent and disconnected objects) is that if at some point you decide to change some property in a particular symbol (for example, the color, shape, text size, dimensions or whatever else you want), you’ll just need to edit the symbol’s master once, and this change will be automatically replicated to all of the master’s instances, wherever they are.”

Here’s the thing, though. There’s still many choices you have to make as a designer about how you actually create, organize and manage these symbols. For example, as Jon Moore explained on a popular Medium post, while the symbol page shown below is extremely common, it isn’t ideal. In his words,

If I want to add a green button, I’ll need three new symbols…one to cover each button state.

new symbols…one to cover each button state. If I want a white button with blue text, I’ll need three new symbols.

new symbols. If I want to get rid of the border on all of my buttons, I’ll need to update it on every button symbol I’ve created.”

Here’s Jon’s solution: only create one master button symbol with a gazillion nested elements to create any type of desired button.

By saving each element variation as a symbol within the master symbol, the idea is any time you need to insert a button into your user interface, you can choose the master symbol and then choose between a large variety of overrides to add the desired combination of states, as shown just below in the next section.

REMINDER: in order to use overrides in nested symbols, the symbols have to be exactly the same size, down to the pixel.

Override Overload

This technique was really hyped up. I was one of the designers who tried it out when I was working with our new Product Manager on updating our design process. We quickly realized, however, that with this technique, you save time during the initial design of the framework…but then you lose time later. It was two steps forward, one step back – the time I saved creating the framework was quickly lost once I got started on page design.

Basically, when you only use one master symbol for each design component, there’s no question you can create a new framework in no time. The problem comes when you’re building your individual pages: wading through dozens of different states and overrides to configure and insert each and every element was not only annoying, it was incredibly time-consuming.

This was because when you have every imaginable variation under the sun as an override for any given symbol, you have matches that don’t even fit into your framework. For example, you’d have the option to add a red button with yellow text, because you need the yellow text as an override for the green button, but it will come up for every single component you will add to your interface. This leaves you with a dizzying array of choices to pick through each time you add a component. For me, anyway, I was wasting a lot of time on this.

Finding a balance between symbols and states

It was so bad that we decided to rethink our strategy. After some back and forth, we came up with a balance.

There is only a finite amount of combinations for any given component in our framework –so we wanted to create enough master symbols for each component, and only allow them the overrides that would actually ever be used in our framework. This meant creating more symbols per component, but with fewer states for each:

As you can see in the gif below, after I’ve chosen which button I’m inserting, using nested symbol overrides is nice and simple. Redoing the framework only took a few days, and it drastically cut down on the time it took me to build pages.

Don’t always fall for the hype

If I learned anything from this experience, it was to be careful of hype. Sometimes, the ‘old-school’ way of doing things is still the best for your situation, especially if you tweak it a bit to suit your needs. Using the ‘one button’ method described in the beginning of this article, I was able to have a new framework up and running in two days…but it took 10 days to create the pages I was working on. This was way too long and not sustainable.

When we redid our process using the high-element low-state method, we did spend 1 additional day on building a framework, but we also cut our page design time down to 3 days. For us, this was enough pay off in terms of efficiency. Plus, now, adding, editing or deleting a component is a lot easier: there’s less interdependence, I can edit more precisely, and I can delete or edit a part of a component without breaking the whole system.

So whether you’re designing a website or app as part of a team, or even if you’re still working solo, I’d recommend these tools and this way of organizing your symbols. I hope you found this a useful read, and please feel free to reach out with thoughts, or other design tips or tricks.