HIF Visual Language

1. The role of visual language

Visual language expresses a semantic model; it does not create that model.

Design sequence:

meaning
→ structure
→ states
→ interaction
→ visual and auditory form

A theme MAY change the form, but MUST preserve the meaning.

2. Information architecture

Before styling begins, the following must be defined:

• objects and their relationships;
• primary user tasks;
• content hierarchy;
• persistent and contextual navigation;
• critical paths;
• empty, loading, error and success states.

Layout should not conceal the absence of information architecture.

3. Hierarchy

Hierarchy is established through a combination of:

• order;
• position;
• size;
• space;
• contrast;
• weight;
• grouping;
• motion.

An element should not be emphasised through every available visual variable unless the task requires it. Visual prominence SHOULD correspond to significance and frequency.

The primary action is determined by the task, not by a desire to maximise conversion.

4. Layout

4.1. Supporting structure

Each interface defines:

• content regions;
• navigation regions;
• work area;
• system and status area;
• transient layers;
• safe areas;
• reflow rules.

4.2. Grid

A grid is a means of coordination, not a mandatory aesthetic. It MAY be:

• columnar;
• modular;
• spatial;
• baseline;
• managed by the environment.

4.3. Space

Spacing expresses relationships. Proximate elements are perceived as related. Equivalent spacing SHOULD express an equivalent degree of relationship.

Tokens SHOULD use a limited scale, although the scale MAY vary between density profiles.

4.4. Reflow

When the available space changes, priorities are determined in advance:

1. preservation of function;
2. preservation of content;
3. preservation of context;
4. adaptation of composition;
5. reduction of secondary representation.

Scaling an entire desktop as though it were an image is not usually an adaptation.

5. Typography

5.1. Roles

A minimal typographic system includes:

• display;
• page title;
• section heading;
• body;
• interface label;
• supporting text;
• data;
• code or monospace.

A role is determined not only by size, but also by line height, weight, width and context.

5.2. Legibility and readability

The system MUST support:

• sufficient rendered size;
• text enlargement;
• distinguishable styles;
• an appropriate line length;
• wrapping of long words and technical identifiers;
• all supported writing systems;
• fallback without disruption to the layout.

Font weight SHOULD use a designed instance where available rather than synthetic weight when synthesis degrades legibility or character form.

5.3. Selecting a typeface

HIF does not mandate a single typeface for every product. The Product Profile defines:

• UI family;
• reading family;
• monospace family;
• fallback stack;
• supported writing systems;
• licensing and distribution;
• performance budget.

5.4. Technical data

Monospace is appropriate where alignment and character differentiation matter more than the texture of prose: code, hashes, identifiers, paths and terminal output. It SHOULD NOT be applied automatically to an entire “technical” interface.

6. Colour

6.1. Semantic roles

Colour tokens describe function:

• canvas;
• surface;
• text;
• muted text;
• border;
• accent;
• focus;
• success;
• warning;
• danger;
• information;
• selection.

Names such as blue500 MAY exist in the primitive palette, but component contracts MUST depend on semantic tokens.

6.2. Contrast

Contrast is evaluated for text, controls, focus, graphics and every state. Passing a test for one colour pair does not establish the accessibility of an entire theme.

6.3. Colour and state

A material distinction is also expressed through shape, text, an icon, a pattern or position. Red alone is not an error message.

6.4. Themes

A theme contract defines a complete system of foreground and background pairs and states. A dark theme cannot be produced through mechanical inversion.

Forced colours and user-defined contrast take precedence over brand fidelity.

7. Components

A component includes:

• semantic role;
• accessible-name strategy;
• states;
• commands;
• keyboard model;
• pointer and touch behaviour;
• dimensions and constraints;
• content rules;
• error, empty and loading behaviour;
• tokens;
• tests.

A screenshot of the default state is not a component specification.

A component SHOULD expose the smallest coherent unit of meaning. Decorative internal parts MUST NOT become independent product entities without a semantic need.

8. Controls and hit areas

The visible form and hit area MAY differ, but an enlarged hit area MUST NOT overlap another target unexpectedly.

Size is determined by:

• input method;
• density;
• frequency;
• risk of error;
• distance between targets;
• availability of alternatives.

A compact mode does not remove minimum operability requirements.

9. Iconography

An icon SHOULD:

• have a defined meaning;
• conform to the style of its set;
• remain legible at its intended sizes;
• have a text alternative for assistive technologies;
• be accompanied by a label when its meaning is not consistently understood.

One icon MUST NOT represent different consequential actions in adjacent contexts.

Emoji are not a reliable substitute for a system icon set because their rendering varies across platforms.

A third-party icon set requires licensing and attribution review before it is included.

10. Images, wallpaper and illustration

An image is used when it conveys content, identity or orientation. It should not:

• reduce the contrast of controls;
• imitate an interactive element;
• create a false system state;
• be the sole carrier of an instruction.

A background or wallpaper MUST accommodate an unpredictable foreground, or the system MUST provide a backplate or scrim.

11. Elevation and layers

Shadow, border, blur and z-position express a layer and its relationship to context.

Equivalent elevation SHOULD express an equivalent layer model:

• embedded;
• raised;
• floating;
• overlay;
• modal;
• critical.

Blur and transparency should not be necessary to distinguish boundaries.

12. Motion

Motion is used to communicate:

• continuity;
• origin and destination;
• changes of state;
• spatial orientation;
• acknowledgement.

A motion profile defines:

• duration ranges;
• easing roles;
• interruptibility;
• a reduced-motion alternative;
• behaviour under constrained performance.

Animation should not delay access to an outcome once it is ready. Decorative loops SHOULD be rare and capable of being stopped.

13. Sound and haptics

Sound and haptics MAY supplement:

• acknowledgement;
• warning;
• spatial cue;
• critical event.

They MUST have a visual or programmatically available equivalent, except where sound or haptic output is itself the subject of the task.

System mute, volume and reduced-feedback settings take precedence.

14. Density

Density is a geometry profile, not CSS scaling.

Typical profiles include:

• comfortable;
• compact;
• touch;
• large or accessible;
• kiosk or distance.

Density MAY change spacing and the volume of visible data, but MUST preserve:

• semantics;
• order;
• hit-area requirements;
• focus;
• legibility;
• command availability.

15. Design tokens

Recommended layers:

primitive tokens
→ semantic tokens
→ component tokens
→ environment/brand overrides

An override at a lower layer MUST NOT bypass an accessibility constraint.

A token SHOULD define:

• a purpose-based name;
• type and unit;
• permissible range;
• fallback;
• dependent components;
• contrast or geometry requirements.

16. Originality and reference

References are used to understand:

• architecture;
• behaviour;
• cultural convention;
• level of quality.

A reference does not confer a right to copy code, assets, trade dress or branding. A derived interface MUST have its own identity and verified asset provenance.