A good component starts with a real mobile need: a setting row, a list item, a toolbar, a status badge, an empty state. Begin with the workflow, then design the smallest reusable pattern that supports it.
Open with the use case
Before writing code, describe where the component appears and what states it needs. Contributors and reviewers can move faster when the purpose is concrete.
- What action does it support?
- What content can change?
- Does it need loading, disabled or error states?
- How should it behave on narrow screens?
Keep the API boring
Use clear class names, predictable markup and CSS variables already present in the design system. Avoid clever structure unless it removes a real maintenance cost.
Improve an existing component example with a missing state. That teaches the project style and helps users immediately.
Document the copy-paste path
Every component should tell a developer what markup to copy, what CSS it depends on and which interaction details matter on a phone.