2 definitions in this file:

Identifies this document block as an interactions spec. The interaction steps in time order. Each item documents a single step with its trigger, description, involved components, and optional examples. Ordering is significant, so tools SHOULD keep and display steps in this order to show the sequence over time.
Min items: 1
References: interactionEntry { "kind": "interactions", "items": [ { "trigger": "User activates the 'Add to cart' button on a product card.", "description": "The item is added to the cart. The cart badge increments and a brief confirmation toast appears.", "components": [ { "identifier": "Button" }, { "identifier": "Badge" }, { "identifier": "Toast" } ] }, { "trigger": "User opens the cart drawer.", "description": "The drawer slides in from the right, focus moves to the first interactive element inside it, and the rest of the page is marked inert.", "components": [ { "identifier": "Drawer" } ] }, { "description": "The user reviews the line items and proceeds to checkout. The drawer closes and the checkout view receives focus.", "components": [ { "identifier": "Drawer" }, { "identifier": "Button" } ] } ] }
What happens during this step: the system's response, visual changes, state transitions, and user-facing feedback. CommonMark supported. What starts this interaction step: a user action, system event, or condition (e.g., 'User submits the form by activating the submit button', 'API returns a 422 response'). When omitted, the step continues the previous step's flow without a new trigger. The entities involved in this step, as entity references. Each identifier MUST match a component documented in the system; the optional role says what the component does in this step. Creates a traversable cross-reference between the pattern's interaction flow and individual component docs.
Min items: 1
Visual or interactive examples for this step: screenshots of the resulting state, screen recordings of the transition, or code snippets showing the implementation.
References: richText, entityRef, example [ { "trigger": "User submits the checkout form by activating the 'Place order' button.", "description": "The button enters its loading state and the form fields become read-only. The system validates the payment details and submits the order to the server.", "components": [ { "identifier": "Button" }, { "identifier": "TextInput" }, { "identifier": "Form" } ] }, { "trigger": "The server returns a 422 response because the billing address is incomplete.", "description": "The form exits its loading state. The offending field is marked invalid, an inline error message appears beneath it, and focus moves to the first invalid field so screen reader users hear the error.", "components": [ { "identifier": "TextInput" }, { "identifier": "InlineError" } ], "examples": [ { "title": "Inline validation error state", "presentation": { "kind": "url", "url": "https://storybook.acme.com/?path=/story/patterns-checkout--validation-error" } } ] }, { "description": "The user corrects the billing address and re-submits. The system re-validates, accepts the order, and the button returns to its loading state.", "components": [ { "identifier": "Button" }, { "identifier": "TextInput" } ] }, { "trigger": "The server confirms the order.", "description": "The system navigates to the confirmation page and announces the success message via a live region.", "components": [ { "identifier": "Toast" } ] } ]

Design System Documentation Spec (DSDS) 0.12.0 — Draft Specification

GitHub