The first useful component in a project usually isn’t clever. It’s a button, a link, or a little layout pattern that was about to be written for the third time.

I try to let repetition tell me where the system wants to be. When I abstract too early, I often end up designing for possibilities that never happen.

Give patterns a clear home

A few shared tokens for color, spacing, and type can do a surprising amount of work. They make decisions visible and give the team somewhere to start when a page needs to change.

Components should be small enough to understand, but complete enough to be useful. I prefer a clear API with a few intentional options over a prop for every imaginable variation.

Document the decisions

A short example is often better than a long explanation. Show the default state, the most common variation, and the situation the component is designed for.

As the product grows, the system should grow with it. That means revisiting decisions instead of treating the first implementation as permanent.

Thanks for reading.
— Yang