Slidedeck by Cristiano Rastelli
Jeremy Keith recently described the separation of concerns in the above graphic using a fantastic metaphor:
Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.”
— Jeremy Keith
Let’s take a look at why you’d want to create this separation at the design system level, and at how a few leading companies are publicly sharing their practice.
So why would you want to separate core HTML & CSS in your design system? The way I see it, there are three potential driving factors:
First, the need to keep HTML & CSS separate will directly depend on the number of products you have to support with your design system, and the underlying tech stack of each. The wider variety (one uses React, one uses Angular; one uses Sass, another uses vanilla CSS, etc.), the greater need to have your core components available as HTML & CSS.
Say your team decides to incorporate Vue in the design system. You’ve got substantial buy-in that the company is standardizing on Vue. Fantastic. Then, 3 months down the road, one team decides they don’t want to use Vue, but prefer React. They’re stuck either building things from scratch, or figuring out how to get React to work with Vue.
Extrapolate that out across products and, as companies grow, multiple lines of business, and you’ll understand the need. Even when companies standardize, there will always be outliers on different teams. Larger still is the issue of rewriting everything in your design system when the next Vue comes along. Will that be in 3 years? 3 months? 3 days?
Predicting the Future
I’m not good at this. If you’re Merlin, you can stop reading here. Still here? Okay, let’s look at some best practice.
The Salesforce Lightning design system is becoming the poster child of modern frontend design systems. Jina Anne not only created it, she’s gone on to create the first 100% design systems focused conference. She wrote chapter 2 of InVision’s Design Systems Handbook.
No. The Salesforce Lightning Design System is a pure CSS framework that you can use with any front-end development framework you’d like, including Salesforce-specific technologies such as Visualforce and Lightning, as well as third-party frameworks like React or Angular.
And that’s where it gets interesting. The Salesforce team is able to take the core HTML & CSS Lightning components and create a separate React-based project from them. Here’s what Jina had to say about that, on the Style Guide Podcast:
— Jina Anne, on the Style Guide Podcast
Lucky us, that React project has already been made public:
The Lightning Design system is an example of an entire suite of components written in vanilla HTML & CSS, with fantastic documentation in their “Design Guidelines”, and a focus on accessibility. This enables their team to build a React version for React-based projects, but that project starts with all the core best practice built in. Maybe I’m just giddy because Lightning pulls off so well what Brad originally described in Atomic Design:
One of the biggest advantages of establishing a thoughtful design system is that it allows organizations to scale best practices. If all those best practices — responsiveness, accessibility, performance, UX, ergonomics, and so on — are baked into the system, users can simply plug in the patterns and reap the rewards. This means design system users don’t have to be senior-level designers or developers to produce good work; the design system serves as a quality control vehicle that helps users apply best practices regardless of each individual’s skill level.
— Brad Frost, Atomic Design
Micah Godbolt wrote the fantastic Frontend Architecture for Design Systems, which included some very neat ideas for abstracting parts of your design system into JSON, what he referred to as “schema-driven design”. Since publication of the book, Micah has been working for Microsoft, on the Fabric design system.
The Fabric design system is built to support core web, React, Angular and iOS. The “get started” process offers the following options:
The Fabric core contains very low-level CSS and design elements that are easily shared cross-project:
What I’m really excited about is the “theme generator” in Fabric’s core — in the “output” section we have theme values available as JSON, Sass and PowerShell. This indicates that the majority of Fabric’s core is available as data that can be translated to different formats, likely the driving force behind being able to support React, Angular and iOS:
The video referenced in the Angular docs offers a great detailed explanation of what their team is able to accomplish, and some of the challenges.
Fabric is different than Lightning in that its primarily exposing low-level pieces in its core (icons, colors, layout, etc.), as opposed to having what Lightning refers to as “Component Blueprints” for all the components it offers.
Remember that design systems conference I mentioned earlier? Yeah, last year Diana Mounter gave a great presentation on color, and I naturally investigated to see if there was anything public related to her work and the team at GitHub’s approach to frontend design systems. Lucky for us, there’s a shiny new docs site:
Well, yes, technically Angular is a front-end framework, but conceptually and philosophically it’s much more like a back-end framework (actually, I think it’s conceptually closest to a native SDK; something more akin to writing iOS or Android apps, while others compare it to ASP.NET).
— Jeremy Keith
I can envision a core HTML/CSS design system which not only contains all the low-level elements (colors, typography, etc.), and components built in vanilla HTML/CSS, but additionally examples of the components in the different templating languages or JS frameworks used in products the system supports. Similar to how Pattern Lab uses tabs for HTML and Mustache.
Whichever path you decide to take will very much depend on your product variety mentioned above. The earlier you decide to abstract low-level pieces at the design system level will be the day you start saving massive amounts of work for your team in the long run.