information-architecture

Name: information-architecture
Author: dembrandt

281installs5forks

How to install information-architecture?

dembrandt/dembrandt-skills/information-architecture

$npx -y skills add dembrandt/dembrandt-skills --skill information-architecture

Installs into the current project.

Summary

In large applications, information architecture determines whether users can find, understand, and act on data. Naming matters. The UI should mirror the data model and signal how data can be transformed. Dangerous or irreversible changes always require a confirm dialog. Use when

Files · 1

View on GitHub

SKILL.md

1	# Information Architecture
2
3	In small products, users find their way by exploring. In large applications — multi-module SaaS, ERPs, analytics platforms, marketplaces — exploration breaks down. The structure itself must do the navigational work. Information architecture is the design of that structure: what exists, what it is called, and how it relates to everything else.
4
5	Good IA is invisible. Users find what they need without thinking about the structure. Bad IA forces users to hold a map in their head.
6
7	---
8
9	## Naming is Design
10
11	The names given to entities, sections, and actions are one of the most consequential design decisions in a large application. Bad names create cognitive friction on every visit.
12
13	Principles:
14
15	- Use the user's vocabulary, not the engineer's. If users call it a "job", do not call it a `task_assignment`. If they call it a "client", do not surface `contact_entity`.
16	- Be specific. "Settings" is vague. "Account settings", "Workspace settings", "Notification preferences" tell the user exactly where they are.
17	- Be consistent. If it is called "Project" in the sidebar, it must be called "Project" in the breadcrumb, the page title, the confirmation dialog, and the API error message.
18	- Distinguish similar things. If the product has both "Users" and "Members", the distinction must be meaningful and consistently communicated.
19	- Name actions by their effect. "Archive" not "Hide". "Publish" not "Save to live". "Transfer ownership" not "Change user".
20
21	Naming audit questions:
22	- Would a new user understand this term without training?
23	- Is this name used consistently across every surface it appears?
24	- Does this name describe what the thing does, not how it is stored?
25
26	### Internal vocabulary is not customer vocabulary
27	The terms a company uses internally are frequently not the terms the customer should see. An internal casual shorthand ("the recon job", "a P2 ticket") is precise for the team but opaque to an outsider. When a term crosses from the internal build into the customer-facing app, translate it to the customer's word, or a universally understood one — never ship the internal shorthand by default.
28
29	- Introduce as few new terms as possible — a hard ceiling of ~10 invented terms for the whole product, and fewer is always better. Every new coined term is something the user must learn before they can act. Prefer terms so universal that the end user already knows them over anything you'd have to teach.
30	- Placement tells half the story. Where a feature sits — which section, which nav group, next to what — communicates as much as its label. A well-placed control needs less naming; a well-named control in the wrong place still confuses. Design the location and the name together.
31
32	### Label length: buttons are terse, titles continue the story
33	- Buttons: 1 word, ideally — 2 is fine, 3 is the maximum. A button is an action verb, not a sentence. "Save", "Publish", "Invite member".
34	- Titles and headings carry the fuller explanation. Let the surrounding title, section header, or help

People who liked this also viewed

6 picks

Type

information-architecture

281installs5forks

View on GitHub

How to install information-architecture?

dembrandt/dembrandt-skills/information-architecture

$npx -y skills add dembrandt/dembrandt-skills --skill information-architecture

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Information Architecture
2
3	In small products, users find their way by exploring. In large applications — multi-module SaaS, ERPs, analytics platforms, marketplaces — exploration breaks down. The structure itself must do the navigational work. Information architecture is the design of that structure: what exists, what it is called, and how it relates to everything else.
4
5	Good IA is invisible. Users find what they need without thinking about the structure. Bad IA forces users to hold a map in their head.
6
7	---
8
9	## Naming is Design
10
11	The names given to entities, sections, and actions are one of the most consequential design decisions in a large application. Bad names create cognitive friction on every visit.
12
13	Principles:
14
15	- Use the user's vocabulary, not the engineer's. If users call it a "job", do not call it a `task_assignment`. If they call it a "client", do not surface `contact_entity`.
16	- Be specific. "Settings" is vague. "Account settings", "Workspace settings", "Notification preferences" tell the user exactly where they are.
17	- Be consistent. If it is called "Project" in the sidebar, it must be called "Project" in the breadcrumb, the page title, the confirmation dialog, and the API error message.
18	- Distinguish similar things. If the product has both "Users" and "Members", the distinction must be meaningful and consistently communicated.
19	- Name actions by their effect. "Archive" not "Hide". "Publish" not "Save to live". "Transfer ownership" not "Change user".
20
21	Naming audit questions:
22	- Would a new user understand this term without training?
23	- Is this name used consistently across every surface it appears?
24	- Does this name describe what the thing does, not how it is stored?
25
26	### Internal vocabulary is not customer vocabulary
27	The terms a company uses internally are frequently not the terms the customer should see. An internal casual shorthand ("the recon job", "a P2 ticket") is precise for the team but opaque to an outsider. When a term crosses from the internal build into the customer-facing app, translate it to the customer's word, or a universally understood one — never ship the internal shorthand by default.
28
29	- Introduce as few new terms as possible — a hard ceiling of ~10 invented terms for the whole product, and fewer is always better. Every new coined term is something the user must learn before they can act. Prefer terms so universal that the end user already knows them over anything you'd have to teach.
30	- Placement tells half the story. Where a feature sits — which section, which nav group, next to what — communicates as much as its label. A well-placed control needs less naming; a well-named control in the wrong place still confuses. Design the location and the name together.
31
32	### Label length: buttons are terse, titles continue the story
33	- Buttons: 1 word, ideally — 2 is fine, 3 is the maximum. A button is an action verb, not a sentence. "Save", "Publish", "Invite member".
34	- Titles and headings carry the fuller explanation. Let the surrounding title, section header, or help

People who liked this also viewed

6 picks

Type