---
title: "Chunking"
source: "/reference/chunking"
description: "Information becomes easier to process when related pieces are organized into meaningful units that can be understood as one structure."
---
# Chunking
Information becomes easier to process when related pieces are organized into meaningful units that can be understood as one structure.
### Principle
Information becomes easier to process when related pieces are organized into meaningful units that can be understood as one structure.
### Why it matters
People rarely process a complex interface as an unstructured list of individual details. They build larger units: an address, a plan, a filter group, a table row, a billing section. Good chunking reduces the number of independent items that must be held in mind and exposes the structure of the task. Arbitrary grouping creates the opposite effect because users must first decode why items were grouped together.
### Deeper design interpretation
Chunking reduces the number of independent relationships users must manage at once. A well-formed chunk gives several details a shared meaning: an address becomes one concept, a billing section becomes one task, a row becomes one record. The interface helps users reason in units closer to the domain instead of individual controls.
Effective chunks are semantic rather than merely visual. Two columns do not automatically form two meaningful groups. Likewise, splitting a form into many cards can increase navigation and scanning cost if the sections do not correspond to recognizable sub-tasks.
Layr should ask whether the grouping helps users answer a question, make a decision, or complete a coherent piece of work. The best chunk often has a useful name that a user would naturally use.
### What the agent should reason about
Inspect headings, labels, data relationships, sequence, and repeated task boundaries. Determine whether the grouping reduces the amount of context the user must carry forward. When groups are arbitrary, the agent should recommend reorganization around user concepts rather than simply adding more containers.
Chunk boundaries should also survive responsive layout changes. A desktop grid may create obvious groups that disappear when stacked on mobile.
### Common failure patterns
- Long settings pages mirror implementation modules instead of user concepts.
- Related comparison values are separated across distant panels.
- Mobile stacking removes the visual boundary between sections.
- A section heading describes only half of the controls beneath it.
- Every field becomes its own “chunk,” producing fragmentation without reducing mental work.
### Audit questions
- Can each group be named in the user's language?
- Does the chunk correspond to one decision, object, or sub-task?
- Are relationships easier to understand inside the chunk than outside it?
- Does responsive reflow preserve the same conceptual structure?
### Example agent finding
> **Medium — Notification settings are grouped by backend channel instead of user intent.** Email, push, and SMS controls are separated into three cards, forcing users to reconcile the same alert type across distant sections. Group by notification purpose first and expose channel choice within each group so each chunk corresponds to one user decision.
### Agent directive
> Group information around meaningful concepts or sub-tasks. Prefer chunks that match the user's mental model and can be named clearly.
### Apply this when
- Long forms, settings, onboarding, documentation, dense dashboards, tables, command palettes, menus, and multi-step flows.
### Observable signals
- A long flat list contains items with obvious conceptual subgroups.
- Users must compare distant values that belong to the same decision.
- A section contains so many independent controls that its heading no longer describes one coherent idea.
- Groups exist only because of layout columns rather than semantic relationships.
- A mobile layout destroys grouping that was clear on desktop.
### Recommended actions
- Create sections around concepts users can recognize and name.
- Keep a chunk internally coherent and avoid mixing unrelated decisions.
- Use headings, spacing, and containers proportionally to the strength of the grouping.
- Preserve chunk boundaries when responsive layouts reflow.
### Do not over-apply
More sections are not automatically better. Excessive fragmentation forces users to navigate artificial boundaries. A chunk should reduce mental organization work.
### Example
**Weak:** A settings page lists 28 toggles in one continuous column sorted by implementation order.
**Stronger:** Controls are grouped by notifications, privacy, billing, and workspace behavior, with each section containing related decisions.
### Evaluation notes
- **Default severity:** Medium for complex tasks; low for short content.
- **Typical confidence:** High when semantic groups are inferable from labels and data.
- **Primary evidence:** Headings, DOM sections, field semantics, spacing, task sequence.
- **Related rules:** Cognitive Load, Working Memory, Law of Proximity, Law of Common Region
### References
- [Laws of UX — Chunking](https://lawsofux.com/chunking/)
## Related rules
- [Cognitive Load](/__layr/pages/reference/cognitive-load.md)
- [Working Memory](/__layr/pages/reference/working-memory.md)
- [Law of Proximity](/__layr/pages/reference/law-of-proximity.md)
- [Law of Common Region](/__layr/pages/reference/law-of-common-region.md)
## Agent guidance
Review criteria, the finding contract a report must use, and worked examples.
Established principle; Layr interpretation and agent guidance. Category: Memory & Cognition.
## Retrieve
- Canonical page: https://layr.design/reference/chunking
- Markdown for agents: https://layr.design/__layr/pages/reference/chunking.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "chunking"
title: "Chunking"
category: "Memory & Cognition"
origin: established
canonical_url: "https://layr.design/reference/chunking"
principle: "Information becomes easier to process when related pieces are organized into meaningful units that can be understood as one structure."
directive: "Group information around meaningful concepts or sub-tasks. Prefer chunks that match the user's mental model and can be named clearly."
applies_when:
- "Long forms, settings, onboarding, documentation, dense dashboards, tables, command palettes, menus, and multi-step flows."
observable_signals:
- "A long flat list contains items with obvious conceptual subgroups."
- "Users must compare distant values that belong to the same decision."
- "A section contains so many independent controls that its heading no longer describes one coherent idea."
- "Groups exist only because of layout columns rather than semantic relationships."
- "A mobile layout destroys grouping that was clear on desktop."
audit_questions:
- "Can each group be named in the user's language?"
- "Does the chunk correspond to one decision, object, or sub-task?"
- "Are relationships easier to understand inside the chunk than outside it?"
- "Does responsive reflow preserve the same conceptual structure?"
recommended_actions:
- "Create sections around concepts users can recognize and name."
- "Keep a chunk internally coherent and avoid mixing unrelated decisions."
- "Use headings, spacing, and containers proportionally to the strength of the grouping."
- "Preserve chunk boundaries when responsive layouts reflow."
avoid_when:
- "More sections are not automatically better. Excessive fragmentation forces users to navigate artificial boundaries. A chunk should reduce mental organization work."
common_failure_patterns:
- "Long settings pages mirror implementation modules instead of user concepts."
- "Related comparison values are separated across distant panels."
- "Mobile stacking removes the visual boundary between sections."
- "A section heading describes only half of the controls beneath it."
- "Every field becomes its own “chunk,” producing fragmentation without reducing mental work."
evidence_types:
- "Headings"
- "DOM sections"
- "field semantics"
- "spacing"
- "task sequence"
default_severity: "Medium for complex tasks; low for short content."
typical_confidence: "High when semantic groups are inferable from labels and data."
related_rules:
- { id: "cognitive-load", title: "Cognitive Load", url: "https://layr.design/reference/cognitive-load" }
- { id: "working-memory", title: "Working Memory", url: "https://layr.design/reference/working-memory" }
- { id: "law-of-proximity", title: "Law of Proximity", url: "https://layr.design/reference/law-of-proximity" }
- { id: "law-of-common-region", title: "Law of Common Region", url: "https://layr.design/reference/law-of-common-region" }
```
## What to reason about
Inspect headings, labels, data relationships, sequence, and repeated task boundaries. Determine whether the grouping reduces the amount of context the user must carry forward. When groups are arbitrary, the agent should recommend reorganization around user concepts rather than simply adding more containers. Chunk boundaries should also survive responsive layout changes. A desktop grid may create obvious groups that disappear when stacked on mobile.
## Routing
Route a review here when the user must remember, infer, translate, reconcile, or reconstruct information. These rules are especially relevant when the system already possesses context that the interface fails to expose.
## Review procedure
For every finding:
1. Identify the exact component, state, route, or interaction.
2. State the observable evidence.
3. Name the principle that applies.
4. Explain the user consequence in the current context.
5. Estimate severity from the consequence, frequency, and reversibility.
6. Recommend the smallest change that addresses the issue while preserving the product's existing design system.
7. Lower confidence when intent, frequency, audience, device, or product constraints must be inferred.
8. Do not produce generic advice such as "improve hierarchy" or "make this clearer" without specifying what is wrong and why.
## Finding contract — emit exactly this shape
```yaml
finding:
rule_id: string
location: string
evidence:
- observable fact
impact: string
severity: low | medium | high | critical
confidence: low | medium | high
recommendation:
change: string
rationale: string
preserve:
- existing design-system behavior
- valid product constraints
```
## Example finding for this rule
Medium — Notification settings are grouped by backend channel instead of user intent. Email, push, and SMS controls are separated into three cards, forcing users to reconcile the same alert type across distant sections. Group by notification purpose first and expose channel choice within each group so each chunk corresponds to one user decision.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html
SettingsAccount
Settings
notify.email_alerts
acl.profile_visibility
billing.invoice_email
team.invite_default
notify.weekly_digest
export.data_request
notify.desktop_push
billing.copy_to_owner
acl.search_indexing
team.seat_autofill
18 more settings · ordered by moduleOne list · four unrelated concepts · implementation labels