Design systems. It’s a specialty that has grown in the short amount of time that I’ve been developing the web and something that intrigues business owners as a way to create consistent products while saving time and money. I’ve spent the better part of a decade almost exclusively building these systems and wanted to look back and acknowledge how far design systems have come since I first started this journey. I also want to discuss the current trajectory of design systems and how we take these into the future.
2015: Style tiles and pattern libraries
There was a hodgepodge of names that were thrown around for the early pieces of what would become design systems. Style tiles. Pattern library. Component library. I’m probably missing a few. Style tiles were big in design to give a reusable color palette for different patterns to use within a product. Pattern or component libraries included reusable HTML, CSS, and JavaScript of a product so that teams didn’t have to build the same table or buttons from scratch over and over again. But products didn’t directly consume components at the time. The process involved including the CSS for all components in the <head> of the downstream site, copying the HTML from the source file, and adding a <script> tag if your component needed some presentational JavaScript. Sass variables were the glue between design’s style tiles and CSS. JSON objects and arrays paired with mustache templates were your best friend and filtering those through Pattern Lab was the path to creating successful component/pattern libraries. Replace those mustache variables with WordPress PHP and it was magic! The storefront of our systems was built from scratch in Jekyll, iframes pointed to Pattern Lab and had to be manipulated to get the iframe to take the height of the component that was passed in. This site was built using the design system code and documentation tables were manually created for every single component.
This was a simpler time, but one that I really appreciate to this day because it is the base for how we build systems today. In the end, what shows up on the screen comes down to thoughtful HTML, CSS, and JavaScript.
The popularization of JavaScript frameworks
I clearly remember the arrival of the JS frameworks into the conversations we had with clients. React and Angular were the major ones with the popularity of Vue following suit. I remember really struggling with it at first and complaining. “Why are we using React when we have perfectly good HTML, CSS, and JS over here?!” When your team can’t convince the client to move away from React, you kind of have to learn it. By the end of that project, I started to learn the value of it. No longer did teams need to copy, paste, and replace variables in their products. Product teams could directly consume these bundles and get the HTML, CSS, and JS for free by importing a component. ES6 module support was huge for this process and changed the landscape of design systems. Storybook started to pop-up in client conversation. At the time it felt like competition to Pattern Lab so, of course, I was skeptical of it. Eventually these frameworks became more than just discussion pieces, but engrained into the organizations we worked with everyday.
Where do we stand today?
I really want to focus on where design systems are at today and the future. Since the arrival of React, Angular, and Vue and the additions of many more frameworks, Storybook has become the development tool for creating, displaying, deploying, and bundling up components. Storybook can auto-generate prop tables and the days of manually having to do that are fortunately over. Add-ons bring accessibility, RTL language support, interactive controls, and plenty of other important features into the development process of design systems. Figma has become the front-runner for design tools for design systems as it continues to create more efficient ways for systems to work while bringing design and development closer together. ZeroHeight has become the equivalent of the Jekyll and Gatsby reference sites that I would build from scratch, but with lots of fantastic bells and whistles that require a proper team to maintain and enhance. ZeroHeight can pull in from Storybook and Figma to help align development and design and present the components and documentation to consumers in a helpful way. It really is incredible how far we’ve come with these systems and tools.
With the improvements of technology comes extra time to focus on other essential things. The selling-point of consistency is no longer as loud as it used to be and the bigger focus is on items like accessibility, multi-theming, server-side rendering, analytics, testing, automation, and performance. Design systems have become more than just a pattern library with some dev documentation for a few products. They have become an ecosystem of guidance for how many product teams in an organization should design and develop.
Where do we go from here?
We’re at an interesting point in the design system world from where I sit. Technology has become significantly better since 2015. Back then, the component library world revolved around your simple HTML, CSS, and JavaScript. Then Angular, web components, React, and Vue came out in a 4 year span to change the world of design systems to a more consumable component format. While web components were native to the web, the JS frameworks took front-stage, leaving web components in the back of the fridge. Because these frameworks became popular and teams could consume these components directly in less time, plenty of organizations split away from native HTML, CSS, and JS in some areas to focus on one or multiple frameworks. Now, these large organizations have multiple design systems with inconsistencies between these.
How do organizations plan to solve these inconsistencies across multiple platforms?
Enter web components. Coming full-circle back to 2015, what are web design system components at the very root level? HTML, CSS, and JS. Web components are essentially modular bundles of HTML, CSS, and JS that can be included in an application by themselves (e.g. Drupal environment) or be thrown into one of the multiple frameworks. By having these modular HTML, CSS, and presentational JS bundles, you create that consistency across web platforms as long as you use that same web component tag (e.g. <design-system-button>). That way a button in a Drupal environment can look the same as a React button or an Angular button or whatever other framework is needed. LitElement and Stencil have been leading the charge in this department by creating easier ways to compose web components for more flexible consumption.
This is where design systems are heading and frameworks should really embrace web components instead of having a “we vs. them” mentality that I’ve seen at times. Because web components took a backseat to the JS frameworks, there are still some improvements that still need to be made. Cross-shadow root accessibility and server-side rendering (SSR) are two challenges currently being worked on to help create a performant, accessible web experiences. There are minor workarounds for now.
While injecting web components into multiple frameworks is a move towards greater consistency (that we’ve done now for organizations), just be mindful that teams have to maintain these systems. These systems have become a lot broader which should require a core team support and smart thinking. While web components can be injected just about anywhere, normalizing on a couple frameworks probably makes sense unless you have plenty of people who can specialize across frameworks to help guide the system.
Wrapping up
The web should continue to get easier to build and we need to work together to get it there. Adaptability is part of the web in the short time that I’ve been around and we need to figure out how to approach not only design systems, but our own roles, as technology improves. Now that Internet Explorer is in the past, new features like container queries and form field styling will change the way we build design systems and the web. Add in AI as it matures and we’ve got an entirely different landscape that we’ll need to adjust to yet again.
Despite the changes over the years, design systems continue to stick around and will likely stick around until there is a new buzzword for them. From a component standpoint, the foundation remains the same with thoughtful HTML, CSS, and JavaScript. From an organizational standpoint, companies should really invest in teams to support these systems. A design system is a product that serves many products and should be treated that way. Design should save a company money, but you can’t expect great work by throwing a skeleton crew at them. They are an art and a science that requires proper thinking to get right. The success of a system depends more on the people and process within the system more than the framework or tooling.
Let’s continue to make beautiful, performant, and accessible design systems for the Internet. Until the robots take over, keep collaborating, keep improving, and keep building.