TL;DR 🚀
- 👉 Design systems help bridge the gap between designers and developers and improve collaboration between the two.
- 👉 The Atomic Design Methodology is a great place to start building your own design system for your company.
- 👉 Documenting your design system is of the utmost importance. Clear communication is key.
- 👉 Don’t see design systems as a saving grace, but merely as a tool to improve your company’s efficiency and deliver MVPs faster.
At Bothrs, we’re all about creating better experiences, faster. Design systems really speak to both of those adjectives more than anything. So, last night we went to a cosy little get-together in the beautiful city of Ghent to learn more about design systems; what in the devil are they, and how do you build and maintain them? Johan Ronsse, UI designer at the Belgium-based digital design studio, Mono Company, kicked off the evening and told us all about what design systems are, for real. Next up, Stephen Verhalleman, product designer over at Teamleader, talked about how you can turn a design system into a tool and service. Lastly, Jonathan Dierckens and Maarten De Roeck, full stack developer and product designer respectively at In The Pocket, told us all about automating design systems. Curious to learn what we made of all that? Keep reading!
What even is a design system?
There are a bunch of misconceptions out there as to what a design system actually entails. No shame though, design systems are still in their infancy. Most people think it’s a style guide, a big ol’ library of components, or a giant list of principles and guidelines. In reality, it’s really an amalgamation of all of those things; kind of like an entire ecosystem. It benefits communication, people, and businesses. It’s organic; it grows and evolves as the company matures or customer needs change.
Ultimately, it’s about bridging the gap between designers and developers, and creating a better functioning product faster and more efficiently. It provides consistency, and improves the collaboration between designers and developers. After all, it can be quite the challenge to get everyone to communicate in a way where nobody is left clueless. Imagine your product has a boatload of drop-down menus that all behave a slightly differently. An OCD-ridden product manager will, without a shadow of a doubt, lose his mind entirely. Your developer, on the other hand, is getting real tired of having to reinvent the wheel over and over.
So, how to deal with those types of struggles? Basically, you start off by getting together to properly articulate these issues. From there, you can start working on building a systematic approach to design as a whole. Sounds like you’d need a lot of alignment in there and you’d be completely right. That’s exactly why thorough documentation is so important. Take a look at Shopify’s Polaris for instance. There’s content and design guidelines, a list of components -building blocks, if you will- and patterns; everything Shopify merchants need to know to build the best possible experience including less obvious things like tone of voice, for instance. That sounds like music to our ears.
If this sounds a little too abstract for you, no worries. If you’re wondering how you could define and build a design system from the ground up, be sure to check out Brad Frost’s Atomic Design Methodology. In short, it’s composed of five distinct stages working together to create interface design systems in a more hierarchical manner. Here’s how it’s set up:
- Atoms are UI elements that can’t be broken down any further and serve as the elemental building blocks of an interface. These are like basic HTML elements, like form labels or buttons.
- Molecules are collections of atoms that form relatively simple UI components. For example, you can make a search form out of a button, a search input and a form label.
- Organisms are relatively complex components that form discrete sections of an interface. A group of molecules, if you will. Like a header on a web page.
- Templates place components within a layout and demonstrate the design’s underlying content structure. It’s basically a specific arrangement of organisms.
- Pages apply real content to templates and articulate variations to demonstrate the final UI and test the resilience of the design system.
Each higher-level stage is comprised of elements of the lower-level stages, making it a lot easier for both developers and designers to understand one another.
Cool, but do I really need a design system?
Here at Bothrs, we’re painfully aware how fast things can move in the digital realm. Imagine the following doomsday scenario real quick. Building and designing a digital product can be a long and tedious affair, I think we can all agree on that. Imagine a team of designers and developers have been slaving away on a product for two years, but then suddenly the company decides to launch a full-scale rebranding. Sounds great from a design perspective, getting with the times and all, but everyone that’s been working on the project for the past two years are pulling their hair out right this instance, or what’s left of it. Rebranding means a complete manual rework of both styling and coding. This is exactly what the In The Pocket guys meant when they were talking about not giving yourself shitty work.
With a proper design system in place, those same people would still have some hair left on their greasy scalp. For example, having an implemented design system allows you to alter atom-level components like form labels or buttons in seconds and changes can be applied consistently throughout the entire product design almost instantaneously. Change one ‘master component’ to your liking and boom, it’s now adjusted properly everywhere else.
On large-scale projects, with hundreds of layers, a design system could save your team weeks of reinventing wheels, and would allow for a much better cohesion of both design and development. If you care about efficiency at your company at all, this is properly the biggest argument when you’re advocating for design systems.
Damn, I better get to it then!
Take your foot off the gas for a minute there, champ. While it’s been a lot of hype talk up until this point, design systems are merely a means to an end, and not an end in itself. Make no mistake, you can’t just go and build a fully fledged design system in a vacuum to then start releasing new products every week; the level of oversight would be painful to say the least. In a perfect world, you’d build your design system alongside the creation of a product. In reality, only around half of design companies could actually pull that off. Often times, the product came first.
What’s next?
The fine gentlemen at In The Pocket even went a little further. Remember when I said design systems were about bridging the gap between design and development? Imagine you could automate that translation process. Let me put this in a way that makes me sound smart: we’re talking design-code integrations to automate developer handoff, and making it scalable. Sounds pretty smart, right? All that with the overarching intention to further reduce friction (and therefore save time) between design and code
Exciting times ahead, that’s for sure. It doesn’t take a genius to figure out why a well-built and well-documented design system could help a company to move faster and more efficiently. But it’s no holy grail either. As mentioned earlier, it’s a means to an end, and it takes a ton of work to put into place for developers and designers alike. It’ll take a lot of counseling, but what marriage doesn’t these days? 🤔