Hacker News new | past | comments | ask | show | jobs | submit login

Step 1: The main folks you should convince to get onboard are actually the designers. The argument I've seen work pretty well is "having a consistent design means your designer don't need to QA quite as often and it raises the baseline quality for everything." Finally "we will have shared components no matter what, we want you to influence them"

Step 2: Just start building the components. Don't wait for approvals. With enough of a foundation you can show some value and go from there.

Step 3: Show evidence of time savings, how many of those components are used by how many projects.

Step 4: Share a vision and strategy. I really like how others said "don't be the bottleneck" the component library will be left behind if it turns into that. Encourage contributions. Share your roadmap. Encourage incremental and experimental components so that people can share less refined components. Finally clearly indicate what isn't shared and what it will take make something "shared".

I think getting too bogged down in reusability of lots of things is eventually the downfall of component libraries. Additionally, "too much categorization" is also problem. Atomic design for instance is great but I feel like it's a concept to teach designers how to think about componentization and for engineers it actually ends up getting in the way.

If it's going about 70% well at that point, the thing to take it to the next level is to collaborate with design leaders to get them to hold their designers accountable for matching to the design system. They may end up needing to recreate a version of those components in something like figma. If there isn't support for this, the whole system will be a pain till the end of time.






Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: