Before even getting to fun the part of building the component library, as an engineer that builds tools, convincing stakeholders that this tool will be worth building was the absolute first step. This can be a daunting task, especially when teams have been using an existing design system for years. Here are some things that helped us get buy-in:

1. Identify pain points We already understood that the existing design system had limitations, but it was important to gather feedback from actual users of the system. As a majority remote office, we were able to gather pain points and frustrations through slack, which led us to the overall agreement that a new component library was necessary.

2. Understand your weaknesses We had two fairly large problems on our hands that are not uncommon of most tech companies these days:

We were a very lean team - with only a couple of engineers and a designer, we had to be strategic about how we allocated our time and resources. Building a component library from scratch would be a massive undertaking to support our product, and we had to be realistic about what we could achieve with our limited bandwidth.

We also had to be honest about the shortcomings of our existing design system - it was built in-house by an even smaller team, and while it served its purpose at the time, it lacked the robust features, documentation, and community support that a well-established library could provide. By acknowledging this deficit, leaning on a third party component library was almost a no-brainer. As an engineer, I would have loved nothing more than to have the opportunity to create components from scratch. However, I needed to be realistic about our team's capacity and product timelines in the short term, and the long-term sustainability of maintaining a custom design system.

3. Do the research We evaluated several popular component libraries, including Chakra UI, Material-UI, Shadcn, Radix-ui, and Ant Design. We looked for:

• **accessibility support**: were components built with accessibility in mind?
• **customizability**: could we easily theme and extend the components to fit our brand needs?
• **documentation quality**: was there clear, comprehensive documentation for developers and designers?
• **ease of dev use**: will this be easy for our devs to adopt without a huge learning curve?
• **performance and bundle size**: were the components optimized for fast load times and smooth interactions?
• **active maintenance**: was the library actively maintained with regular updates and bug fixes?
• **community support**: have other companies adopted this? A design system is driven by community, after all

4. Make sure Design is on your side While we knew our engineering pain points, design also had their concerns. We needed to present a solid case that addressed both sides. We already knew the benefits of adopting a third-party component library from the engineering side (improved accessibility, faster development times, and better design consistency), so we needed to find a way for design to jump on board as well. It helped to have a forkable library that designers could easily work with in Figma! We also needed to make sure there was a concrete understanding that we shouldn't stray far from the component library we'll be forking. Design buy-in is just as (if not more) important as engineering buy-in, so we made sure to involve them in the decision-making process from the beginning.

5. Present a clear migration plan One of the biggest concerns with adopting a new component library is the migration process. We needed to present a clear plan for how we would transition from the existing design system to the new one. This included identifying which components would need to be replaced, how customizations should be handled, and what the timeline would look like. By having a solid plan in place, we were able to alleviate some of the fears and uncertainties that stakeholders had about the migration process. See my next post on migrating our design system.

6. Communicate, communicate, communicate Throughout the entire process, we made sure to keep stakeholders informed and involved. We had a dedicated slack channel and held office hours for design and engineering where folks could come with any feedback. We held regular meetings for DS-focused folks to provide updates on our progress, address any concerns, and gather/share even more feedback. By keeping the lines of communication open, we were able to build trust and confidence in our decision to adopt a new component library.

If there's one thing I've learned from this experience, it's that getting buy-in for a new component library is not just about presenting a solid case - it's about building relationships, addressing concerns, and working collaboratively towards a shared goal. Collaboration and community is key to help a design system (and a company) thrive.