design systems

Dependencies in JavaScript are pretty straightforward. I can't write library.doThing() unless library exists. If library changes in some fundamental way, things break and hopefully our tests catch it.

Dependencies in CSS can be a bit more abstract. Robin just wrote in our newsletter how the styling from certain classes (e.g. position: absolute) can depend on the styling from other classes (e.g. position: relative) and how that can be — at best — obtuse sometimes.

Design has dependencies too, especially in design systems. Nathan Curtis:

You release icon first, and then other components that depend on it later. Then, icon adds minor features or suffers a breaking change. If you update icon, you can’t stop there. You must ripple that change through all of icon’s dependent in the library too.

“If we upgrade and break a component, we have to go through and fix all the dependent components.” — Jony Cheung, Software Engineering Manager, Atlassian’s Atlaskit

The biggest changes happen with the smallest components.

My pal Lindsay Grizzard wrote about creating a CSS system that works across an organization and all of the things to keep in mind when starting a new project:

Getting other developers and designers to use the standardized rules is essential. When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM. You can explore working around this with linters, but forcing people to use a naming convention they hate isn’t going to make your job any easier. Hopefully, you will be able to convince them why the extra underscores are useful, but finding a middle ground where everyone will participate in some type of system is the priority.

I totally agree and the important point I noted here is that all of this work is a collaborative process and compromise is vital when making a system of styles that are scalable and cohesive. In my experience, at least, it’s real easy to walk into a room with all the rules written down and new guidelines ready to be enforced, but that never works out in the end.

Ethan Marcotte riffed on Lindsay’s post in an article called Weft and described why that’s not always a successful approach:

Broad strokes here, but I feel our industry tends to invert Lindsay’s model: we often start by identifying a technical solution to a problem, before understanding its broader context. Put another way, I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.

Jules Forrest discusses some of the work that her team at Credit Karma has been up to when it comes to design systems. Jules writes:

...in most engineering organizations, you spend your whole first day setting up your development environment so you can actually ship code. It’s generally pretty tedious and no one likes doing it, but it’s this thing you do to contribute meaningful work to production. Which got me thinking, what would it look like to make it easier for designers to design for production?

(more…)

The team at Figma has created a new resource for “learning, creating and evangelizing design systems” called Design Systems that already has a good collection of interviews and articles by some folks thinking about these things.

I particularly liked Jeroen Ransijn’s post on how to convince your company it’s ready for a design system, where he writes:

Building a design system is not about reaching a single point in time. It’s an ongoing process of learning, building, evangelizing and driving adoption in your organization.

Design systems are a popular topic. Ethan Marcotte recently looked at instances where patterns get weird, Lucan Lemonnier shared a process for creating a consistent design system in Sketch, and Brad Frost debunked the perception that design systems are rigid. Seems like Figma's new site will be a nice curated repository of this ongoing discussion.

Heydon Pickering looks into how to give a React component a certain heading (like <h1></h1>, <h2></h2>, etc.) depending on its context and thereby ensure that the DOM is still perfectly accessible for screen readers. Why is using the right heading important though? Heydon writes in the intro:

One thing that keeps coming back to me, in research, testing, and everyday conversation with colleagues and friends, is just how important headings are. For screen reader users, headings describe the relationships between sections and subsections and — where used correctly — provide both an outline and a means of navigation. Headings are infrastructure.

(more…)

Brad frost picks up the ongoing conversation about design systems. Where many posts seem to center on how to create one and how to enforce it, the big takeaway here is that design systems are not synonymous with constraints. They're only as strict as we make them and new CSS features like custom properties actually open up new creative possibilities—something Andres Galante and Cliff Pyles recently pitched right here on CSS-Tricks.

Brad:

The aesthetic layer is often the most malleable layer of the frontend stack, which means that we can create systems that allow for a lot of aesthetic flexibility while still retaining a solid underlying structural foundation.

This not only sounds right, but puts a strong punctuation on why we love CSS: it's a set of styles that can be applied an infinite number of ways to the same HTML markup. A new layer of paint can be slapped on at any time, but the beams, walls and ceiling of the building can remain constant. Dave Rupert's personal site is a prime example of this and he details his approach to theming.

Ah, CSS Zen Garden...

We talk a lot about Vue around here, including some practical applications of it, but haven't gotten deep into designing for it. In this post, Viljami Salminen describes his Vue design process and the thinking that led him to build the Vue Design System:

A design system can help establish a common vocabulary between everyone in an organization and ease the collabo­ration between different disciplines. I’ve seen it go the other way around too when important decisions have been made in a rush. To avoid that, Vue Design System introduces the following framework for naming that I’ve found working well in the past...

Viljami lists Design Principles, Tokens, Elements, Patterns, and Templates as the way in which he structures a system and I think it’s a pretty interesting approach and a parallel to Lucas Lemonnier's post on creating design systems in Sketch, using Atomic Design as the structure. I particularly like how Viljami fits everything together in the example style guide that’s provided.