Audit repeated implementation first
Look for repeated markup, state handling and interaction behaviour across the application. Those are stronger library candidates than components chosen because they appear in a design-system template.
The audit also exposes inconsistencies that need a product decision before they can become reusable code.
Design component boundaries around responsibility
Small focused components are easier to compose, but splitting everything into tiny wrappers creates noise. The right boundary usually follows a stable piece of behaviour or a reusable interaction contract.
Keep APIs boring and predictable
Consumers should be able to infer how similar components behave. Consistent naming, controlled variants and composable children generally age better than large collections of special-case props.
When a new requirement appears, ask whether it is a shared pattern or only one feature needing local composition.
Build accessibility into the reusable layer
Keyboard behaviour, focus management, labels and semantic structure are ideal candidates for reuse because mistakes otherwise repeat across the product.
This does not remove the need for page-level accessibility thinking, but it raises the baseline for every screen that uses the component.
Document examples people can copy
Documentation should answer how the component is meant to be used, what states it supports and what not to use it for. Practical examples are often more valuable than exhaustive API tables.
If developers routinely bypass the library, the problem may be the API or documentation rather than adoption discipline.