Thanks for sharing, Pascal. I really love your ways of demonstrating the nuances and challenges when adopting a design system.
I wonder if you have any suggestions when applying a built design system (Material Design, Ant, Salesforce, etc.) to your own product? How to choose one? One of my challenges is that I could not find a "one thing fits all" system and sometimes have to detach the example component to make additional edits - which I know is not ideal.
Thanks for the positive comments here, it is truly appreciated 🫶.
This is a great question and one that is somewhat difficult to answer without having the full context. As a design team or org, it is important to identify what is your main need. You must first evaluate if is is more valuable to create full blown design system from scratch OR, leverage a pre-existing one and improve it along the way. You must ensure that you include the development team through this very important conversation. They will play a huge role in identifying the best approach.
If you decide to use a pre-existing one, you must then identify the one that seems the closest to your need. There are so many out there to choose from (mui.com, tailwindui.com, etc). From there, you and your development team identify the best option. You can then collaborate with your team to identify:
1. What are the missing components/needs
2. Which component we need to contribute back
3. When to break a component and the best way to approach this
As mentioned in the articles, there is no one size fits all approach but this is something that has worked for me. Collaboration is key here in order to identify the best path forward. Once you identify and figure out "your path forward" you can then start working away at your system. Adding elements to a component and ensure you have a backlog of items to work with your development teams to ensure that these elements are added back in.
Thank you, Pascal, for such well-elaborated reply! I didn't realize the importance of collaboration with development team, which totally makes sense now after reading through your step-by-step explanation.
It seems that there are still various nuances to manipulate with even if leveraging a pre-existing system - agree that a backlog gonna be super helpful! Love that idea and thanks for all the tips :)
Thanks for sharing, Pascal. I really love your ways of demonstrating the nuances and challenges when adopting a design system.
I wonder if you have any suggestions when applying a built design system (Material Design, Ant, Salesforce, etc.) to your own product? How to choose one? One of my challenges is that I could not find a "one thing fits all" system and sometimes have to detach the example component to make additional edits - which I know is not ideal.
Thanks for the positive comments here, it is truly appreciated 🫶.
This is a great question and one that is somewhat difficult to answer without having the full context. As a design team or org, it is important to identify what is your main need. You must first evaluate if is is more valuable to create full blown design system from scratch OR, leverage a pre-existing one and improve it along the way. You must ensure that you include the development team through this very important conversation. They will play a huge role in identifying the best approach.
If you decide to use a pre-existing one, you must then identify the one that seems the closest to your need. There are so many out there to choose from (mui.com, tailwindui.com, etc). From there, you and your development team identify the best option. You can then collaborate with your team to identify:
1. What are the missing components/needs
2. Which component we need to contribute back
3. When to break a component and the best way to approach this
As mentioned in the articles, there is no one size fits all approach but this is something that has worked for me. Collaboration is key here in order to identify the best path forward. Once you identify and figure out "your path forward" you can then start working away at your system. Adding elements to a component and ensure you have a backlog of items to work with your development teams to ensure that these elements are added back in.
Hope this helps you :)
Thank you, Pascal, for such well-elaborated reply! I didn't realize the importance of collaboration with development team, which totally makes sense now after reading through your step-by-step explanation.
It seems that there are still various nuances to manipulate with even if leveraging a pre-existing system - agree that a backlog gonna be super helpful! Love that idea and thanks for all the tips :)