Where is your Style Guide?

nolawi
5 min readMar 11, 2019

--

I build Style Guides.

My journey into UI Development is a not so unique, but one thing has been consistent through out. I design and build Style Guides.

I have been lucky enough to have been part of large engineering teams on rebrand or redesign efforts, including Software AG, GEICO, USA Today and National Geographic Society.

As a print designer I designed and built print Style Guides for test booklets in Pagemaker, then in QuarkXpress and then in InDesign.

Paul Rand’s IBM Graphic Standards Manual

As a Graphic Designer I was involved in rebranding campaigns and we did it through a Branding Guidelines which included both print and web as in most large organizations in the Web 2.0 era.

The Append-Only Stylesheet Problem

Even before the prevalence CSS Preprocessors, we implemented Style Guides through Global Style Sheets. In some cases Design teams maintained CSS files that would be shared across platforms via a single URL.

Many solutions spawned to account for mobile devices and solve browser compatibility issues. Combating caching issues by versioning CSS and Gracefully Degrading browsers we can’t fully support. Or supporting mobile browsers using tools like jQuery UI like we did at HomeSnap.

It became clear that our CSS was not our Style Guide. Internal web based Style Guides being built were missing lots of stuff.

There had to be a better way, and it was design system.

A design system isn’t only a collection of the assets and components you use to build a digital product in most Design Systems are really just Pattern Libraries: a big box of UI Lego pieces that can be assembled in near-infinite ways. All the pieces may be consistent, but that doesn’t mean the assembled results will be. Your product is more than just a pile of reusable UI elements. It has structure and meaning. It’s not a generic web page, it’s the embodiment of a system of concepts.. — Emmet Connolly

I couldn’t have said it any better.

At CollegeBoard, we built our Style Guide on top of Bootstrap. Base global CSS files was shared across teams and platforms with minimal issues. My first application in Bootstrap 1 is still up in a similar state as it was built 7 years ago.

http://horstmann.com/bigj/style.html

I dug in and fought for Bootstrap on every project, which ultimately saved UI Developers time on maintenance and instead focus on other things, like Contributing to open source Design Systems.

Lack of resources makes it impossible to maintain a Style Guide! I am sure you have heard that before. And its true, most UI / Full Stack developers do NOT have the luxury to build and maintain a one; features and bugs take the priority.

Long ago people figured out that it’s a good idea to devise some shared underlying rules when building a bunch of related things. And a case for Design Systems was made. Designers love them. As do Engineers in every industry.

Efforts

Most of us start with a existing application with a NOT so up to date Style Guide. UI developers find unmaintained Style Guide is only slightly better than none at all. Digging through deviations from scope, compounded by the number of supported devices, browsers and sizes was only slightly better than digging through Spaghetti Code.

With the prevalence of a Full Stack Environment and single page apps, UI Developers roles shifted and the Style Guide lost its evangelist and enforcer.

Methodologies Emerged

The Style Guide had to be incorporated in the development lifecycle. Colin O’Byrne talk about SDD, a term that was coined at Pivotal Labs. Every part of member of an engineering team has to contribute to it. Those you can’t code or design, should QA and write documentation and create and track issues.

As your Design Systems grow and mature with your project, the relies on UI Developers time decreases.

Atomic Design

http://atomicdesign.bradfrost.com/

An efficient methodology to design good applications could be breaking UIs down to their atomic (basic) elements, and working onward and upward from there. And Many Agree!

Atomic Design, and as the name itself says takes the fundamental, unbreakable components as the starting point when designing.

Your React or other Framework should render a state less pure single input component at the Atomic Level. Focusing on the ‘primary building units’ of design, regardless of the different screen sizes and device’s layout.

<button class="c-btn { btnClass }">{ btnText }</button>

Atoms together with molecules, organisms, templates and views, they form the five elements of atomic design. They can be divided into building blocks and containers (templates & views).

The key principle is to use the most basic elements to build up to the next level.

Now that you know you can Harness the Power of Atomic Design and build your Style Guide the right way.

You can start by picking one of these Awesome Design Systems, or carving some time for tech debt in focused on your Front End System. Front End coding paradigms and patterns as well as workflow should be integrated as best practices.

The full stack design system (by Emmet Connolly)

One-size-fits-all model has its dangers, and Material Design has its flaws and it might not fit with your Design+Developer Workflow.

Growth

Front End Developers should have the option to grow into Design Engineering, and/or Full Stack development. Design team if any should be involved in the hiring process of your next UI Developer candidates.

Tools I love

I build Style Guides using Atomic Design Principles in React and Pattern Lab.

--

--