I love design systems (aka styleguides).

atomic design

Combined with the idea of atomic design, they make a lot of sense. Unfortunately they’re hard to do right and keep up to date, especially in small projects.

Patternlab.io is a great base for an online styleguide. However, I feel it lacks a key thing to be a “living styleguide”: integrate into developers workflow.

I believe once a component has been described, integrated and tested it should become easy to re-use and update, across the whole application.

Web Components are great, but won’t help you much to integrate your components into a Wordpress (or the majority of CMS for that matter). In the end, you usually end-up with at least 3 versions:

Needless to say that these will quickly be out of sync.

What I have in mind

Update: now on Github: https://github.com/lipsumar/design-system-framework

I want to have an actual “single source of truth” for components. That means a single template and not 3. Changing only 1 file would update the component everywhere it’s used in the application and the styleguide.

This single source would also allow to have a much better view on the project: since everything has a single source and is managed by a tool, we can easily know where it is used and how.

Here are some key points I have in mind:

Separate sources

--+ MyComponent/
  +-- html/
  +-- css/
  +-- js/
  +-- config.json

Each component has its own directory (simplified)

This allows to think about components in a truly modular way, were they can all exist independantly. Using the styleguide as a dev tool guaranties a module is not tightly coupled to another one.

The styleguide is the dev tool

The styleguide website is the place were designers and developers actually work on HTML/CSS and javascript. It lives online for documentation and locally for development.

It takes care of compiling SASS, ES6, Handlebars/Mustache, etc… watching files and understanding dependencies to re-build everything that needs to and refresh the browser.

You can think of the styleguide as a workbench, test suite and documentation.

The source is a template

Using a template with variables as a source instead of static hard-coded HTML allows to never put arbitrary data in HTML.

<div class="MyComponent__name">John Doe</div>

Seems familiar?

Lorem ipsum data is usually perfectly short and components break as soon as real data flows into them. Using only templates and variables means no hard-coded data: the tool can inject different mock data to make sure they hold up.

Back-end agnostic

By choosing a logic-less javascript template (such as Handlebars) as the source, we can transpile to virtually any other logic-less template. This allows to be completely independant from the back-end technology.

All variations at a glance

The tool knows about the different variations of each component (following the BEM logic) and can display all of them side by side for easier updates and maintenance.

Documentation built-in

Everyone should benefit from the styleguide: developers, designers and editors. That’s why the documentation is built-in and should contain:

A simple npm module

It must be simple to install and simple to deploy. npm seems the right candidate.

CLI tools

Some usual CLI tools are available to developers to easily setup the local server, kickstart new components, build production code, etc…

What now?

Does that sound nice ? Help me make it real !

I’ve been using a similar tool for the past few months to build the new upcoming front-end at Easyfairs and it’s working as expected.

The module we use suffers from many youthful mistakes, build speed being the worst. I now have a much better idea were I’m going and I would love to hear what you think or even work on this with you. A new Github repo is coming very soon here: https://github.com/lipsumar/design-system-framework.

Get in touch via Twitter or drop me an email !