Creating a Design System with Sketch and Jekyll

Design systems are a popular subject in the UXD community and for good reasons: they bring cohesion to the user experience across platforms and products. Building a design system is one my favorite practices as it requires cross discipline collaboration and teamwork to accomplish and has a great payoff.

What is a Design System?

A Design System is the living ecosystem of a products branding, interface design and engineering. They are more than a style guide, since they document and implement the code that makes the designs part of the software.  Visual designers, interaction designers, product managers and developers all play key roles in the defining the system.

There are great resources to reference companies’ design systems such as http://styleguides.io/ and different philosophies on organization such as http://atomicdesign.bradfrost.com/.

Business Benefits

Having a visual library speeds design time and creates consistency in concepts. This allow designers to focus more on creative problem solving and less time building deliverables. Creating redlines for developers is a time consuming process for both designers and developers.

For development, a designer system reduces requests for designs and CSS styles. We were getting requests for button styles or had developer grabbing whatever code they could find. This lead to a lot of redundant code in different product areas. A design system solves these problems by taking a single source for styles and standardized class names for elements. With these in place, development can focus on writing code and less on styling elements.

User Benefits

Having a unified design system creates a consistent experience throughout a platform, which reduces the learning curve of user’s journey through different tasks in the platform. For example, consistent styles for primary, secondary and tertiary buttons will inform the user of the hierarchy of functions on a page.  This continuity boosts user confidence as they move from task to task on different pages.

The Parts

Style Guide –  the visual guide to a brand including colors, typography and graphic styles for different element.

Pattern Library – the collection of user interface parts for an application, such as forms, card formats, navigational elements, buttons, and alerts.

Component library – there are different ways to deliver a design system through frameworks such as Angular and React.js, but the front end architecture will definitely have the HTML, CSS and javascript interactions to create the UI components in the browser or other environment. For web applications, standardized naming conventions for DOM elements are key to creating a maintainable and scalable system.

The Process

Inspiration

Before creating a design system, we did research into other successful design systems including a conference for the Red Hat’s design system patternfly.com and Mail Chimp’s pattern library. Airbnb wrote a great article about their process.

Design Audit

We were suffering from design debt: the result of UI design iterations by different designers over a period of time. Without a guiding force behind the designs, styles and layouts can drift leading to disparate UI elements throughout the platform.  Product areas were prioritized by high and low impact areas, and the product areas with the most impact were audited first.

We took screenshots of the different UI elements throughout the platform and collected them in different pages in a Sketch file. It served as our audit sketchbook. The extent of design debt was apparent as we collected the elements and provided a clear scope for the work ahead.

Front-end Audit

Redundant CSS created a technologic debt that thwarted maintainability and scalability as well as increased file sizes in every product area leading to slower page loading times. We took the same approach to tackling one product area at a time, since we had other projects going during this process and could not commit to an entire platform audit.

Decide on a naming convention

There are different naming patterns such as BEM and SMACSS. Both are good, your team will need to choose one and stick to it. We choose BEM and catered it to our needs.

Our ToolKit

Sketch + Invision
With the Craft toolset from Invision and Sketch’s industry adoption, the combination provided all the resources needed for creating a robust UI toolkit for the style guide and the pattern library.

Sass
Sass helps created modular and object oriented front end styles. We employed Sass maps for colors and leveraged the functions and mixins which make languages like Sass so much better than vanilla CSS.

Jekyll
Jekyll keeps website deployment simple since it compiles to static HTML, no database, and is backed by Git. Bootstrap’s site is powered by Jekyll as well other design systems we surveyed. We used Bootstrap 4 for front-end framework and paired it down to only the features we needed to keep it light weight.

 

The Result

Design Pattern Library

A visual library of styles and components lives in Sketch, which is hosted by Git. The Sketch files follow a semantic numbering system, which prevents different designers overwriting each others work. Part of the inspiration for that came from this article  by Mathieu Dutour. There are many tools in development for using Git and Sketch together, so we plan for a GUI to eventually lay seamlessly on top of the Git repository. Abstract has potential and is in alpha trials.

Git for Everything

For the moment, Git serves effectively as a shared drive for the files, but since HTML prototypes and the Jekyll site also live in the repository, it makes sense to have one source of truth. It also makes it very easy to see what other designers are working on. Since new designers might not be comfortable with command line, they can use SourceTree or another tool to help. Our Repo only has one branch, so only pulling and pushing keeps their workflow simple. The current designers are familiar HTML and CSS and have experience with Git, so adoption was not difficult.

 

 

MENU