I’m very much on board with the “thinking it as a product” and I think we’re actually going to be in good position to sell it to other teams since they’re being forced to adhere to common designs - there’s just no help or implementations to get them there. So even if we don’t build something they find as good as their favorite library, we’ll have the upside of being the one that adheres to the design.
I also like your thoughts on “customer support” and I’m considering whether doing hands on help for the teams migrating would also be worth it.
I’m still pondering whether starting with something really hard or doing some of the easy stuff is the right way. Starting with easier stuff would allow us to build a foundation, get to the point where the library is actually installed across products, which could help establish some feedback loops. That said, I really like your point about targeting the most legacy apps. As you say, that might create of following of people that appreciate the work and would spread the word.
Be careful with wording things that way. "There's currently no competition" and "you have to do it anyway" isn't necessarily a product feature, but possibly a reason to be distrustful.
But yes, ease of use should be easier to sell given a status quo with no competition and no existing easy options.
> I’m still pondering whether starting with something really hard or doing some of the easy stuff is the right way.
It's always going to be a hard decision. It can be helpful to bootstrap with the easy projects with simple needs and by volume (raw number of projects) there might be more of them, but when you finally get around to the hard projects you find you didn't prepare enough and need a lot more work, or big rewrites that will upset all your "easy" customers. But, yes, if you start with the hard projects (and those might be by volume the company's largest codebases or user bases) you might see a lot slower progress, a lot slower to get to an "MVP" point, and subsequently a lot slower to establish some of your feedback cycles, but the teams giving you feedback are likely ones that are going to be most appreciative of the hard work, most helpful in helping getting the easy things rock solid while also given you a perspective on the hardest things, and can be indeed be your greatest internal marketers to other teams if they are happy with all of that hard work.
anyone with access to the figma designs can make just about any component library match any design. when i worked at PwC the internal component library was so bad i would build a basic HMTL5 component and use inline styles to match the design.
as a frontend developer i hate using terrible internal library components that are worse than nothing. it becomes a huge bottleneck that destroys velocity.
just think of this: Single Point of Failure for all your applications.
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!
I’m very much on board with the “thinking it as a product” and I think we’re actually going to be in good position to sell it to other teams since they’re being forced to adhere to common designs - there’s just no help or implementations to get them there. So even if we don’t build something they find as good as their favorite library, we’ll have the upside of being the one that adheres to the design.
I also like your thoughts on “customer support” and I’m considering whether doing hands on help for the teams migrating would also be worth it.
I’m still pondering whether starting with something really hard or doing some of the easy stuff is the right way. Starting with easier stuff would allow us to build a foundation, get to the point where the library is actually installed across products, which could help establish some feedback loops. That said, I really like your point about targeting the most legacy apps. As you say, that might create of following of people that appreciate the work and would spread the word.