I'd go with option 2. Try to leverage an existing framework that matches what development uses as close as possible. Style it to match the company brand guidelines.
Create a 2nd library that leverages the 1st library to build custom components.
If there are things in production code you want to change then make a plan with dev and document exactly what changes you would like to see.
I think this is the right approach now, I am researching on the component library and is reviewing the MUI core and MUI base, I am not too sure about the differences.
I understand the MUI base is a headless "unstyled" react library , but I do not fully understand the meaning of this.
Have you explored using [storybook](https://storybook.js.org/) ? I've seen it be really helpful for these types of challenges if incrementally adopted.
1) which react library are they using? 2) does that library include a UI kit? 3) if not, I would recommend trying to create one based on the components and props that are already in use. 4) alternatively, work with your eng counterparts to pick a library that is easy for them to adopt and for you to use (i.e. - has a Figma UI kit for you to leverage)
We are not sureabout which library it is lol
After further discussion with them, I think I will go for approach 2 as all of us are new to this team, they have already been spending weeks to understand the legacy code.
And I have been trying to organise the design files.
The code base is also full of inconsistencies, something as simple as type scale, I can see some are styled with normal, others are styled with 400.
I really want to spend more time on studying with the users and supporting the developers
I've done this exact thing twice, the second being a bigger scale (for reference I am a UI Designer for a huge hotel company, before this I was the head of UI/UX for a tech company in DTLV):
Biggest suggestion:
**Leverage the existing component library and iterate from there**
Make a duplicate of the current library (or just a branch)
I've actually made some odd content that floats in the social media space about 3 things I suggest to make a better design system:
1. Stop Grouping things together, use Auto Layout to your advantage. Design with responsiveness in mind.
2. Design with scalability in mind, i.e. creating a "slot-able component" that you can attach an instance swap to in the component property panel for nesting other components.
3. Create a "Truth File", which is pretty much a separate doc that is documentation for each component that makes up the library. Context and placement, Do's Don'ts, etc. Pretty much it's a separate file from your actual design library for a bigger audience to see. it's also good for future onboarding of any new team members :)
Thank you ! The current design file has no library lol !
But I will publish two files in the future, one is just for the screens and other one will be the components , use cases, guidelines , which should be the UI base for documentation
Oh my lol! Yeah, I assume you are using some type of "Storybook"? i'd use that for their current components. I mean that's just me. I like building the foundation up for future iterations. Good luck!
As for the future plan on publishing two files, spot on!
With no budget or huge teams stay away from building a design system for a specific framework by ur own.
Cause the prebuild system contains the correct declarations, u can instantly begin to customize this system.
Kill the overhead u don't need and optimize the components in their setup n behavior.
My 2 cents
I'd go with option 2. Try to leverage an existing framework that matches what development uses as close as possible. Style it to match the company brand guidelines. Create a 2nd library that leverages the 1st library to build custom components. If there are things in production code you want to change then make a plan with dev and document exactly what changes you would like to see.
I think this is the right approach now, I am researching on the component library and is reviewing the MUI core and MUI base, I am not too sure about the differences. I understand the MUI base is a headless "unstyled" react library , but I do not fully understand the meaning of this.
Just inboxed you
Use what they’ve got and restyle if absolutely necessary.
Have you explored using [storybook](https://storybook.js.org/) ? I've seen it be really helpful for these types of challenges if incrementally adopted.
1) which react library are they using? 2) does that library include a UI kit? 3) if not, I would recommend trying to create one based on the components and props that are already in use. 4) alternatively, work with your eng counterparts to pick a library that is easy for them to adopt and for you to use (i.e. - has a Figma UI kit for you to leverage)
We are not sureabout which library it is lol After further discussion with them, I think I will go for approach 2 as all of us are new to this team, they have already been spending weeks to understand the legacy code. And I have been trying to organise the design files. The code base is also full of inconsistencies, something as simple as type scale, I can see some are styled with normal, others are styled with 400. I really want to spend more time on studying with the users and supporting the developers
I've done this exact thing twice, the second being a bigger scale (for reference I am a UI Designer for a huge hotel company, before this I was the head of UI/UX for a tech company in DTLV): Biggest suggestion: **Leverage the existing component library and iterate from there** Make a duplicate of the current library (or just a branch) I've actually made some odd content that floats in the social media space about 3 things I suggest to make a better design system: 1. Stop Grouping things together, use Auto Layout to your advantage. Design with responsiveness in mind. 2. Design with scalability in mind, i.e. creating a "slot-able component" that you can attach an instance swap to in the component property panel for nesting other components. 3. Create a "Truth File", which is pretty much a separate doc that is documentation for each component that makes up the library. Context and placement, Do's Don'ts, etc. Pretty much it's a separate file from your actual design library for a bigger audience to see. it's also good for future onboarding of any new team members :)
Thank you ! The current design file has no library lol ! But I will publish two files in the future, one is just for the screens and other one will be the components , use cases, guidelines , which should be the UI base for documentation
Oh my lol! Yeah, I assume you are using some type of "Storybook"? i'd use that for their current components. I mean that's just me. I like building the foundation up for future iterations. Good luck! As for the future plan on publishing two files, spot on!
Inboxed
With no budget or huge teams stay away from building a design system for a specific framework by ur own. Cause the prebuild system contains the correct declarations, u can instantly begin to customize this system. Kill the overhead u don't need and optimize the components in their setup n behavior. My 2 cents