Catalog / Components
Component quality
checklist.
A reusable review path for making UI components clearer, more responsive, and easier to hand off.
Structure before style
Good components start with layout discipline. Use frames, grids, containers, and consistent spacing before adding color or decoration.
- Use predictable margins, gutters, and columns for desktop and mobile.
- Keep component internals organized with padding, gaps, and alignment rules.
- Make row grids and spacing tokens support dense screens such as tables and dashboards.
- Design for resizing: stack, wrap, fill, and hug behavior should be intentional.
Visual depth
Gradients, shadows, borders, and tonal palettes should explain grouping and depth. They should not make the interface harder to scan.
- Use shadows to show elevation, not to decorate every card.
- Keep gradients subtle enough that text and controls remain readable.
- Use borders when separation matters more than depth.
- Document color, shadow, border, and radius decisions in the style guide.
Action components
Buttons, forms, search, filters, and sign-up flows carry user intent. Their labels, states, errors, and spacing need more care than decorative UI.
- Write button labels as outcomes, not vague commands.
- Separate primary, secondary, destructive, loading, disabled, hover, focus, and success states.
- Keep form labels visible and pair validation with recovery instructions.
- Make filters and search show what changed, how many results remain, and how to reset.
Product patterns
Dashboards, pricing, carts, modals, pagination, tabs, and navigation bars are not isolated pieces. Each one must help users compare, decide, continue, or recover.
- Use one idea per card in dashboards and keep the action close to the metric.
- Make pricing and shopping flows easy to compare without hiding tradeoffs.
- Keep modal windows focused on one decision and provide a clear escape.
- Show active states in tabs, pagination, navigation, and multi-step flows.
Five-minute component review
- 1Can a user identify the main action in three seconds?
- 2Are all interactive states visibly different?
- 3Does the mobile version preserve the same task, not just the same pixels?
- 4Can the component handle empty, loading, success, warning, and error states?
- 5Is the component documented well enough for another designer or developer to reuse it?