How to Gradually Build a Design System
Building a design system as a side-effect of your everyday work
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, 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.
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.
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 😲
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.
