Interface Design

An interface is the boundary where two systems meet—a contract that defines how they communicate, what they expect, and how they handle failure. Interface design is the practice of shaping these boundaries to be explicit, safe, and easy to reason about. It's not just about user interfaces; it's about any interaction point between components, services, or teams.

Good interface design reduces coordination cost, makes failure modes explicit, and enables operations teams to safely retry and recover. It's the difference between integrations that quietly break and systems that fail loudly and recover gracefully.

Patterns

  • Idempotent operations with durable receipts
  • Explicit failure types and recovery paths
  • Versioned contracts with compatibility windows
  • Small surface area, precise semantics
  • Observability at the boundary

Anti-patterns

  • Implicit side effects and hidden coupling
  • Retry-unfriendly commands
  • Ambiguous error responses
  • Version churn without migration paths
  • Leaky internal models

Interface Design Fault Tree

Recognize an interface design problem by its downstream symptoms.

When interface design is wrong, you don't see it right away.
In Code & Systems
  • → Hard to retry safely
  • → Fragile glue code
  • → Hidden coupling everywhere
In Operations
  • → Same incident returns
  • → Work gets stuck
  • → Must shepherd changes
In People & Teams
  • → "Ask Alice" tribal knowledge
  • → Hand-offs are slow & painful
  • → Constant mismatch of expectations
If you see these symptoms, pause and ask: "Is this an interface design problem?"

Start here with Interface Design

Recent logs using this concept

Related missions

Juphjacs Web Framework

Interface-first page framework used to make contracts explicit.

Interface Design Playbook

A mission focused on shaping boundaries and failure modes.

🔍 ⌘K or /