The best design system in the world still drifts if the people using it route around it. Using one well is not about rules; it is about a few habits that keep the system trustworthy for everyone else.
Compose, do not fork
The most damaging habit is the private fork: copying a component to make one small change. It feels faster and it is, exactly once. After that it is a permanent liability that never receives another fix or improvement from the source.
When a component does not do what you need, compose around it or file the gap. A fork solves your problem and quietly weakens the system for everyone.
Token, do not hardcode
Every raw value you type is a future drift and a screen that will not survive the next theme change. Style with semantic tokens even when a hardcoded value would be quicker, because the quick version is the one you pay for later.
If the token you need does not exist, that is not permission to hardcode. It is a gap worth reporting.
Contribute, do not route around
A healthy system has a short path from need to contribution. Use it. When you push a fix or a new variant upstream, you convert your one-off effort into a shared asset, and you keep the source of truth actually true.
The teams that get the most from a system are the ones that treat it as something they help maintain, not just something they consume.
Read the system before you extend it
Most reinvention happens because someone did not know the part already existed. Before building a new component or a new token, spend the five minutes to check what is there. The fastest teams treat the system's documentation as the first stop, not the last resort, and it saves them from shipping the third slightly different modal.
Learning the vocabulary pays compound interest. Once you know the tokens and the components by name, composing on the system becomes faster than improvising against it, which is the entire point.
A system is only as good as the habits of the people who use it. Compose, token, contribute.On using systems well