Bridging Sketch and Style Guides: Designers and Developers Can Play Nice
As more digital designers embrace Bohemian Coding’s Sketch, new doors have opened for creating and maintaining style guides. Making the switch from Adobe Illustrator to Sketch can be an easy transition with considerable benefits for speed and process. I won’t go on about how great Sketch is–you can decide that for yourself. Instead, I’ll simply share some thoughts around style guides and ways I’ve used Sketch to help construct them.
What is a Style Guide?
They come in many shapes and sizes, but they all have a core purpose – maintain consistency with a product’s design language. When done well, they can keep teams of designers and developers working together like pretzels and beer. Ok, maybe not that good, but we’re all in this together right?
Rather than getting caught up in the difference between style guides, brand guides and front-end frameworks, let’s consider a style guide to be an organized collection of visual assets and interaction patterns. These collections typically live online and guide the application of both design and development.
There is a lot of documentation on the philosophy of a style guide. I happen to be a big fan the atomic-design-concept folks, like Brad Frost speak about. Atomic design is a methodology for creating design systems as opposed to a piecemeal collection of design elements. In short, the UI is broken down to its smallest pieces (atoms) and systematically built up into molecules, organisms, templates and finally, pages. While these metaphors may seem abstract, they are part of a digital ecosystem (hooray metaphors!) for users to navigate.
Designers use the style guide patterns as building blocks for their design concepts. They can be reused and applied as a product’s design vocabulary. When designers use consistent patterns, it reinforces the end user’s decision-making throughout their experience.
Code-based design patterns then help developers to implement the same code base for each applied instance. Some developers are getting very slick with this process and creating what is known as a component API. They essentially decouple the User Interface code from the application and utilize it externally via the API.
This all sounds great so far, right? If you work in an agile software development environment, you may have felt the growing pains that come along with shaping a product. Whether you are building it from the ground up, or trying to inject functionality into an existing product, the goal is to mitigate friction in the overall user experience.
As more designers and developers contribute to the rapidly changing goals, the need for a living style guide that grows with the product becomes clear. Without it, a team may find themselves creating Frankenstein.
Maintaining a “living” document brings with it the implication that someone somehow will keep it up to date. This requires resources that are not always easy to allocate. When there is a new addition for a style guide, how do you document and ensure it is implemented the next time it needs to come into play?
Now what if your organization is only responsible for the design and not the development? Or vice versa? While it’s ideal to have both design and development done by the same entity, these scenarios happen. When multiple parties are involved, it’s even more crucial for them to embrace this sacred document.
In cases where designers and developers are not working closely, I suggest two forms of a style guide. The first is what I call the design guide. This would be the Sketch file that each design comp is created from. It contains all the UI elements as symbols and art boards with preconfigured grids for the targeted platform(s). Once the new comps are finalized, they may introduce some updates to the symbol library. This document can be copied, artwork removed, and saved as a new mother style guide for designers to work from. A change log is also helpful in maintaining updates.
This design style guide and change log then gets implemented into the development guide. The development guide will have code snippets tied to each asset for reference. This guide would live online and be easily accessible. With a good change log, developers would spend less time scratching their heads saying, “What’s new?” before each sprint. Hint: The development guide is also a nice place to have a download link for the current design guide.
Sketch To Save The Day (Sort Of)
Sketch has some tools and plugins that I have found helpful in the process of designing and maintaining style guides. One way we help our design teams stay on track is by using templates with preconfigured symbols and styles.
Symbols and shared styles are two very useful features in maintaining templates for mid-high fidelity design work. They help User Experience (UX) designers rapidly create wireframes by simply dragging and dropping components from their symbol library. They are equally helpful for visual designers as they fine tune creative elements and apply changes across all instances of a symbol - all while keeping teams in sync.
A very intriguing plugin for bridging design and development is Zeplin. It takes designer’s work and reflects the document’s color palette, type hierarchy, and other assets. For developers, it renders code snippets of CSS, Objective-C, Java (and more). It even provides asset dimensions and coordinates. The agile design process can light your hair on fire, so it’s easy to see how this form of documentation can help designers and developers coordinate. However, it does not add as much value when developers are not using Sketch or if development is detached from the design process. Another nifty plugin is called Sketch Style Inventory. This plugin will actually create another page in your document called Style Inventory, documenting things like colors, text styles and symbols. It can even export metadata and images from your document that can be handed off to development. It exports colors as JSON, symbols as PNG, text styles as JSON.
I would like to see a plugin that exports a linked symbol library–similar to what I used to do with Adobe Illustrator. With Illustrator, you can create a mother document with each asset on its own artboard. In a new document, use the place function. Check the link and show import options, then select the artwork you want to place. You can create a seemingly infinite amount of documents with the mother document’s artwork placed (linked) within.
Every time you update the mother document artwork, the changes will apply throughout these child documents. It’s almost as cool as CSS–almost.
There are always going to be different situations where designers, developers and even clients need to coordinate a style guide. The goal will continue to revolve around coordinating visual and interactive elements with intense production schedules. Closing the gaps between these parties will result accurate product execution and ultimately delight the users we work so hard for.