Designing Introduction
Diwa design work is token-first: define intent in tokens, validate in components, then hand off implementation details using shared naming and accessibility rules.
Design Philosophy
- - Start with semantic tokens before local component overrides.
- - Keep interaction patterns consistent across focus, hover, and motion.
- - Prefer existing component variants before introducing one-off visuals.
- - Treat accessibility states as first-class visual states, not afterthoughts.
Workflow Pointers (Design to Dev)
- 1. Define the intent using existing Diwa token categories (theme, spacing, typography, interaction).
- 2. Prototype with existing Diwa components in your design tool or browser mocks before proposing new variants.
- 3. Validate keyboard focus, contrast, and responsive behavior for core states.
- 4. Hand off using token names, component names, and explicit state behavior notes.
Design Files and Handoff Guidance
- - Use your team's Diwa design source file as the source of reusable components and token references.
- - Match design-layer naming to Diwa token names in src/global/app.css to reduce translation errors.
- - Include state specs in handoff: default, hover, focus-visible, disabled, error/success, and reduced-motion behavior.
- - Link the corresponding component docs tabs (Usage + Accessibility + API) in each handoff note.
Component-to-Token Entry Points
| Design Decision | Styles Entry | Component Entry |
|---|---|---|
| Theme and semantic colors | /styles/theme | /components/button/configurator |
| Spacing and density | /styles/spacing | /components/input-text/configurator |
| Typography hierarchy | /styles/typography | /components/text/configurator |
| Focus-visible behavior | /styles/focus | /components/switch/accessibility |
| Hover and pointer behavior | /styles/hover | /components/tabs/examples |
| Motion and reduced motion | /styles/motion | /components/toast/examples |