☼
☽
Back

APRIL 23, 2026

Patterns as the shared UX Engine

A simple mental model from my experience scaling UI across multiple teams: think of the UI stack as three interconnected sub-systems with clear responsibilities and clean contracts. Inspired by systems thinking and atomic design, it builds from small to large while making Patterns the home for reusable, stateful UI behavior.

The three systems that keep UI scalable

When UI systems grow, complexity doesn’t come from “more components”, it comes from unclear boundaries: who owns what, where state should live, and how shared decisions evolve without slowing teams down.

This mental model is to treat UI as three interconnected sub-systems, each with a different job and a different kind of contract:

This separation keeps the system scalable in two directions at once: it preserves consistency at the edges, so shared UI remains coherent as it spreads across teams and surfaces, and it enables speed at the surface, so feature teams can ship product work quickly without repeatedly reinventing interaction logic.

What follows is a diagram of how these sub-systems relate, not as a rigid hierarchy, but as a living system with clear ownership boundaries and feedback loops.

The system in practice: Banner

The context: As more teams needed in-product banners, we used this model to standardize UI and interaction patterns while keeping business logic in feature code. This reduced duplication and kept the UX consistent.

The process: The pattern was developed collaboratively through a structured approach:

  • 1. Audit

  • 2. Scenario mapping

  • 3. Pattern definition (design the contract)

  • 4. Source of truth (centralize and document in Storybook)

  • 5. Rollout (adopt at the feature layer)

Banner documented in Storybook

The component exposes a clean, higher-level API. Consumers configure it through props (heading, description, actions, background pattern) without managing any internal state.

Agent-ready by design

AI agents navigating and operating products on behalf of users aren’t a distant edge case. These systems are designed around one principle: consumers only need the Patterns System API, not its internals. That same principle is what makes the architecture agent-ready: agents thrive on clean, stable contracts.