Design Systems Are The New Responsive Design

The processes surrounding web design and development are undergoing a radical shift. I'm not talking about new JS frameworks claiming to be the "next great thing", or css-in-js, or any other language fad: I'm talking how we approach building the internet. I'm talking about design systems.

Over the last decade we've watched as mobile responsive design has transformed from an unknown entity to an essential — even primary — consideration of any web project. If you're a developer (or a designer, or a marketing exec, or anyone within 200 feet of a web project), responsive design and development come as a given. There's no question about making sites responsive: it's the new normal. I predict we'll see the same transformation surrounding design systems over the next five years. They'll move from being an unknown entity (to the general public) or an afterthought or nonessential (to a company), to an expected, required, understood approach to the web.

At Clarity Conference 2018, Amélie Lamont spoke brilliantly about language and design. One of her points stuck with me more than the rest: important periods of transformation (e.g. movements) aren't named and defined as revolutionary during the transformation — it's after, when we look back on what's changed, that we put words and titles and importance to it all. I believe we're in one of those moments, and will be able to look back with clear language in few more years to pinpoint the shift in thinking around design systems.

Currently, there is no standard definition as to what a design system actually is. Some design teams consider their visual component library in Sketch to be a design system. Do their devs agree? I doubt it. Some dev teams consider their gists and component repositories to be a design system. Can their designers see the UI? Interact with it? Probably not. This is the first major shift I anticipate: I hope we can start moving towards a common understanding that design systems live in code, but are accessible by non-coders. Adekunle Oduye succinctly said it at that same conference: "A design system doesn’t exist until it’s in code." Design systems should be built by and show off the ACTUAL code you use in your application. That same source of truth should be consumed by your site — meaning devs only have to build components once, and code won't have a chance to break in the build process.

Let's go one step further and look at implementation. Not all implementations are equal, and I think this is the second place where we'll see radical changes as this movement grows.

Many design systems currently take the "custom Bootstrap" approach. This means you've simplified your development process a bit by organizing and documenting ready-made HTML snippets with various CSS classes to differentiate between variations. It's easy for developers to copy and paste that code into their applications to fulfill specific needs. But what happens when you want to do a major overhaul — one that would necessitate (or be facilitated by) a restructuring of your HTML? Developers still need to find every location of that HTML and swap it for the new HTML. You may be able to keep the same classes, but they might be severely out of date — particularly if they were named for their physical appearance, e.g. "btn--blue" rather than "btn--primary".

This is where template-driven design systems have an immeasurable leg up: your developers only have to change the HTML in one place. They haven't disseminated mutable HTML all over your brand's sites: they've put in a templating language, hopefully with a simple data-structure like JSON, which will likely remain the same no matter how drastic your brand refresh. Your "single source of truth" is exactly that, a single source of truth — not just in theory, but in practice, too. Let's take an event announcement card as an example. Likely, no matter how wildly your designs change, the data is the same: name, date, location, time, summary, picture, etc. With the "custom bootstrap," devs are copying and pasting new HTML all over your sites to update in accordance to the refresh. With a templating language and a solid data structure, your devs will update one single location: the true single source of truth. The mother template to which all data feeds into. The data structure can remain, and our brand refresh just got considerably faster and easier.

As management and stakeholders continue to ask about the ROI on design systems, I can't help but wonder how obvious it would be to them if they spent a week in the dev trenches during the midst of a brand refresh. I have no doubt it would be clear as day: a full fledged, professionally implemented design system will be a solid investment, and WILL raise the bottom line.

The design systems community is hungry right now — with no single "right" way to do it (yes, I'm admitting that even what I've espoused here may not be right for everyone), everyone is doing their best to make the right decision for their own situation. I'm excited to watch this movement progress in the coming years, and curious to look back — once we "figure it out" — and clearly see how the pieces all fall together. Personally, I'll stake my flag on the templating language hill, but let's check back in a few years and see how it's going. Who knows? Maybe the real answer isn't even here yet!