#1: Why You Need To Know About Design Systems
Welcome to our user-friendly series on design systems. If you’re just meeting us: we’re Basalt, and we’re happy you’re here. We design, implement, and build elegant design systems for organizations large and small to power their comprehensive technology (and business) strategies.
Because we believe design systems are the future standard of web design, we’re writing this eight-part series to better explain what they are and how we implement them differently.
We started Basalt because we’re passionate about helping organizations evolve, grow, and streamline using design systems. But even though we’re experts at building and implementing them, what they actually are can still be challenging to define and explain. Design systems incorporate, unify, and connect every aspect of the organizations that use them in myriad positive ways — thus, their definition differs according to their unique benefit to the stakeholder:
A CEO sees a better bottom line, a CTO notices a newly empowered development team, a marketing coordinator sees brand consistency across channels. A content editor enjoys clearly defined practices and elegant, thoughtful tooling. Developers are empowered to do their best work. Your customers probably don’t even know it’s there: all they notice is an elegant, intuitive user experience. But from a bird’s-eye view, we like designer Dan Mall’s succinct definition: a design system is a way to integrate creative direction across an organization.
We think it’s important that everyone knows what design systems are, and what they can do, because where building for the web is concerned, design systems are very quickly becoming the water we swim in. This evolution in web design is happening because design systems are a more cost-effective way to build better products for the web in a fraction of the time it used to.
Because we believe they are the future standard of web design, we’re writing this series to better explain design systems and how we implement them differently.
Our simplest definition of a design system: a set of technology tools, principles, and practices that allow an organization to build for the web faster, better, and with fewer resources. That’s it: a set of technology tools; a set of principles and practices. The technology tools are tangible artifacts. The principles and practices are how an organization uses those tools in an organized manner to achieve a common goal.
UX and interaction designer Alla Kholmatova defines a design system as a set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product — her book, Design Systems, in our opinion, is the one to read if you want a full sweep of the topic within one volume. We are not trying to do that here: we’re here to give you the Cliffs Notes of their benefits, to explain who they’re for, and to explain how a design system is born.
Their benefits:
- A more cost-effective route to better digital products
- Increased brand security, functionality, and scalability
- a comprehensive technology strategy that reduces pain and increases agility.
(We’re dedicating the next eight posts to fleshing out the benefits, so stay tuned.)
Who they’re for:
A diverse and ever-expanding scope of business verticals, including, in short, any organization that builds for the web in order to do business, showcase a brand, and grow.
(That’s why we’re covering this topic without the usual tech lingo: the application of design systems is broadening as they evolve. We want to make their benefits crystal clear…even to organizations who don’t yet know they could use them.)
We think it’s important that everyone knows what design systems are, and what they can do, because where building for the web is concerned, design systems are very quickly becoming the water we swim in.
How a design system is born: that’s this series. We’ll walk you through our methodology for implementing design systems, beginning with an overview of the process, and zooming in on the aspects of our approach that are unique.
Who is this series for?
If you’re read this far, it’s probably for you. We’re writing it for anyone who cares about how their organization runs and wants to communicate the benefit of design systems to the rest of their team.
We’ll offer our views on healthy communication around governance, thorough interface inventories, richer discovery sessions, the paramount importance of design principles, and much more.
We hope it’s accessible to anyone within organizations who stands to benefit from design systems, which (we think) means everyone.
We want more organizations to have the power to address their specific, previously unsolvable web development and brand control problems: in part, design systems exist to reduce your pain. But we think it’s far more exciting to consider them instead in terms of their positive potential — strengthening bottom lines, polishing brands, and helping organizations build, scale, and maintain their technology solutions.
We at Basalt hope that being as transparent as possible about our methodology — how we work with clients to make a design system happen — will offer you something of value, and make the incredible potential of design systems apparent along the way.
(Devs: we’re thinking of you, too. We’ll be writing about deployment, React, Interface Inventory, systems integration, serverless design systems/design systems in microservices, and all of your favorite things.)
Very soon, we’ll be presenting our philosophy on implementation methodologies — the sequence of steps that bring a design system into being. And in our third post in the series, we’ll introduce you to the actual roadmap detailing Basalt’s methodology: a succinct, ground-level tour of the whole process from start to finish.
Follow us on Medium to join us on the journey, and thanks for reading!
You can find out more about us at basalt.io.
