HIF / Documentation / Map

HIF Knowledge Base

Version: 0.2

1. Purpose

The HIF Knowledge Base is a maintained body of knowledge for designing, building, evaluating and governing human interfaces. It covers operating systems, applications, websites, services, documentation, administrative tools, kiosks, conversational systems, AI-mediated interaction and future interface forms.

It is not a gallery of fashionable solutions. It separates:

human capabilities and limitations;
normative rights and safeguards;
interaction and information models;
visual, content and behavioural expression;
platform and domain conventions;
implementation systems;
evaluation evidence;
legal, rights and platform-reference governance;
operational and commercial practice.

2. Knowledge architecture

Layer A — Foundations

philosophy and model of the human being;
HCI, ergonomics and human-centred design;
perception, cognition, memory, attention and motor action;
situated action, distributed cognition and activity theory;
research ethics and quality of evidence.

Layer B — Universal contract

Interface Constitution;
accessibility and inclusion;
privacy, security, safety, agency and trust;
requirements for automation and AI;
normative vocabulary and exception policy.

Layer C — Models

actors, objects, views, commands, events, state and policy;
navigation, focus, modes and input bindings;
information architecture and content;
feedback, errors, recovery and undo.

Layer D — Expression

typography, colour, space, imagery, sound, haptics and motion;
responsive and adaptive composition;
components, patterns and design tokens;
localisation and bidirectional content.

Layer E — Profiles

operating-system shell;
desktop and mobile application;
web product and transactional service;
documentation, builder, installer, recovery and kiosk;
terminal, conversational, AI, spatial, retro and white-label products.

Layer F — Engineering

design-system architecture and governance;
semantic APIs and component contracts;
content and token pipelines;
platform conventions and compatibility;
quality gates and release management.

Layer G — Evidence

formative and summative research;
analytical, automated and empirical evaluation;
test design and task corpora;
accessibility conformance;
product metrics and controlled experiments;
operational evidence.

Layer H — Professional practice

client-site audit;
reproducible findings and prioritisation;
remediation design and implementation;
acceptance, retesting and regression;
responsible claims, pricing inputs and conflicts of interest.

Layer I — Legal and rights governance

jurisdiction and distribution profiles;
intellectual-property and platform-reference controls;
asset, font, code, data and brand clearance;
independent creation and similarity review;
privacy, accessibility, consumer and sector legal gates;
release evidence, permissions, notices and change control.

3. Source policy

HIF sources MUST be traceable to an English-language original. Preferred sources, in descending order, are:

a current standard or specification issued by its governing body;
an original peer-reviewed paper or an author's original monograph;
official platform, browser or design-system documentation;
an official public-sector service manual with disclosed research practice;
an original technical report or dataset from the responsible institution.

A secondary article, translated summary, search result or unsourced checklist MAY help discover a source but MUST NOT be cited as the evidential basis of a normative HIF requirement.

The existence of a source does not make a claim universal. Every imported claim MUST record its population, task, context, date, method and limitations where these affect interpretation.

4. Claim classes

Class	Meaning	Required support
Normative	A HIF obligation	Constitution, applicable profile and test
Empirical	An observed relationship	Original study or reproducible product evidence
Platform	A convention required by an ecosystem	Current official platform guidance
Pattern	A reusable solution to a recurring problem	Defined context, forces and known limitations
Heuristic	A review prompt	Provenance plus validation in the product context
Hypothesis	An unverified product belief	Explicit success and falsification criteria
Decision	A chosen trade-off	Owner, rationale, evidence and review date

Numbers MUST NOT be presented as universal thresholds unless a standard defines them for the stated scope. Findings derived from heuristics MUST NOT be reported as conformance failures.

5. How to navigate the corpus

Start with the Philosophy and Constitution. Select an applicable Product Profile, model the product using the Interaction Model, then define information, content, Design Foundations, visual language and system components. Use the dedicated colour, typography, layout, adaptation, imagery, motion, data-visualisation and brand documents for expressive decisions, then apply Design Review and Critique. Before implementation, apply Legal, IP and Platform-Reference Governance and create the required Rights Clearance and Release Records. Plan accessibility assurance through Accessibility and Inclusion and preserve its release evidence in the Accessibility Assurance and Conformance Record. Plan evaluation before implementation and maintain traceability from a user need to requirement, design decision, implementation, test and operational evidence.

For an existing client site, begin with the Web Audit Playbook, use Test Design, report through the Audit Report Template, complete an Accessibility Assurance Record when accessibility is in scope, and verify remediation against the same task corpus and acceptance criteria.

6. Maintenance

Every document MUST state its version or inherit the corpus version. Each material change requires:

the claim or requirement being changed;
reason and evidence;
affected profiles and tests;
migration or compatibility impact;
reviewer and review date.

Sources whose content is living or versioned MUST be reviewed at least annually. Platform rules and web quality thresholds SHOULD be checked before every audit engagement.