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
<head> of the downstream site, copying the HTML from the source file, and adding a
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?
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.
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.
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.