HIFDocs
HIF / Documentation / Meaning

Content and Information Architecture

Version: 0.2

1. Position

Content is part of the interface, and information architecture is part of the product model. Neither is a final layer of copy applied to completed screens.

A person MUST be able to form a useful answer to four questions:

  1. Where am I?
  2. What is here?
  3. What can I do?
  4. What will happen next?

2. Domain model before navigation

Define canonical objects, relationships, lifecycle states, ownership, permissions and vocabulary before defining menus. Navigation is a projection of this model for a task and audience; it is not the model itself.

For every content type record:

  • stable identity and URL policy;
  • owner and authoritative source;
  • intended audience and user need;
  • creation, review, expiry and archival states;
  • security, privacy and accessibility constraints;
  • available commands and related objects;
  • search and discovery metadata.

3. User needs and top tasks

Each important page MUST serve an evidenced user need or an operational obligation. A need statement SHOULD describe the situation, intended outcome and reason without prescribing the interface.

Top tasks MUST receive priority in navigation, content maintenance, performance budgets and testing. Organisational structure MUST NOT be imposed on users unless it matches their task model.

4. Classification and labels

A taxonomy SHOULD be:

  • mutually understandable, though not necessarily mathematically exclusive;
  • stable enough for recognition;
  • extensible without changing established meanings;
  • expressed in the audience's language;
  • testable through representative findability tasks.

Labels MUST describe destination, topic or effect. Parallel items SHOULD use parallel grammar. Internal department names, abbreviations and campaign language MUST NOT replace terms that users seek.

Controlled vocabulary, synonyms, aliases and deprecated terms SHOULD be maintained separately from visible navigation labels.

5. Navigation

Use the smallest set of navigation systems that explains the product:

  • global navigation for stable product areas;
  • local navigation for siblings within an area;
  • contextual links for meaningful relationships;
  • breadcrumbs for hierarchical orientation;
  • history and recents for temporal return;
  • search for direct retrieval;
  • task progress for ordered transactions.

Repeated navigation MUST remain consistent in relative order and identification. Current location MUST NOT be communicated only by colour. A navigation model MUST work with keyboard, zoom, reflow and assistive technology.

Do not use breadcrumbs to represent interaction history, tabs to represent a site hierarchy, or pagination to conceal a required sequence.

Search quality includes discovery, query interpretation, ranking, result comprehension and recovery.

Search SHOULD:

  • accept audience terminology and common variants;
  • preserve a submitted query visibly;
  • explain filters, sorting and result scope;
  • distinguish zero results from failure;
  • offer correction without silently replacing intent;
  • provide stable result titles, descriptions and destinations;
  • remain operable by keyboard and assistive technology.

Measure successful retrieval and reformulation, not only query volume.

7. Page and content structure

Each page SHOULD have one primary purpose, a descriptive title and a heading structure that represents content relationships. Put the information required for a decision before the action that commits it.

Write for scanning without reducing content to fragments:

  • lead with the conclusion or task;
  • use concrete verbs and nouns;
  • keep one conceptual purpose per paragraph;
  • use lists only for genuinely parallel items;
  • place conditions and exceptions beside the affected action;
  • make link text meaningful out of context;
  • disclose dates, scope and authority where currency matters.

Plain language means language appropriate to the audience, not the removal of necessary precision.

8. Forms and transactions

A form is a conversation with state, validation, recovery and consequences.

The system MUST:

  • ask only for information necessary at that stage;
  • explain unfamiliar requests and sensitive use;
  • use persistent visible labels;
  • specify required format before input where material;
  • accept reasonable human variation where it can be normalised safely;
  • preserve valid input after an error;
  • identify errors in text and associate them with fields;
  • provide a review step for consequential submissions;
  • issue an understandable confirmation and reference.

Break a transaction into steps when this reduces cognitive load or matches real dependencies, not merely to increase page views. Progress indicators MUST reflect the actual process and MUST NOT imply false certainty.

9. Empty, loading, error and completion content

Every state requires authored content. An empty state SHOULD explain what is absent, why that matters and what action is available. Loading content MUST NOT promise an outcome not yet confirmed. Error content MUST distinguish what happened, what was preserved and what to do next. Completion content MUST state the result, persistence, follow-up and evidence of completion.

10. Localisation and internationalisation

The source model MUST support expansion, different word order, plural rules, date and number formats, writing direction and culturally dependent examples. Strings MUST NOT be assembled from fragments that translators cannot reorder.

Language selection SHOULD preserve the current object and task. Locale, region, currency and language MUST NOT be treated as interchangeable. Machine translation MAY assist drafting but human review is REQUIRED for normative, legal, safety-critical or high-value transactional content.

11. Findability and machine representation

Human-oriented information architecture comes first. Metadata, structured data, sitemaps and semantic HTML SHOULD faithfully expose that architecture to browsers, search engines and assistive technology.

A URL SHOULD be stable, readable, canonical and independent of ephemeral UI state. Redirects MUST preserve established identity during migration.

Search-engine optimisation MUST NOT introduce hidden text, misleading headings, doorway pages or content that contradicts the human-visible product.

12. Evaluation

Evaluate architecture and content with:

  • content inventory and ownership review;
  • vocabulary analysis from research and support data;
  • open and closed card sorting where appropriate;
  • tree testing for findability;
  • first-click and task-completion studies;
  • search log and zero-result analysis;
  • readability and comprehension tasks;
  • accessibility evaluation;
  • localisation pseudo-testing and native review.

Successful navigation in a prototype does not by itself validate comprehension, trust or successful task completion.

Sources