A components value is its reuse and removes as the effort in creation and maintenance. Compound has a number of levels of component libraries but they fit the same basic criteria.
<aside> ℹ️ Does this project benefit more than one project team?
</aside>
☑️ If it does, then it should be progressed through as a component proposal.
❌ If it doesn’t it should remain as a component local to your projects.
Components are products in themselves and they require the same high-level thought process as other any other product design, as they require effort in creation and on going maintenance.
Before creating a component it is worth running through this checklist.
When proposing a new component or component update it is best to start with visual designs. Working through variations, like those needed in an annotations, really help foster discussion around edge cases.
Collaboration
It is beneficial to take these concepts to a review with team mates to check for crossover or alignment. Remember, components should benefit more than one team.
Work in Boundaries
Although tempting to think too far it is a better practice to work out what component(s) are required for immediate work. Using this as a baseline you can work through the variations that will be changing using just those properties i.e. toggling images or buttons.
Remember, components can be improved and ideated and the first release does not have to be the final answer.
A proposal is the first step to moving things forward. The proposal doesn’t have to be the final design, that is is for specification & annotation.
The proposal should be a high level summary that is shared to the Team UX channel for wider discussion and feedback.
Despite working through the design ideations with colleagues, 99% of the time the viewpoint of a developer or Product owner will highlight other requirements.