HIFDocs
HIF / Documentation / Patterns

Interface Pattern Catalogue

Version: 0.2

1. What a pattern is

A pattern is a reusable response to a recurring problem in a stated context. It is not a screenshot, component name or visual prescription.

Every production pattern MUST define:

  • problem, context and user intent;
  • relevant objects, commands and states;
  • preconditions and resulting effects;
  • accessibility semantics and input equivalence;
  • content responsibilities;
  • responsive and localisation behaviour;
  • failure and recovery;
  • evidence, limitations and known misuses;
  • acceptance tests.

Use a platform-native convention when it carries an established meaning and does not violate a stronger requirement. Novel expression MAY differentiate a brand; novel semantics require evidence.

2. Action patterns

Primary and secondary actions

A surface SHOULD have a clear action hierarchy derived from consequence and task order. Visual prominence MUST NOT misrepresent importance, safety or commercial preference.

Destructive action

Name the object and consequence. Separate destructive controls from routine actions, prevent accidental activation, confirm proportionately and offer undo or recovery where feasible.

Command menu

Use for a set of available commands, not for navigation disguised as actions. Unavailable commands require an explanation when that helps the person recover.

Batch action

Expose selection scope, excluded items, partial failure and per-object outcome. The command MUST NOT silently change scope when a filter, page or live update changes.

3. Input patterns

Text input

Use a persistent visible label. State constraints before input, accept harmless variation, preserve the entered value and connect any error to both field and summary where a summary exists.

Choice

Use radio buttons for one choice from a small visible set, checkboxes for independent choices, and a select when space or a long familiar list justifies concealment. A switch represents an immediately applied binary setting, not submission of a decision.

Date, time and quantity

Accept formats appropriate to locale and task. Explain boundaries and timezone where consequential. Do not force a calendar picker for dates more easily typed or recalled than navigated.

File upload

State accepted types, limits, security processing and progress before transfer. Support retry without discarding valid surrounding work.

Search and autocomplete

Keep typed text visible, distinguish suggestions from results and preserve keyboard control. Suggestions MUST NOT be announced or selected in a way that replaces user intent without consent.

4. Navigation patterns

A link navigates to a resource or location; a button invokes a command. Visual style MAY vary, but semantic role and expected browser behaviour MUST remain truthful.

Tabs

Tabs switch between peer views of the same context. They SHOULD NOT represent a long process, site-wide navigation or mutually dependent steps.

Breadcrumbs represent a stable hierarchy. They do not replace a back command or show arbitrary visit history.

Pagination and progressive loading

Choose pagination when stable position, sharing and deliberate traversal matter. Progressive loading MAY support exploration but MUST preserve focus, history, reachability and a route beyond the current batch.

Step flow

Use when order or dependency is real. Show current position, allow safe return, preserve work and review consequential information before commitment.

5. Disclosure and layer patterns

Accordion and details

Use for optional subordinate content, not to conceal information required for a decision. The trigger MUST expose expanded state.

Tooltip

A tooltip MAY provide brief supplementary explanation. It MUST NOT contain the only route to a command or essential information and MUST work beyond hover.

Dialog

A modal dialog is justified only when a bounded decision must interrupt the current context. It requires a name, contained focus, logical initial focus, reliable escape and focus restoration.

Popover and menu

Use for temporary, spatially related content. Define dismissal, focus and collision behaviour. A temporary layer MUST NOT obscure the trigger or focused item.

6. Feedback patterns

Inline validation

Validate when the result can help action, not merely on every keystroke. Do not report incomplete input as an error before the person has had a fair opportunity to complete it.

Progress

Use determinate progress when the proportion is known and indeterminate status when it is not. Never animate fake progress as evidence of completion.

Notification

Choose persistence and interruption according to urgency and consequence. Transient messages MUST remain available long enough and MUST NOT be the sole record of a consequential outcome.

Empty state

Distinguish first use, no matching result, cleared data, unavailable data and permission limits. Each requires different explanation and action.

7. Data-display patterns

Table

Use for comparison across shared dimensions. Provide real headers, relationships, responsive access and a non-visual means of understanding sorting and state. Do not convert structured data into inaccessible visual cards solely to fit a narrow screen.

List and card

A list expresses repeated peers. A card groups information and actions about one object. Nested interactive regions MUST remain semantically and physically distinguishable.

Dashboard

Start from decisions and exceptions, not available charts. Every visualisation MUST identify scope, units, time range, provenance and uncertainty where material.

8. Account, permission and trust patterns

Authentication

Support password managers, paste and accessible authentication. Explain recovery before it is needed. Do not use cognitive tests as the sole route to a primary function.

Permission request

Ask at the moment of need, identify the capability and consequence, provide a meaningful refusal path and explain how the choice can be changed.

Consent MUST be specific, informed and freely chosen. Necessary processing and optional preference MUST remain distinguishable. Refusal MUST NOT be hidden behind greater friction.

9. Pattern admission

A candidate pattern enters a shared design system only when it:

  1. solves a recurring evidenced problem;
  2. has defined semantics and content;
  3. passes accessibility and input review;
  4. has responsive and localisation behaviour;
  5. has automated and manual tests;
  6. states known limits;
  7. has an owner and change policy.

One-off compositions SHOULD remain local until repetition and evidence justify standardisation.

Sources