Speeding up Design execution while keeping consistency. Creating a Symbol Library
One of the most gratifying projects that I have made at CEMEX was the creation of a Sketch symbol library. A unique reference for creating visual compositions.
The fundamental problem we were having that triggered the creation of it was that the team members were copy/pasting from the Master Style Guide PDF and modifying those elements to adapt to the requirements of the current deliverable.
This was inefficient for many reasons, but mostly because there were many versions of those files going around the office and there was no centralized way of having them updated.
Our system had to evolve or we would fail in the intent of creating a coherent visual framework for our software products.
Atoms, molecules, organisms, complex beings.
Atomic design proved to be very efficient at building the Sketch library. It’s the adequate compositional technique for creating such tool. Translated to plain Sketch words, it’s about creating symbols with other symbols that are created with symbols. And for those that don’t know what symbols are, it’s just a visual element that when changed, it changes everywhere you have applied it.
Atomic also happens to be quite similar to the compositional structure of actual software components, so it opens the designers eyes to the intricacies of how the real thing is built by using modern front end frameworks.
You start by creating the atoms, or the very basic compositional elements of a design, in our case it’s the color swatches, the diverse shadows of components, some referential pictures and the basic shapes used in the symbols.
Then the molecules that are just a combination of the prior, for example a card uses a swatch atom for the color, a shape atom used as a mask for the rounded corner rectangle and a shadow atom for the drop shadow effect.
Then the organisms, as for example combining the card molecule, with an avatar molecule and Text to identify a person.
You can now understand how this goes on, it is self explanatory.
Once we deployed the library and all of the team’s comps were using it, the benefits rose to the surface pretty quick. Being able to centralize the correction of UI elements is a very powerful tool, edit once, publish the changes to a repo and all of the peers connected to it will receive the change, which will propagate to their comps automagically.
A really good use case for us was to modify one color of the library to make it AA in contrast ratio for accessibility. It was as easy to modify the swatch in the library, which is stored in a OneDrive folder (Dropbox, Google Drive would do the same) and all of the peers connected to that OneDrive folder got the updates instantly and their comps prompted to incorporate the change as soon as they opened any file that used the library. That shade of green is now compliant in every comp that the library has ever touched.
If Atomic is the perfect compositional method, it proved not to be so efficient as a presentational schema. One thing we did at the first iterations of the library was to structure the symbol tree within the library also in atomic fashion. This meant that we had 4 subgroups, atoms, molecules, organisms and complex beings, from which the one that was mostly used was the organisms, nesting the vast majority of components. This proved to be a bad decision, as the symbols are also held within nested drop-downs in the Sketch UI, making it more difficult to pick a component.
We fixed it early on by storing all of the component symbols at root level, and have subs for atoms and molecules.
With great power comes great responsibility.
This has also proven to be true in our case, cause depending on a library forces you to work in a very specific way.
It is not a bad thing to ask everybody to use the library to create comps, after all, this is not something we invented, tech giants use these methods too. The thing is that for smaller companies (or big companies with small design departments) there might be time and money to do this once and do it right. This has constrained us to stick with Sketch as our only compositional tool. Even if we would love to join the Figma bandwagon or use another software, the outlook of creating a new library sends us back home with Sketch. So, if you are in the need of developing one of your own, bear in mind that you’ll stick to it for a few good years, and that designers’ impulse to hop on the latest and trendiest tool is going to be squashed before it takes shape.
Another consequence of standardizing your visuals is that the evolution of the design language will be much slower, and it will take the shape of steady growth instead of total revamp. This will make some of the designers bored pretty quickly, as it is normal that some are looking forward to introducing novel pieces that may not fit right in with the rest of the components.
What about mobile?
Mobile is another thing we learned a lesson from. We developed at first a library for desktop, and then a library for mobile. Since everybody had the desktop one installed and only a few had the mobile one we thought it was a good idea for the mobile one to have a dependency on the desktop one, so that it could consume the same set of atoms. Having them separated turned out to be a bad idea, because now you had to have two libraries in sync, most likely the desktop one was going to be edited first, and then later on the mobile one. We ended up creating one library, and each component has a “Mobile” sub that holds the specific symbols should there be one.
All in all is about saving resources.
And this is of course the biggest gain of having your UI library well set, you will save a lot of time, and you will save a lot of money. Things become predictable, and your product teams will start revolving around the library in order to create new stuff. This will generate confidence and your end users will feel right at home when using your products, as they will feel part of a suite. Later on the developers will think of creating a library of their own to mimic yours and everybody will start to speak the same language, which in big organizations is nothing but good news.
