A shared date input presents the same label, help, validation, keyboard behavior, and recovery across booking and account flows.
Chapter 09 / 14
Build consistent components around behavior
Define reusable components with shared appearance, states, and access behavior.
Your goalChoose a button, input, or dialog. List its states and keyboard behavior, then name one complete task that uses it and a pattern that surrounds it.
01 / Begin with the task
The principle
A design system helps a team repeat a sound decision. Its value comes from consistent behavior and clear usage guidance as much as from consistent styling.
- Component
- A reusable interface element with a defined purpose and behavior.
- Design token
- A named value for a shared visual role, such as spacing, type, color, or radius.
- Component contract
- The states, inputs, outputs, and accessibility behavior a component promises.
Define a component from a recurring task, then specify its states: idle, focus, active, loading, success, error, disabled where relevant, and recovery. Record the meaning of labels, the keyboard behavior, and the content it accepts. Use shared tokens to keep the visual language coherent.
A pattern operates at a different scale from a component. A booking pattern may combine date input, availability display, review, and confirmation components. Choose the pattern from the user's task, then select or adapt components to fulfill its behavior.
02 / Follow a method
Apply it in four steps
- Identify a recurring task and the component's role in it.
- Write its state and keyboard contract.
- Apply named type, spacing, and color tokens.
- Test the component inside a complete workflow.
03 / Compare outcomes
Strong and weak execution
Two teams style date inputs alike while giving them different validation timing and correction behavior, so the familiar appearance predicts different outcomes.
Why the outcome changes
The strong component lets a familiar appearance predict a familiar behavior. The weak version shares styling while changing the rules of entry and correction. Compare the component contract in two complete workflows, then test the same error and keyboard path in each setting.
04 / Use the method
Practice on a real screen
Choose a button, input, or dialog. List its states and keyboard behavior, then name one complete task that uses it and a pattern that surrounds it.
Review your work
- The component has a stated task and usage condition.
- Its visual states and keyboard behavior form one contract.
- The same contract holds inside a complete workflow.
Keep your observation, interpretation, and proposed change together. Use the related patterns to inspect complete interaction states.