Amanoba Logo
Back to Course

Think in Components, Not Pages

Day 16 of 30 · The Playbook 2026 – Masterclass for Designers

Design in component APIs—states, boundaries, usage rules—instead of one-off pages.

Learning Goal

  • Define component API: required/optional props, events, states.
  • Set responsibility boundaries: what it does and does not do.
  • Usage rules: where it must not be used.
  • Document good/bad examples.

Why This Matters

  • Page-centric work creates duplication.
  • Components give reuse and consistency.
  • Clear API keeps the system stable.

Explanation

  • API: props, events, states.
  • Responsibility: what it never does (e.g., Card does not fetch data).
  • Docs: examples + “don’t use here”.

Examples

Bad: Every page builds a unique card.

Good: Card with API, states, documented limits.

Guided Exercise

  1. Pick a UI element (card, input group); write its API.
  2. List states (hover, focus, error, loading).
  3. Write prohibitions (where not allowed).

Independent Exercise

Document the component API in the Playbook with Figma/Storybook links.

Self-Check

  • API written.
  • States mapped.
  • Ban list exists.

Optional Deepening