# Compose a DASH interface

Use this reference for implementation and component selection. Start from the actual task and approved design, then read the component pages needed for that work.

## Choose the interaction before its appearance

| User need                                   | Documentation to inspect                                                                                                                                                       |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Enter and validate information              | [Forms](https://hash.design/patterns/forms.mdx), [Form](https://hash.design/components/form.mdx), and the relevant input component.                                            |
| Save or submit work                         | [Saving](https://hash.design/patterns/saving.mdx), [Button](https://hash.design/components/button.mdx), and [Error handling](https://hash.design/patterns/error-handling.mdx). |
| Filter or sort a collection                 | [Filtering and sorting](https://hash.design/patterns/filtering-sorting.mdx), then Select, Combobox, or Menu as appropriate.                                                    |
| Reveal detail or request confirmation       | [Progressive disclosure](https://hash.design/patterns/progressive-disclosure.mdx), then Dialog, Drawer, or Popover.                                                            |
| Explain an in-progress or absent result     | [Loading](https://hash.design/patterns/loading.mdx) and [Empty states](https://hash.design/patterns/empty-states.mdx).                                                         |
| Communicate a result or recoverable problem | [Notifications](https://hash.design/patterns/notification-messaging.mdx).                                                                                                      |
| Arrange a screen                            | [UI layout](https://hash.design/patterns/ui-layout.mdx) and [Responsiveness](https://hash.design/foundations/responsiveness.mdx).                                              |

Resolve exact component names and import paths from the [Components directory](https://hash.design/components) and the installed package. Prefer an application wrapper when it already implements the required behavior. A component label in a prototype or a related-components list is not proof of an export. For an unavailable component, explain the gap and use a supported composition if it meets the task; otherwise propose a specific alternative.

Published component Markdown may contain JSX demo references. Read the baked-in example code, local declarations, and corresponding stories when the text alone does not establish usage. Preserve the compound-component structure and state callbacks shown by that version.

## Compose with tokens

Use semantic foreground, background, and border roles for interface content. Raw palette steps belong in deliberate palette previews or brand artwork; an arbitrary fixed hex value should not substitute for a theme-aware role. Verify actual contrast, including muted text and status colors.

Use the shared spacing, radius, shadow, type, and duration scales when the design calls for them. Density and available width are separate concerns. The reference preset leaves named viewport breakpoints to the consuming application: inspect its configuration before using names such as `md` or `lg`. Retain readable DOM and focus order when a layout changes.

For custom motion, start from the component's behavior and shared duration tokens. Respect `_motionReduce` or the corresponding media query. Keep meaningful status visible in the still state; give repeating demonstrations a pause control and stop unnecessary animation offscreen.

## Keep the complete task usable

- Give controls visible labels or suitable accessible names. An icon-only button needs a name; a tooltip alone does not establish that name. Decorative icons should stay out of the accessibility tree.
- Preserve keyboard and focus behavior when wrapping a component. Confirm how a dialog opens, closes, and returns focus, and how a menu or selection control handles its documented keys.
- Decide which component or parent owns controlled state. Connect real values, callbacks, validation, and disabled or pending behavior. A convincing static example is not a working interaction.
- Preserve entered values when validation or a request fails. Show the next useful action, and keep loading, empty results, and errors distinct.
- Use native navigation and action semantics. Verify important actions with a keyboard and touch; essential behavior cannot depend on hover alone.
- Handle long labels, dense content, and narrow widths. Contain genuinely two-dimensional content without making the whole page scroll sideways.

## Research and brand boundaries

Verify that the installed package implements any proposed behavior before relying on it. A styling token or “verified” label does not enforce permissions. Preserve the application's actual authorization and confirmation logic. Make unsupported research concepts explicit when asked to prototype them.

Use the appropriate [brand assets and terms](https://hash.design/brands.mdx). Keep the product's identity and approved design rather than copying the documentation site's layout into every application. Licensed font files and other restricted assets are not supplied by this skill.