JournalContactMenu

Creating a Sketch file organization system

Alice threw this one into the void on
March 15, 2019
In an effort to improve our team's workflow for web projects, I've taken a deep dive into the realm of file-hygiene. My goal is to create a system that allows our design team to have more brain-space for actual designing (by reducing pixel pushing whenever possible), and, in turn, provide our development team a clean, thoroughly documented file that will eliminate any questions that start with “where is?”

Working messily

Naming conventions, building systems, and organizing stuff are all things I now find wildly exciting (at least digitally; I wish I could get as excited about my wardrobe). But the first time I used Sketch everything I made was an absolute mess. I sort of had a grasp on how symbols worked, like, just enough to barely make of use them, but not use them efficiently. But was okay, because I prefer to learn by doing. My lizard-brain likes to absorb new information quickly so it can and figure out how all the different parts work together, as a whole. I'd rather press all the buttons, mess up a lot, and seek help based on the task I'm trying to accomplish, rather than being told information I don't feel like I need at the time. Like, if I'm figuring out how to make a sparkle icon, I'm more likely to google “how to make a sparkle shape adobe illustrator” before I try “what do each of the distortion tools in adobe illustrator do”

As I was getting newly acquainted with Sketch, I was moving way too fast to even consider organizing all my symbols and artboards and pages. I was much more concerned about meeting deadlines than thinking about why I was naming stuff "tiles" or "cards". This length of the screenshot below should say it all... it's from one of my very first projects in Sketch:

a screenshot of all the disorganized symbols in one of my first, super messy, Sketch files
I really lived in apartments like this and didn't see any issue...

Total chaos, right? I was using underscores to separate words in a Symbol name, but other times I'd use dashes. Lots of Symbols had an alternate version of itself that was the "dark"  or "light", or also "active" or "inactive." Who even knows what "Exhibit timeline hard right grey" even means!? I was a danger to society.

All joking aside, actually, working this way was dangerous to my team: imagine if I had gotten sick in the middle of this project, and a co-worker had to take the wheel. Honestly, it might've been easier for them to start from scratch than try and sift through all this weird naming. And that's just the symbols! I also didn't have a system for how I used Pages, how I organized my artboards... I really don't think it's hyperbolic to say that if someone had to tap-in to take my place, it would have cost us thousands of dollars in time spent reverse engineering my messy file.

But you know what? We grow! We learn. As I completed more projects, still doing lots of growing and learning as I went, my “how do I...” google searches became less about production and more about process:

“How to build a flexible button system with symbols”

“Managing a color palette in Sketch”

“Handling typography in Sketch”

Even if what I was designing wasn't very complicated, I felt a need to explore all the capabilities of even the simplest symbols. Form inputs became my favorites. I covered every interactive state I could think of: error, disabled, active, focus, hover, hints...etc. even if it wasn't something that was being used in the prototype. By learning how to use Sketch as efficiently as possible, I was (for the first time) designing more comprehensive systems for interfaces and not just designing to the prototype demo that laid out the basics. I was making better decisions about color palettes, form (like shapes, not the thing you fill out), and layout, because I was forcing myself to pressure test the interface against more interactions and worst-case-scenarios.

However, it also dawned on me that just because I was having a moment of enlightenment, that didn't mean my workers were too. So the next time I handed a Sketch file over to our dev team, they'd be getting something very different than if anyone else had done the project. Developers have enough on their plates without worrying about how I set up my comps versus how another designer sets up theirs. It was very apparent that I needed to get other folks involved to get buy in on this organizational system before it could become standard. This also meant an ego check: before pitching the idea, I told myself, "Alice, you've been working completely in your own head up until now. This needs to work for everyone. It will change, and you gotta let that happen."

Pitching the idea

I met with our development lead to run him through my idea. He liked where it was going, and his suggestions gave me some great insight on how he and our other developers use a comp when they're creating cut up. Looking back, I feel silly not having asked "hey, what can I do to make cut-up easier for you?" sooner.

With buy-in and good direction from the development team the next step was to take it to the design team. It's worth noting I had to back this up with an argument of how we'd benefit, because what I was proposing was a big process-shift for our team. I don't take that lightly. Creatives can feel very personally tied to their way of working, and to ask someone to change that means there better be some big gains worth having.

My argument revolved around three main points:

  1. We have to respect our colleagues' time. If we all set up files the same way, we won't waste any time looking around for stuff or learning the quirks and weirdness of someone else's file set up.
  2. Changes are inevitable. Our organizational system should allow us to expand the design if and when that time comes (because it will).
  3. It'll make the designers think more like developers. Bridging that gap means fewer bumps in the road and more "flow." The designers will design better, and our developers can spend less time "getting acquainted" with a new file and diving right into writing the cut-up.

The Sketch organization system I designed

The short answer is that it's more or less based on Atomic Design principles. If you're unfamiliar with Atomic Design, Brad Frost's writing on this subject is an excellent place to start. If you'd prefer a visual representation, here's a diagram from Muzli.

My system takes those "atomic levels" and applies them to the way symbols are organized in any Sketch file. Atoms, however, are mostly omitted from the symbols because things like color and typography can be more efficiently handled as layer styles. Iconography and brand assets (patterns, logos...etc), though, those are Atoms within our symbol system.

Symbols

Working with the design team, we decided to operate under the following naming convention for all our symbols:

screen / atomic-level / object / 1 / 2 / 3

Here are a few examples of each atomic-level:

a gif of a sketch file that demonstrates my symbol system in use

Compare this gif to the one from earlier? It's a fraction of the height.

There's definitely some areas where this falls apart. Other folks also picked up on these pain points in atomic design. I found that for all the simple molecules that barely change between screens, there are just as many that need total visual overhauls. Small things, like buttons (a molecule) typically just size up and down, and that’s easy enough to account for in a static environment like Sketch. But imagine a big, complex ecosystem, like google calendar! All of those columns and events are completely fluid and flexible. That’s not to say you can’t design for it in Sketch, but your symbols can only be so flexible when you’re locked into using pixels instead of percentages.

Layers

Every layer gets a name. Period. And not a nonsense name either. Why? Let’s go back to our goal of “we have to respect our colleagues time.” Suppose I get sick and need to take a week off of work in the middle of designing comps. If I hand you that file, which of the following would be easier to work with:

Or

And look, I even used the super-well organized symbols! But as layers the symbol naming convention is actually not very helpful. A rough working solution I have in place right now is to rename the layer to whatever procedes the last forward slash in the symbol name. This meets the goal of having easy to read, and scannable layer names, and also is a way to vet how well we named the symbol in the first place. In the screenshot above, “3-organism/hero/LGP” probably needs a re-work, because a layer named “LGP” (in the context of that project) doesn’t make a ton of sense.

When layers are named and grouped accordingly, and sorted from top-to-bottom (with exceptions for visually overlapping elements that might need a special arrangement), it’s a win both for the designers and developers. It makes every single object and piece of text that much faster to find.

Artboards

Because we treat each Page in a Sketch file as a unique page on the website, there are only 3 categories an artboard can fall into:

  1. The “base” template
  2. Responsive breakpoints
  3. Interactive states

At minimum, every page will have one artboard as a “base.” This acts as the basic reference screen-instance that our developers use when they’re constructing that page. Beneath the base template there may be responsive breakpoints that demonstrate how the interface sizes up or down. Interactive states are mostly used for the InVision prototypes so we can show clients things like hover states, dropdowns, and other interactions.

Those three categories are organized in a strict visual fashion: a row of artboards demonstrates a “user flow” of some sort. All of the artboards in a row must be displaying the same device size (desktop with desktop, tablet with tablet...etc.) The flows are always specific to that page (like Shopping Cart).

The responsive breakpoints are organized vertically. If the design is mobile-first, then the mobile screen will be on top of the column, following by a tablet-size artboard, and then a desktop-size artboard. That column of artboards will be displaying the exact same information—no changes in content, only changes in layout. We use big headlines floating at the top of a group of a layout so our developers can zoom way out and still have good way-finding on the canvas.

Pages

Standard pages that exist for every document include the Symbols page, and a Style Guide page. The Style Guide is an organized collection of interface elements that our developers can reference

At first I used heart emojis instead of numbers, but our lead developer pointed out that that system wouldn't work for sites with more than 7 pages (sadly there are only so many colors of heart emoji). The numbers are a way to mark a “parent” page, and the ones with no number mean they’re a child of that parent page. The numbers also show developers the order in which the navigation should be arranged visually. This system works for us because the sites we typically build are for businesses marketing their services, and not webapps or social sites where the page order isn’t as important.

Gains, ferda!

With those four things (Layers, Symbols, Artboards, and Pages) organized, half the battle is won. A lot of what this comes down to is taxonomy: how should we name things, and why? It’s a really big question. Not only do you have to consider how most other folks name things (and why), but also what other names are being used? What are the outliers and why do they exist? How did those names come to be (have they always been that way, or have they changed over time) and why? That’s not to say I think designers need to write whole dissertations on why they’re calling something a “card” or “tile”, but I do believe we have an obligation to be intentional when we do so. Being curious about names (about anything!) is a great way to learn more. Up until recently, I didn’t realize that what I understood to be “tooltips” were actually called “popovers” in Bootstrap’s framework. And now that I know the difference, I can “talk better web” with our developers the next time we do a project using Bootstrap.

Something particularly strong about this organizational system is that it can work in tools beyond Sketch. The principles are basically the same, with some tweaks to terminology. In Figma, instead of the atomic levels being a part of each component’s name (components are Figma’s version of Symbols), you can place your components on artboards and name those artboards Atoms, Molecules, and Organisms instead. It’s the same system, just more visual.

Things that need sorting out still:

I’d love to say this is finished, but that’s not how systems work. Sketch and other tools will continue to update, and this system will have to adapt. My teammates and I will find ways to break this with every new project, and things will have to change to accommodate. To get ahead of some of those inevitable changes, I’m keeping a list of big questions to continually pressure-test the system against:

  1. How does this scale up to a larger brand that has multiple digital products and environments?
  2. Where does it stop? What doesn’t and what shouldn’t this organizational system do?
  3. This was created and tested with website projects in mind, but does it work for native app builds too?

Resources and references.

A lot of other people are doing very similar work, and because they published their thoughts and methods I was able to speed through a lot of the hard parts. These are the articles, authors, and teams that I leaned on to help make a system for me and my team: