Take Ownership of Your Design with Living Style Guides

Lots has been written about the value of style guides. I’ll assume you’ve read the whys and wherefores, so I’ll spare you the pitch. What I will tell you, is that at EventMobi, we’ve noticed significant improvements as a result of having a well defined style guide. Most notably: improved designer-to-developer communications.

Improved Designer-to-Developer Communications

In recent years, designers and developers have been flooded with tools to improve cross-functional communication. These tools attempt to take a lot of the manual work out of creating detailed, annotated design documents — the standard approach for delivering designs to developers. For example, InVision’s Inspect promises to help deliver pixel-perfect measurements and details to developers. It even generates CSS for you!

Although these tools often promise the world, they frequently fall short in these two areas:

• They focus entirely on making the designer’s job easier without any regard for the workload of the developer.
• They assume products are created as one-off pages, rather than being built from a series of reusable components.

Shifting Responsibilities

We’ve gradually observed a shift in the developer’s responsibilities from being solely focused on either frontend or backend development, to a more versatile full-stack role. The benefit is that the frontend and backend are developed in tandem and better complement each other. The downside is an expansion of what is expected of a single developer.

The challenge is that many full-stack developers are self-declared amateurs when it comes to CSS. In an effort to ease some of their responsibilities, at EventMobi our designers take full ownership of CSS. This ensures that the people whose day-to-day work is directly affected by CSS are the same people invested in CSS best practices.

Designers’ ownership of CSS gives us a number of additional advantages:

• There is no design hand-off. This eliminates a lot of wasted communication and lost productivity.
• Designers have full control of every pixel in the final product. They can make adjustments without any developer involvement.
• Since our designers must now think in terms of components, this helps reinforce our process and aids in communication with developers who are already building products with components.

Building Products Like Lego

Our style guide is built using the principles of atomic design. Instead of designing individual pages, our designers work with smaller pieces of UI referred to as components. You can think of components as individual Lego blocks, each one reusable and designed for a specific task. These components can be combined in various combinations to create an infinite number of pages. Components allow our designers to discuss a design in terms of the building blocks used.

As a result, our designer-developer conversations are more focused on product and the value it’s delivering to customers, rather than the time-consuming discussions around padding or font sizes.

By placing ownership of CSS with designers we ensure consistency of the components that are used during the design phase. Plus, developers no longer have to interpret a designer’s intent.

Flipping Style Guide Ownership

A style guide’s relevance is directly proportional to the amount of attention it receives. A guide in disrepair quickly becomes a neglected guide. Neglect leads to a feeling of indifference, allowing exceptions to be introduced without receiving the scrutiny they require to keep the style guide useful. In such cases, a style guide may even be abandoned completely.

In the early days of style guides you might have maintained two separate sets of CSS code: one for production and a second for the style guide. Syncing the two was a nightmare. As the need for style guides became more apparent and accepted, tools emerged to help manage the process and even automatically generate style guides from production code. With this approach, developers own the style guide, which is the opposite of what we want.

Our solution is to flip the ownership. Our style guide code becomes our production code. The CSS written for our style guide is published to a private NPM package and included as a dependency in our development environments. This completely eliminates duplicated work and it properly aligns the ownership of elements. Designers own the patterns. Developers own the functionality. In order for a change or new component to make it to production, our designers must update the style guide.

It also has the added benefit of allowing us to reuse the patterns in multiple projects. For example, our internal tools team uses the same set of components and styles for some of our developer tools because it is easy for them to simply include the NPM package as a dependency. It’s a win-win for everyone involved.

Ownership and Maintenance

Style guides offer design teams numerous advantages like consistency and cohesion. To thrive, though, dedicated resources are required. By adjusting how we approach style guides, we can lessen the maintenance workload and get maximum value from style guides in the designer-to-developer handoff.