What is a design system?
A design system is an evolving single source of truth for individuals and teams that are taking part in building products grouped under a single brand or visual language (It doesn’t get more abstract than that 🙂).
A design system may consist of reusable functional and graphic components like symbols, fonts, CSS files, images, and UI code components. The use of these artifacts is guided by an appended documentation of design principles, best practices, and other guidelines. A design system may even include more abstract elements such as beliefs and values connected to a brand.
Having said that, design systems mean different things to different people and may very well not include a full and comprehensive list of items that make up a design system in its strictest sense.
Examples — design systems:
Why should you build a design system?
The benefits of a design system can be categorized under two headings: user experience and product development.
User experience
Less variance in styling = fewer UI components. A limited set of UI components means your users spend less time learning your product and more time enjoying it.
Consistency in style and functionality makes it much easier for users to predict the outcomes of actions performed on your app; thus, minimizing the chance for confusion and the frustration that follows it.
A systematic approach makes it possible to provide optimized UI/UX, based on research and evidence.
A consistent design increases the level of confidence users have in your product.
App development
A single source of truth makes collaboration between designers and developers much easier. As it often happens, a developer may receive partial or ambiguous styling instructions, making it harder for him to implement them accordingly. By consulting in his company’s design system, many ambiguities can quickly be resolved (without the need for an endless back-and-forth between him and the designer/s)
Using a reusable UI component library means less code gets re-written; less time is wasted on re-inventing the wheel and fewer mistakes show up in the code (as a result of the amount of thought put in building a reusable component but also simply as a matter of statistical fact — as chances for mistakes lower when repetition is kept to minimum)
Using a reusable UI component library makes onboarding much easier. New developers can easily find and use components, see examples of how they’re used, etc.
Using a reusable UI component library makes maintenance a breeze. The library’s components have all been tested and agreed upon, and changes to any reusable component quickly get propagated to all instances of it, in and across projects.
A design system for a small team - an overkill?
“The more decisions you put off, and the longer you delay them, the more expensive they become.”
―Craig Villamor, Google Maps
Building a comprehensive design system like the ones we often see created by large enterprises, is obviously not a top priority for small teams or startups. The costs of building such a system dramatically outweigh the benefits for teams of that scale, with no more than one or two projects.
As mentioned earlier, a design system could mean anything from a collection of reusable graphics, all the way to a full and comprehensive system with guidelines and brand values — so, the question is not when should you build a design system but to what extent it should be built.
To put it differently, the question is — what parts of a design system give an immediate return to small teams? The answer is, unsurprisingly, a UI component library.
As mentioned earlier, reusable components ensure consistent design, speed-up development time, simplify maintenance and make your company, as well as your apps, much more scalable. So, why are we not seeing more of it?
Stopping everything to build a design system is a privilege small teams usually just don’t have. Designing a visual system and building a component library to implement it is a pretty massive project to take on.
But, it doesn’t have to be. You can do it the other way around.
Building a UI library, one component at a time
As much as we appreciate the merits of a UI component library, building it is still a project in and of itself. Isolating components, configuring packages, maintaining repositories, etc., are undoubtedly time-consuming and may seem like they’re not worth the effort.
Fortunately, there’s a simpler way 😏
Using Bit (Github) you can easily share components from any project/repository to your own collection (library) in bit.dev.
Bit completely eliminates the overhead involved in building a component library. It isolates components for you — tests and builds them (in isolation) and lets you easily push them to your own collection in bit.dev. No need to configure packages or maintain additional repositories.
Sharing components with Bit
This means you can instantly isolate and export components from any existing app or project, and reuse them in other apps. The side-effect of this process is that as you work, all your components are seamlessly organized, documented, visualized, rendered and made available to consume in one place.
Components in bit.dev are rendered-live with examples and can easily be found using Bit’s search capabilities. No need for a gallery website, documentation portals, external component playgrounds etc.
Browsing through component systems in bit.dev
Components can either be installed using NPM or Yarn or imported to your project, as a source-code, using Bit. Imported components can be updated (from anywhere) and pushed back to their collection in bit.dev.
What it all means is you can focus on building awesome apps while effortlessly create a component library, and immediately enjoy the benefits that come with it 😲
Components’ lifecycle with Bit
Conclusion
Design systems are not exclusive to large enterprises. A design system should accompany your team/organization from the get-go, and grow in width and depth as your company grows.
Medium
Top comments (6)
I am excited to see design tools continue to evolve and help bridge the gap between designers and engineers. Bit is a great example of this. I have worked on many projects that involved continuous back-and-forth efforts between designers and engineers to match a design system. Imagine the time that can be saved when a design system already includes the markup - theoretically, the product is already built... ;D
Here is a nice resource of additional tools moving in that direction.
Nice post! I can certainly see the merit in having a well thought out design system. I've mainly used Material for all of my side projects.
The company I work for does have a site with design guidelines but not a full-fledged component library. Something to bring up to our UI/UX...
Great post! We actually are starting to think to create a component library to a client so that every team working on the project could enjoy and use the components library, because today the project is a bit messy and every team is creating each component in their own way.
Just a question, how do you convinced your team (or your superiors) to implement this library? We kind of gonna have this challenge on the future
Hi Pedro
Just like any other business decision, it's a matter of calculating the benefit-cost ratio.
A component library used to be a time-and-effort consuming project with no guarantee that it will actually be used.
Using new tools like Bit , it now takes much fewer resources to have a library with reusable UI components and the chances of it to being adopted and used by the organization are much higher (thanks to better discoverability of components, easier collaboration on individual components, etc).
So, my advice to you would be to present the benefits of a component library (written in my post) and offer the right tools for the job :)
Great post, Eden! I shared it in our Telegram newsletter/channel for devs. 👉🏼 Link
Hey there! I shared your article here t.me/MenlnTech and check out the group if you haven't already!