Components and interaction states
Components repeat across an interface; states explain what is happening. Real tasks require more than a successful screen, including loading, empty results and failure recovery.
Give shared components stable behavior
Buttons, inputs, lists, navigation and notices need consistent meaning and feedback. Reuse allows people to learn behavior once and teams to improve repeated quality problems centrally.
Explain waiting and empty results
Loading indicates work is in progress, while empty data needs a reason and a useful next step. Missing permission, no matches and information that has never been created are different situations.
Make failure recoverable
Explain where an error happened, what remains saved and whether retrying is appropriate. For uncertain external actions, check the actual outcome before retrying to avoid duplicate operations.
Use states to check completeness
Relevant checks include normal, loading, empty, error, success and forbidden states. A demonstration state proves that an interface can display it, not that production access controls or a backend exist.