Lightweight text-based notation connects interface screens/pages/states with listed affordances ("affordances” are the parts of the interface that users can interact with, such as buttons, fields, and other interactive elements) in each so you can quickly see the macro relationships before worrying about how affordances and other elements must be placed in the interface. Screens/states are places you get to always via some affordance.
An Interaction Schematic is a UI shorthand that distinguishes between affordances in the interface and actions in the code. Because the columns show the interface endpoints, the arrow labels are available exclusively to explain what happens between what the users see. Additionally, you can also switch to the system language. We can do this below the captured affordances to call out technical complexities under the surface of the design to find time bombs and get a bit more precise about the circuit.
Wiring up affordances and places/screens this way early on communicates critical interaction patterns at the right level of abstraction. With a detailed flow (e.g., a Figma file), we just see boxes. When we zoom in, we see a lot of detail, but only about one place. With an Interaction Schematic, we can see all the parts and how they are connected, and easily iterate our way to the right circuit.
You can use digital sticky notes with connection lines in an online collaborative whiteboard. You can use one color for screens/states (orange), another for affordances (yellow), and one more for system language (red).
Two Advanced Techniques:
Partials: Sometimes there are too many affordances to list under a single screen. When you need to list all the affordances on a screen, indicate that the same affordances repeat in each row, or distinguish the affordances for navigation from the topic row affordances, prepend the _affordance with an underscore (“_”).
A solid line to separate alternate actions: For example, there's only one login screen, but there are multiple possible actions (affordances) on that screen. The line appears above each additional affordance. Think of it as "or". When there are multiple actions, the arrows point from an action to a new screen.
**A NOTE ON SYSTEM LANGUAGE:**
**Definition:** System Language is the internal vocabulary, logic, and structural naming used in a product’s implementation—how things are defined, composed, and rendered in the codebase or design system. Unlike user-facing text, System Language reflects the real architecture beneath the surface. It’s the raw material of product construction.
**Purpose:** Using System Language during early-stage work, like shaping or framing, anchors abstract ideas in technical reality. It helps teams uncover hidden complexity, validate assumptions, and spot potential risks before metastasizing into late-breaking surprises or costly refactors. Let devs in a shaping session know they own those red cards for any given screen/state.
**How It’s Used:**
- **Affordance-to-implementation mapping:** For any new UI element or interaction, ask: *What does this correspond to in the current system?* Is it a known component, a new variant, or a fresh path in the logic?
- For example:
- UI affordance: “Tap to Pay”
- System Language: `initiateApplePaySession(amount, breakdown, metadata)`
- **Probing for hidden complexity:** Use implementation-oriented questions to surface edge cases and integration risks. As questions like:
- *How is this condition defined in code?*
- *What data structures or states are involved?*
- *Does this hook into existing flows or create new logic branches?*
- **Clarifying types of unknowns:** Distinguish between:
- Questions you can answer in the room (e.g., by reading source or scanning schemas)
- Questions that require follow-up (e.g., spiking, pairing, deeper investigation)
- **Moving beyond yes/no feasibility:** The goal isn't just to ask *“Can we build this?”* but to arrive at a partial diagnosis: What’s known, what’s murky, and what needs work? Even rough findings inform better decisions than blind optimism.
**Why It Matters:** Bringing System Language into early discussions gives product, design, and engineering teams shared traction. It prevents wishful thinking, exposes integration risks early, and builds shared understanding of cost and structure, not just possibility. By grounding creative ideas in technical truth, teams shape work that’s not only ambitious but also executable.