Compose supported controls into tasks with clear state ownership and recovery.
A pattern connects controls, content, and application behavior so that people can complete a task. Choose a pattern by the outcome people need, then decide which components support each step. A catalog component supplies a specific interface contract; a pattern also needs decisions about data, timing, and recovery.
| User task | Guidance |
|---|---|
| Act on an item or confirm a consequence | Common actions, Dialogs |
| Understand why a value or action cannot change | Disabled states, Read-only states |
| Enter information or access an account | Forms, Login |
| Work with text | Text toolbar |
| Find or reveal information | Search, Filtering, Disclosures |
| Understand waiting, absence, or an outcome | Loading, Empty states, Notifications, Status indicators |
| Navigate and use changing space | Global header, Overflow content, Fluid styles |
Start with the smallest composition that supports the task. A save workflow might use TextField for the value, Button for submission, and Banner for a failed request. Add a Dialog only when a decision warrants interruption. Do not add a modal merely because the operation is asynchronous.
Component names do not imply a complete service. Form supplies grouping; the application supplies submission. TextEditor provides text entry; the application supplies editing commands. Authentication, notification delivery, and search indexing are separate application capabilities.
Figure in preparation
Overview: interaction sequence
The boundaries between controls, application work, and recovery.
Assign an owner to each transition. For example, Button emits an action, but it does not await a save request or set its own loading state. The application connects that event to its operation, updates the interface, and handles failure.
Specify initial, editing, waiting, successful, failed, and cancelled states where they apply. Keep empty results distinct from a failed request. Describe which data remains available after an error and whether retry repeats or resumes the operation. An action labeled “Undo” needs an implemented reversal, not just a dismissed message.
Avoid duplicating the same state across competing surfaces. If a page already explains an error next to the affected field, use a summary only when it helps people locate or resolve that error.
Use the same names for the same entities and actions throughout the task. State the consequence before a consequential action and describe the result after completion. Keep essential help visible.
Review the full keyboard sequence, accessible names, focus after updates, announcements, and enlarged text. Test both themes over the actual backgrounds. Component semantics support this work but do not establish that the assembled task is accessible.
Use the component catalog for supported APIs. Review controlled state before connecting values, and Designing with Liquidify for the visual hierarchy.