INF2170H Chap.1 IA Foundations and Design Boundaries
IA Foundations and Design Boundaries
Structure content for use
Information architecture connects content structures to user needs and organisational context. This chapter separates structuring, organising and labelling, then asks what evidence can support a design claim. It treats scope as an active control on method and conclusion, not a disclaimer added after the recommendation.
Original cases show how to turn a broad complaint into a testable information problem.
Keep the claim at the evidence scale
A prototype can represent a proposed structure without proving that the structure works. A local observation can justify a local test without establishing a universal mental model.
The chapter practises naming the object, audience, evidence, method and boundary before polishing the design response.
Diagnose the layer before selecting a method
An information environment can fail at several layers. The content may be absent or contradictory. The categories may answer mixed questions. The labels may communicate the wrong boundary.
Navigation can place a useful object behind an unexpected route, while search may miss it because the description uses inconsistent terms. A strong diagnosis names the layer and proposes evidence capable of challenging the preferred explanation. Begin with at least two plausible causes.
If both could explain the observation, choose a method that separates them rather than one that merely produces more detail.
Keep user, content and organisational context together. Users bring tasks, vocabulary and prior knowledge. Content has types, relationships, quality and lifecycle. Organisations bring mission, systems, resources and authority. An architecture mediates among those conditions.
Copying an organisation chart may simplify ownership but obscure user needs; copying a participant grouping may ignore maintenance and policy. The recommendation should state which constraint is decisive and which consequence remains.
Carry the boundary into the final sentence
Every conclusion should answer four questions: what changed, for whom, on what evidence and within which limit.
Replace broad claims of intuition with the observed behaviour or structural criterion. If a local study found one ambiguous label, recommend revising and retesting that label for the sampled task. Do not claim the entire system is unusable.
If a prototype makes the proposed relationships visible, say that it demonstrates representation, then identify the user or maintenance test still required.
This habit improves transfer. When the audience, channel or content universe changes, preserve the premises that remain supported and reopen only the affected assumptions.
A desktop and voice interface can share an underlying content model while presenting different routes. Experienced staff and first time visitors can use the same records while interpreting labels differently. Controlled transfer shows which architecture layer remains stable and which requires new evidence.
What this chapter covers
- 01
Information architecture
- 02
Structuring and organising
- 03
Users, content and context
- 04
Design evidence
- 05
Claim boundaries
- 06
Method selection
Worked example · free
Frame a support site problem
- 2Define the object and audience.
- 2Separate observation from interpretation.
- 2Select a test and boundary.
Key terms
- Design Boundary
- Design Boundary states the audience, object and evidence scale within which a recommendation is defensible.
- Information Ecology
- Information Ecology describes the interdependence of users, content and organisational context.
- Structural Claim
- Structural Claim explains how a proposed relationship or route addresses an observed information problem.
IA Foundations and Design Boundaries FAQ
Why is information architecture not the same as visual design?
Information architecture focuses on content objects, relationships, labels and access routes. Visual design can clarify those decisions through layout, colour and presentation, but it does not determine the underlying categories. Evaluate each layer with evidence suited to the question instead of calling every interface problem an architecture failure.
How should a broad complaint be reframed?
Identify the audience, task, object and observable failure. Replace a statement such as “the site is confusing” with a route, label or retrieval problem that a method can inspect. List alternate explanations before selecting a test so the preferred diagnosis does not become an assumption.
What makes a design claim too broad?
A claim is too broad when it extends beyond the sampled audience, content universe, method or channel. Preserve the useful finding, narrow the conclusion and name the next test. A precise local recommendation is stronger than a universal statement unsupported by the evidence.
Assessment move
Retrieve the distinctions among structuring, organising, labelling and presentation. For each practice case, name the object, audience and evidence before proposing a method. Change one condition and locate the first inference that no longer transfers. Build a one-page comparison grid with content structure, user context and organisational context as separate columns.
Place every claim from a practice case in one column, then draw only the links that the evidence supports. If a complaint concerns wording, test whether the real defect is the label, the category boundary, the route or the underlying content. Write a precise problem statement before selecting a method, and check that the method can actually answer it.
Rehearse short explanations that distinguish an inventory, a card sort and a tree test by the uncertainty each reduces. When revising a design, preserve the original observation beside the proposed change so the reasoning remains visible. Finish each session by stating one supported conclusion, one plausible alternative and one question that requires additional evidence.
This routine keeps neighbouring disciplines useful without allowing an attractive theory to substitute for information architecture evidence.