The OSBR Handbook
Sign in

Interaction Design

This is the standard OSBR holds interaction design to, and the consistency companion to the Design Guidelines: the interactive behaviour of a component — how it loads, fails, empties, succeeds, and responds to the keyboard — is defined once, before the second screen is built, and reused everywhere. A user should learn the product a single time. When they have learned what a loading state looks like, what an error says and where, what an empty list offers, and which key dismisses a thing, that knowledge MUST carry to every other screen unchanged. Any screen that behaves differently forces the user to re-learn, and re-learning is a tax the design levied instead of paying itself.

We do not invent our own interaction conventions per screen. We stand on named, published practice — the Nielsen Norman Group's consistency and standards heuristic, the major design systems (Google Material, IBM Carbon, Shopify Polaris, Atlassian) that codify component states, and the W3C WAI-ARIA Authoring Practices for keyboard interaction — and apply them as a single shared standard rather than a per-screen decision. This page is the consistency companion to UI That Requires No Manual (that page makes one screen explain itself; this page makes every screen explain itself the same way), to Modeless Design (a consistent exit gesture only helps if it is the same gesture everywhere), and to Accessibility (keyboard and focus consistency is where these standards meet).

Interaction design is where OSBR's values become something the user can feel. Be Nice: define the standard early and write down every deliberate exception, so the next builder inherits the convention instead of guessing at it. Be Kind: the payoff is literal — the user learns the product once, not once per screen; it is unkind to make someone who mastered one screen feel lost on the next because the same button now sits elsewhere, the same error now speaks differently, or the same key now does nothing. Be Strong: refuse to let the second screen freelance its own loading spinner because a shared one was not ready yet.

How to read this policy

1. Goal

The goal is a product the user learns once, not once per screen. Every interactive component behaves predictably: the same state looks the same, the same action produces the same result, and the same key does the same thing, no matter which screen it appears on. The user builds one mental model early and spends it everywhere.

The root idea is the Nielsen Norman Group's fourth usability heuristic, consistency and standards: "users should not have to wonder whether different words, situations, or actions mean the same thing." A product that answers that question differently on each screen makes the user carry a separate rule for every page. A product that answers it once lets a habit formed on screen one transfer, untouched, to screen fifty. This is why the standard must be set before the second screen — the first screen alone establishes no convention; the second is where consistency is either won or permanently lost, because every later screen copies whichever way the divergence went.

2. Responsibility

Whoever builds the interactive layer owns its consistency with the rest of the product — not just its correctness in isolation. Concretely, that person or pair MUST:

This is not a hand-off to a separate "design system" team who reconcile the screens at the end. The person building the second screen is the person who either upholds the convention or records the break, because those are the same decision made at the same moment.

3. Practices

3-1. Define the four interactive states once, before the second screen

Every component that fetches, shows, or accepts data lives in four interactive states, not one. The major design systems all treat these as first-class, named things to be designed deliberately — not incidental moments. IBM Carbon documents empty states and loading/skeleton states as reusable patterns; Shopify Polaris ships a Skeleton content set and empty-state guidance; Atlassian's Design System codifies empty state and messaging patterns; Google Material specifies loading indicators and progress indicators. The point OSBR takes from all four: the states are components, defined once, not decisions re-made on each screen.

State What it must do, identically everywhere Grounded in
Loading Same indicator, same placement, same threshold for showing it — a shared skeleton or progress component, not a per-screen spinner Material loading, Carbon loading, Polaris skeleton
Error Same tone, same structure (what happened + what to do), same placement relative to cause Carbon / Atlassian messaging patterns; see self-explanatory-ui §3-3
Empty Same layout, same "here's the first action" shape, on every empty collection Carbon empty states, Polaris empty states, Atlassian empty state
Success Same confirmation mechanism (toast, inline, banner) for the same class of action, everywhere Material / Polaris feedback guidance

One screen can look however it looks — there is nothing yet to be consistent with. The second screen is where the product either reuses the first screen's behaviour or forks it. If the shared states are not defined by the time the second screen is built, the fork happens by default, and every later screen inherits the inconsistency. Define first, build second.

3-2. Same state, same signal — no per-screen dialects

Consistency and standards (NN/g heuristic 4) is violated not only by different words but by the same situation signalled differently. A user who learns that a green toast means "saved" should never meet a green inline banner meaning the same thing two screens later, or a silent success a screen after that. The signal for a state is part of the product's vocabulary, and a vocabulary with synonyms is a vocabulary the user cannot trust.

Every time the same meaning wears a different costume, the user has to stop and check whether it really is the same meaning. That hesitation is the exact cost heuristic 4 exists to remove. One signal per meaning, product-wide, is what lets recognition replace re-checking.

3-3. Standardise keyboard interaction to the ARIA Authoring Practices

Keyboard behaviour is the most invisible place inconsistency hides and the most punishing place to get it wrong — a keyboard or screen-reader user navigates entirely by learned key conventions, so a component that binds keys its own way strands them. The W3C WAI-ARIA Authoring Practices Guide (APG) publishes the keyboard interaction contract for every common pattern — menu, dialog, tabs, combobox, listbox, disclosure, and the rest. OSBR adopts the APG's keyboard model as the standard rather than deciding key bindings per component; this is the interaction side of Accessibility.

The APG exists precisely so that every product's menu, dialog, and tab list behave the same way — a user's keyboard knowledge is portable between products because of it. Diverging inside a single product is worse than diverging between products: it breaks the one place the user was entitled to assume consistency. Adopt the published contract; do not author a private one.

3-4. Reuse the system, and record every deviation in the interaction notes

Consistency is not sustained by willpower on each screen — it is sustained by a shared system that makes the consistent thing the easy thing, plus an honest record of where reality had to depart from it. Every mature design system pairs reusable components with documented usage; OSBR requires the same, including the departures.

Deviating is sometimes right — no standard anticipates everything. What is never right is deviating silently, because the next person cannot tell your considered exception from an accident, and they will propagate whichever they find. Writing the deviation down is what keeps the standard a standard: the exceptions stay countable, reviewable, and reversible.

4. What "Learn Once" Requires, Per Component

Before an interactive component is called finished, it MUST satisfy all of the following. This is the checklist the practices above add up to, and the surface the Quality Gate holds interactive work to:

Requirement The question it answers
States defined early Are loading, error, empty, and success defined as shared components before the second screen? (§3-1)
States reused Does this component use the shared states, not a re-created near-duplicate? (§3-1)
Skeleton loading Does structured content load via the shared skeleton, not a bespoke spinner? (§3-1)
One signal per meaning Does the same class of outcome use the same signal everywhere in the product? (§3-2)
Consistent error placement Is each kind of error shown in the same place relative to its cause on every screen? (§3-2)
APG keyboard contract Does the component implement exactly the keys the WAI-ARIA APG specifies for its pattern? (§3-3)
Same keys everywhere Does every instance of this pattern respond to the same keys? (§3-3)
Visible, ordered focus Is focus visible and in reading order for keyboard users? (§3-3)
System reuse Does it reuse the design system's component and tokens rather than a one-off variant? (§3-4)
Deviation recorded If it departs from the standard, is the departure written in the interaction notes with its reason? (§3-4)

A component that works in isolation but fails any row above is not finished — it behaves correctly on its own screen while quietly teaching the user that this product must be re-learned page by page.

References

Named, published practice this policy is grounded in — each a documented source an SME can adopt directly.

Consistency as a principle

Design systems: component states

Keyboard interaction

Skeleton / loading patterns

Related OSBR standards