Day 6:Tech tools of your Design System #25DaysofDS
PS: I am republishing my 2019 blogs on the Design system at the Hash node. However, these blogs are still valid.
Picking the tech for the design system is challenging especially in today's dynamic tech environment. Developers can be tempted to pick the latest UI framework or might be in the one they are master. You will find yourself always in the trouble to pick the right tech stack. So, what should be done? How to pick the one? What are the Tools one could need while building a Design system? Today we are going to look into that.
What tech do we require?
- Code control tool
- CSS pre-processors
- UI framework
- Existing Design System
- Build tools
- Build distribution
The above stated are the few areas that are important to decide the tech-stacks and tools for the Design System. One point to remember is not the whole list. Let's start looking into each of them and the options available.
Code control tool
There are few options available and every company has the license for the code control tool. Such as GitHub or GitLab. These are very important for reasons to keep your code at a centralized place, and many add-on features such as PRs, code-reviews, commit history, etc.
If you can pick any, please go and research the pros and cons of the code-control tools and pick accordingly.
Your design system holds the styling part of the components. It is important to close the CSS or styling lib you are going to use. Do you want to go to Vanilla? Do you want to use a pre-processor or CSS-in-JS? When you are thinking about any solution, do think about scalability, maintainability, and skills set of the team as well as if new tech you are going to pick then learning curve of that.
A design system is all about UI. When you are planning for the CSS do you also research which UI lib/framework you want to use? Again you want to go vanilla? or Reactjs or angular or web components? Remember, the same matric applies here too, learning curve, team's skillsets, browsers, and OS support, scalability, maintainability, and community support.
Existing Design System
Many times Design systems are made on the existing design systems too. Such as you can make the material design, ng-prime, etc as the base and above that build your design system. This approach has a lot of pros and cons too. Talking about pros - you don't need to take care of many decisions and designs as the existing design system has taken care of. Con would be you will be always dependent on the 3rd party.
When we are coding we need to ship the compiled code for use. So, make sure about which build tool you want to use. Not just for the build but for many other chores such as minification of code, lazy loading, setting up a local environment, etc.
How your users of the design system are going to consume it? Think about this. Will it be a CDN link? npm link? what it is going to be? You need to think about the pros and cons. If you are concerned about the security and privacy of your code then you need to look into paid solutions.
Your development is not done unless and until you are done with the testing. You should invest in the unit and integration testing. If you need to invest in some paid tools do that but this is the most important part of the design system.
Make use of CI/CD and create the pipelines. Make your test cases (unit test-cases), linters, validators, Lighthouse, etc part of your pipelines. This will make sure every developer is following your code guidelines.