Name every state
Loading, empty, stale, denied, failed, completed, and recovery states belong in the interface contract before polish begins.
Interface behavior patterns
Small interfaces should make every important state obvious.
SmolUI turns one interaction at a time into a state map, annotated pattern, and acceptance check that a builder or reviewer can use before choosing a framework.
Make consequences visible
Labels, confirmation, reversal, and escalation should match what an action changes and who will feel the result.
Review without a framework
Each pattern ends with technology-neutral acceptance checks for content, focus, status communication, and backend boundaries.
Latest guidance
Recently published
consequential-actions
Separate Approve, Reject, and Request Changes
Specify approval outcomes by consequence, reason rule, resulting state, and next owner instead of relying on button order.
consequential-actions
Show Bulk-Action Scope Before Changing Many Records
Make selected, visible, filtered, eligible, skipped, and failed records explicit before and after a bulk action.
consequential-actions
Should a Destructive Action Use Confirmation or Undo?
Choose confirmation, review, delay, or undo from the actual consequence and recovery contract—not from a universal delete-dialog rule.
Publishing next
The first reporting tracks
- Distinguish empty, filtered-empty, unavailable, and not-loaded lists
- Show stale data honestly after a refresh failure
- Specify queued, running, cancelling, completed, and failed jobs
- Review inline-save conflicts before overwriting newer work
About this publication
A small UI still carries real operational consequences.
SmolUI publishes compact interface specifications for builders and reviewers. It focuses on visible behavior and acceptance criteria, not component-library promotion, frontend authorization claims, or generic visual inspiration.