I did this! I founded EUI [0] at Elastic and helped teams adopt it. I attribute success to a few factors:
1. Publish components, not styles. This has been rehashed in other HN threads, but the idea is to provide Lego blocks to help engineers build UIs more quickly. This might be out of fashion with Tailwind adherents but we found success by treating the framework's primary interface as React/Vue/JS, not CSS.
2. Be transparent and receptive. Share your goals with consuming teams and ask how you can help them. They might ask for specific components or might ask you to help them convert a UI to use the library. By demonstrating that you and the library are there to serve (as opposed to dictate) you'll earn goodwill and your work will have more impact.
3. Have high-quality components. This applies to the UI design (both how the components look and how they behave) and software design. Are the props intuitive? Do the components compose well? We were fortunate enough to have a strong design and engineering team that did well on this points.
4. Seed the consuming codebase. Patterns in codebases propagate because engineers like to copy/paste. For example, start by migrating all buttons in the consuming codebase over. Then migrate over all forms, modals, and so on. It also helps to take a vertical approach, by migrating a single view entirely over to the library, or building one from scratch. This can get people excited about the library because they can see and experience the end result.
5. Ensure compatibility with the existing codebase. Make sure styles don't collide, make sure the underlying JS libraries are compatible. I chose React for EUI, but the consuming codebase (Kibana) was Angular. We made the decision to convert Kibana to React too, but there was a temporary period where we mounted React components inside of Angular. We needed simple guidelines to support the engineers who were doing that.
1. Documentation should be more than half of your team's time. If it's well documented, and has copy/paste content, people will use it because they are lazy and you gave them the easiest solution.
2. Don't think of yourself as building the UI library only. Take the time to work downstream in the product and help the product teams convert to the new stuff. If you're seen as friendly and supportive, rather than adding more work on a team, it makes things easier.
3. Constantly show off your work in large gatherings. Most folks aren't aware of cool stuff you're doing or why it might be useful. Show, don't tell.
These things fail when the upstream library team things they are passing things over a wall (npm) to a consumer. Dogfood it by building the product alongside the teams.
Hey Dave! I think your great design was a big factor in incentivizing people to use EUI. When folks can see how much of a boost the library can give a UI, they'll _want_ to use it.
“ I chose React for EUI, but the consuming codebase (Kibana) was Angular. We made the decision to convert Kibana to React too, but there was a temporary period where we mounted React components inside of Angular.”
This is my life right now. Glad to hear someone who has done this managed to survive the ordeal :D
I appreciate your points. Can you share more about how you interacted with other teams? Did you have resources to help implement the components into products? Did you use any tools or meeting formats to gather feedback and listen to needs?
Thank you! As snide mentions a few threads up, we built a documentation website for the library from day 1, which I think helped folks a lot. I'm not a fan of Storybook -- I prefer docs to present components in realistic situations, and to have code snippets live-side-by-side so someone can say "Hey this is exactly what I need" and copy and paste it into their codebase. For example, form docs should have an example of a complete form with validation, accessibility attributes, help text, and so on. This way the docs act as both an advertisement and as a resource.
Regarding tools, I recall a bunch of stuff. YMMV:
* A presentation to the wider team on the goals of the library.
* GitHub issues outlining technical design of the library -- this was useful for getting buy-in from tech leads.
* One of the consuming developers gave a presentation on how she had implemented a UI using EUI.
I think it just comes down to repetition and, as snide alluded, positioning yourself as a servant instead of an authority. Keep beating the drum, share success stories, and demonstrate that you're responsive to the feedback you're heading from the folks downstream. Good luck!
1. Publish components, not styles. This has been rehashed in other HN threads, but the idea is to provide Lego blocks to help engineers build UIs more quickly. This might be out of fashion with Tailwind adherents but we found success by treating the framework's primary interface as React/Vue/JS, not CSS.
2. Be transparent and receptive. Share your goals with consuming teams and ask how you can help them. They might ask for specific components or might ask you to help them convert a UI to use the library. By demonstrating that you and the library are there to serve (as opposed to dictate) you'll earn goodwill and your work will have more impact.
3. Have high-quality components. This applies to the UI design (both how the components look and how they behave) and software design. Are the props intuitive? Do the components compose well? We were fortunate enough to have a strong design and engineering team that did well on this points.
4. Seed the consuming codebase. Patterns in codebases propagate because engineers like to copy/paste. For example, start by migrating all buttons in the consuming codebase over. Then migrate over all forms, modals, and so on. It also helps to take a vertical approach, by migrating a single view entirely over to the library, or building one from scratch. This can get people excited about the library because they can see and experience the end result.
5. Ensure compatibility with the existing codebase. Make sure styles don't collide, make sure the underlying JS libraries are compatible. I chose React for EUI, but the consuming codebase (Kibana) was Angular. We made the decision to convert Kibana to React too, but there was a temporary period where we mounted React components inside of Angular. We needed simple guidelines to support the engineers who were doing that.
[0] https://elastic.github.io/eui