46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
# Design System and UI Consistency
|
|
|
|
## Purpose
|
|
|
|
Promote reusable, scalable UI patterns so the interface stays coherent as the product grows.
|
|
|
|
## When to use
|
|
|
|
- A UI area is drifting from existing patterns
|
|
- Reusable components or patterns should replace one-off implementations
|
|
- A feature adds new patterns that may affect future screens
|
|
- You want to improve consistency without a full redesign
|
|
|
|
## Inputs to gather
|
|
|
|
- Existing components, tokens, layout patterns, and style conventions
|
|
- The new or changed UI requirements
|
|
- Current inconsistencies, duplication, or local hacks
|
|
- Constraints from the stack, theme system, or design resources
|
|
|
|
## How to work
|
|
|
|
- Reuse existing components and conventions before inventing new ones.
|
|
- Introduce new patterns only when the current system cannot express the need cleanly.
|
|
- Optimize for maintainability and consistency, not just a one-screen outcome.
|
|
- Keep component APIs and styling patterns understandable.
|
|
- Document new reusable patterns when they materially expand the design system.
|
|
|
|
## Output expectations
|
|
|
|
- More consistent UI implementation or a clear plan for pattern consolidation
|
|
- Notes on reused versus newly introduced patterns
|
|
- Guidance on where the system should expand carefully
|
|
|
|
## Quality checklist
|
|
|
|
- The UI becomes more coherent, not more fragmented.
|
|
- Reuse is meaningful and does not force a poor fit.
|
|
- New abstractions are justified by repeated or durable need.
|
|
- The solution helps future features move faster.
|
|
|
|
## Handoff notes
|
|
|
|
- Note whether the work is local cleanup, reusable component work, or system-level direction.
|
|
- Pair with UX review and frontend implementation when consistency changes affect behavior and clarity.
|