Semiotics
Coverage
Semiotic analysis as the study of sign systems in software interfaces and communication. Covers:
- Foundational models — Peirce's icon / index / symbol trichotomy; Saussure's signifier / signified dyad; Barthes' denotation / connotation / myth layers
- Visual semiotics for interfaces — color as sign (denotation + connotation, with the never-color-alone rule), shape and position as sign channels (top-left, top-right, bottom-right, circle, triangle, pill)
- Iconography as a sign system — consistency, metaphor clarity, pairing rules, system coherence; common breakdowns (icon polysemy, opacity, cultural collision, obsolete metaphor)
- Affordance theory — real affordance, perceived affordance, signifier, anti-affordance; the rule that disabled states need a strong anti-affordance
- Code and API semiotics — naming, variable, endpoint, and error-message signs; the rule that vague names like
processData() are signifier failures even when the implementation works
- Semiotic-coherence audit — the checklist for reviewing a surface across color, icon, affordance, and cross-surface consistency
The skill operates above microcopy execution and color-token math, and below formal ontology. It owns the question "what does this sign communicate to a user?", not "what should the button say?", "what hex value is this?", or "what class hierarchy do these things belong to?".
Philosophy
Every interface element is already communicating, whether the designer intended it to or not. Semiotics exists to make that communication explicit and coherent. A button that looks clickable but is disabled, a green badge that signals "good" when the metric is actually worsening, or a gear icon that means different things on different pages are not visual quirks; they are sign failures that erode user trust one micro-misread at a time.
The core rule is: one signifier should point clearly to one intended signified within a given system context. The more a sign drifts, the more users (and agents) are forced to infer meaning from guesswork rather than from the system itself. Sign drift compounds — a single ambiguous icon is a small cost; ten ambiguous icons across a product is a learned distrust of the entire surface.
This skill is sign analysis, not visual craft. It tells you whether a sign communicates the right meaning. It does not tell you how to lay out the screen, what hex value to use, what class hierarchy to formalize, or what wording to put on a button. Each of those belongs to a different skill in the design / language / data cluster.
When to Use
- Designing or auditing icon systems
- Checking whether a color, badge, or shape communicates the wrong judgment
- Explaining why users misread a button, state, or symbol
- Choosing or critiquing visual metaphors for abstract concepts
- Auditing naming and interface signs together when a surface feels semantically off
1. Foundations — How Signs Work
Peirce's Trichotomy
| Sign type |
Relationship to meaning |
UI example |
Strength |
| Icon |
Resembles what it represents |
Magnifying glass = search |
Intuitive but culturally variable |
| Index |
Causally connected to meaning |
Loading spinner = something is happening |
Direct but context-dependent |
| Symbol |
Arbitrary convention |
Red = danger, hamburger = menu |
Efficient once learned |
Rules:
- Prefer icons for first-use discoverability.
- Prefer symbols for expert fluency when the convention is already learned.
- Use indexes when the system needs to signal that a process or state is actively occurring.
Saussure's Dyad
| Component |
Definition |
Application |
| Signifier |
The perceivable form |
Color, shape, text, icon, animation |
| Signified |
The concept or meaning |
Action, state, category, judgment |
Rules:
- The same signifier should not point to multiple signifieds within one product surface unless that ambiguity is deliberate and documented.
- Changing the signifier can break learned meaning even if the redesign seems visually improved.
Barthes' Three Layers
| Layer |
What it is |
Example |
| Denotation |
Literal reading |
Up arrow = increase |
| Connotation |
Associated judgment / cultural meaning |
Green = positive / good |
| Myth |
Systemic or ideological framing |
Growth as inherently desirable |
Rules:
- Separate direction from judgment in financial UI. An increase is not always good.
- A sign can be denotationally correct while still semantically wrong because the connotation misleads.
2. Visual Semiotics for Interfaces
Color as Sign
| Color |
Common denotation |
Common connotation |
Risk |
| Red |
Error, stop, danger |
Bad, urgent, loss |
Overuse dulls alarm meaning |
| Green |
Success, active, up |
Good, growth, healthy |
Wrong when used for undesirable increases |
| Yellow / Amber |
Warning, caution |
Attention needed |
Easily confused with error |
| Blue |
Information, trust, link |
Calm, corporate, neutral authority |
Can become semantically empty if overused |
| Grey |
Inactive, secondary, disabled |
Neutral, quiet |
May fail as an anti-affordance if too subtle |
Rules:
- Color should not be the only sign channel for important meaning.
- Audit color decisions at both denotation and connotation levels.
- Live token values, contrast compliance, and visual craft belong to
a11y or visual-design-foundations; semiotics evaluates only whether the sign itself is coherent.
Shape and Position as Sign
| Sign channel |
Common reading |
| Top-left placement |
Primary or first-scanned element |
| Top-right placement |
Tools, account, utility actions |
| Bottom-right placement |
Primary CTA in a dialog |
| Circle |
Status, avatar, completion |
| Triangle / arrow |
Direction, expansion, movement |
| Pill / badge |
Category, state, count |
Rules:
- Position and shape carry meaning even without text; treat them as part of the sign system.
- If a layout or component breaks a strong convention, ensure the surrounding cues are strong enough to retrain the interpretation.
3. Iconography as a Sign System
| Principle |
Rule |
| Consistency |
Same concept = same icon across the product |
| Metaphor clarity |
The metaphor should be legible without specialist training |
| Pairing |
Abstract or unfamiliar icons need text pairing until learned |
| System coherence |
Use one icon family unless there is a compelling reason not to |
Common breakdowns:
- Icon polysemy — one icon means several things
- Opacity — abstract mark with no clear signified
- Cultural collision — metaphor fails outside one audience's assumptions
- Obsolete metaphor — the convention is still learned by some but dead to others (e.g., the floppy-disk save icon)
4. Affordance Theory
| Concept |
Application |
| Real affordance |
What the element can actually do |
| Perceived affordance |
What the element appears to allow |
| Signifier |
The cue that tells the user action is possible |
| Anti-affordance |
The cue that tells the user action is not possible |
Rules:
- If an element looks interactive, it should be interactive.
- Disabled states need a strong anti-affordance, not just a mild color change.
- Semiotic failures most often appear when the signifier and the true affordance disagree.
5. Code and API Semiotics
Semiotics also applies to textual and code-facing signs.
| Sign surface |
Semiotic question |
| Function name |
Does the signifier actually tell me what the behavior is? |
| Variable name |
Does the label point clearly to the value's meaning? |
| API endpoint |
Does the route name communicate the resource / action correctly? |
| Error message |
Does it communicate both what happened and how to respond? |
Rule: a vague name like processData() is a signifier failure even when the implementation works. The reader has to open the function to learn its meaning — which is exactly the inference cost a good sign eliminates.
This overlaps with semantics (which owns identifier-level meaning encoding); semiotics adds the sign-system lens — is the same concept signed consistently across both code names and visual interface elements?
6. Semiotic-Coherence Audit
Use this checklist when reviewing a surface:
- Does each color carry one stable meaning across the product?
- Does each icon represent one intended concept?
- Do interactive elements look interactive?
- Do disabled states look unavailable rather than merely quiet?
- Are abstract concepts paired with enough textual support?
- Is the same concept being signed consistently across UI and code-facing surfaces?
Evals
This skill ships a comprehension-eval artifact at examples/evals/semiotics.json. The checklist below is the authoring gate for sign-system decisions; the eval file is the grader surface.
Verification
After applying this skill, verify:
Do NOT Use When
| Instead, use |
Why |
microcopy |
Drafting the actual button labels, empty states, tooltips, or toasts. Microcopy owns the wording; semiotics owns the sign system the wording lives inside. |
semantics |
Deciding the meaning encoding of a single identifier, design token, HTTP status code, or commit type. Semantics owns identifier-level meaning; semiotics owns the multi-channel sign system. |
semantic-relations |
Typing the connection between two concepts (IS-A, PART-OF, thematic, causal). Semantic-relations owns concept-to-concept relations; semiotics owns sign-to-meaning mappings. |
linguistics |
Word morphology, compound-word ordering, abbreviation policy. Linguistics owns word-form rules; semiotics owns broader sign systems including visual ones. |
a11y |
Auditing aria-label correctness, focus management, screen-reader semantics. A11y owns accessibility contracts; semiotics may inform them but does not own them. |
visual-design-foundations |
Palette, typography, spacing, hierarchy, craft quality, and motion feel. Visual-design-foundations owns visual craft; semiotics asks what the visual element signifies. |
| (an ontology skill) |
Formal class hierarchies, existence axioms, reasoning constraints. Ontology owns formal classification; semiotics owns sign meaning in interfaces. |
1---2name: semiotics3description: Use when designing or auditing icon systems, colors/badges/shapes, visual metaphors, interface signs, or naming-plus-visual surfaces that users misread. Covers semiotic reasoning across icon/index/symbol, signifier/signified, denotation/connotation/myth, color/shape/position/iconography, affordances, code/API signifiers, and semiotic-coherence audits. Do NOT use for actual UI wording (use `microcopy`), palette/typography craft (use `visual-design-foundations`), accessibility or contrast compliance (use `a11y`), formal class hierarchies, or word morphology rules.4license: MIT5---6
7# Semiotics
8
9## Coverage
10
11Semiotic analysis as the study of sign systems in software interfaces and communication. Covers:
12
13- **Foundational models** — Peirce's icon / index / symbol trichotomy; Saussure's signifier / signified dyad; Barthes' denotation / connotation / myth layers
14- **Visual semiotics for interfaces** — color as sign (denotation + connotation, with the never-color-alone rule), shape and position as sign channels (top-left, top-right, bottom-right, circle, triangle, pill)
15- **Iconography as a sign system** — consistency, metaphor clarity, pairing rules, system coherence; common breakdowns (icon polysemy, opacity, cultural collision, obsolete metaphor)
16- **Affordance theory** — real affordance, perceived affordance, signifier, anti-affordance; the rule that disabled states need a strong anti-affordance
17- **Code and API semiotics** — naming, variable, endpoint, and error-message signs; the rule that vague names like `processData()` are signifier failures even when the implementation works
18- **Semiotic-coherence audit** — the checklist for reviewing a surface across color, icon, affordance, and cross-surface consistency
19
20The skill operates *above* microcopy execution and color-token math, and *below* formal ontology. It owns the question "what does this sign communicate to a user?", not "what should the button say?", "what hex value is this?", or "what class hierarchy do these things belong to?".
21
22## Philosophy
23
24Every interface element is already communicating, whether the designer intended it to or not. Semiotics exists to make that communication explicit and coherent. A button that looks clickable but is disabled, a green badge that signals "good" when the metric is actually worsening, or a gear icon that means different things on different pages are not visual quirks; they are sign failures that erode user trust one micro-misread at a time.
25
26The core rule is: **one signifier should point clearly to one intended signified within a given system context.** The more a sign drifts, the more users (and agents) are forced to infer meaning from guesswork rather than from the system itself. Sign drift compounds — a single ambiguous icon is a small cost; ten ambiguous icons across a product is a learned distrust of the entire surface.
27
28This skill is sign *analysis*, not visual *craft*. It tells you whether a sign communicates the right meaning. It does not tell you how to lay out the screen, what hex value to use, what class hierarchy to formalize, or what wording to put on a button. Each of those belongs to a different skill in the design / language / data cluster.
29
30## When to Use
31
32- Designing or auditing icon systems
33- Checking whether a color, badge, or shape communicates the wrong judgment
34- Explaining why users misread a button, state, or symbol
35- Choosing or critiquing visual metaphors for abstract concepts
36- Auditing naming and interface signs together when a surface feels semantically off
37
38---
39
40## 1. Foundations — How Signs Work
41
42### Peirce's Trichotomy
43
44| Sign type | Relationship to meaning | UI example | Strength |
45|-----------|------------------------|------------|----------|
46| **Icon** | Resembles what it represents | Magnifying glass = search | Intuitive but culturally variable |
47| **Index** | Causally connected to meaning | Loading spinner = something is happening | Direct but context-dependent |
48| **Symbol** | Arbitrary convention | Red = danger, hamburger = menu | Efficient once learned |
49
50Rules:
51
52- Prefer icons for first-use discoverability.
53- Prefer symbols for expert fluency when the convention is already learned.
54- Use indexes when the system needs to signal that a process or state is actively occurring.
55
56### Saussure's Dyad
57
58| Component | Definition | Application |
59|-----------|-----------|-------------|
60| **Signifier** | The perceivable form | Color, shape, text, icon, animation |
61| **Signified** | The concept or meaning | Action, state, category, judgment |
62
63Rules:
64
65- The same signifier should not point to multiple signifieds within one product surface unless that ambiguity is deliberate and documented.
66- Changing the signifier can break learned meaning even if the redesign seems visually improved.
67
68### Barthes' Three Layers
69
70| Layer | What it is | Example |
71|-------|-----------|---------|
72| **Denotation** | Literal reading | Up arrow = increase |
73| **Connotation** | Associated judgment / cultural meaning | Green = positive / good |
74| **Myth** | Systemic or ideological framing | Growth as inherently desirable |
75
76Rules:
77
78- Separate direction from judgment in financial UI. An *increase* is not always *good*.
79- A sign can be denotationally correct while still semantically wrong because the connotation misleads.
80
81---
82
83## 2. Visual Semiotics for Interfaces
84
85### Color as Sign
86
87| Color | Common denotation | Common connotation | Risk |
88|-------|-------------------|--------------------|------|
89| Red | Error, stop, danger | Bad, urgent, loss | Overuse dulls alarm meaning |
90| Green | Success, active, up | Good, growth, healthy | Wrong when used for *undesirable* increases |
91| Yellow / Amber | Warning, caution | Attention needed | Easily confused with error |
92| Blue | Information, trust, link | Calm, corporate, neutral authority | Can become semantically empty if overused |
93| Grey | Inactive, secondary, disabled | Neutral, quiet | May fail as an anti-affordance if too subtle |
94
95Rules:
96
97- Color should not be the *only* sign channel for important meaning.
98- Audit color decisions at both denotation and connotation levels.
99- Live token values, contrast compliance, and visual craft belong to `a11y` or `visual-design-foundations`; semiotics evaluates only whether the *sign* itself is coherent.
100
101### Shape and Position as Sign
102
103| Sign channel | Common reading |
104|--------------|----------------|
105| Top-left placement | Primary or first-scanned element |
106| Top-right placement | Tools, account, utility actions |
107| Bottom-right placement | Primary CTA in a dialog |
108| Circle | Status, avatar, completion |
109| Triangle / arrow | Direction, expansion, movement |
110| Pill / badge | Category, state, count |
111
112Rules:
113
114- Position and shape carry meaning even without text; treat them as part of the sign system.
115- If a layout or component breaks a strong convention, ensure the surrounding cues are strong enough to retrain the interpretation.
116
117---
118
119## 3. Iconography as a Sign System
120
121| Principle | Rule |
122|-----------|------|
123| **Consistency** | Same concept = same icon across the product |
124| **Metaphor clarity** | The metaphor should be legible without specialist training |
125| **Pairing** | Abstract or unfamiliar icons need text pairing until learned |
126| **System coherence** | Use one icon family unless there is a compelling reason not to |
127
128Common breakdowns:
129
130- **Icon polysemy** — one icon means several things
131- **Opacity** — abstract mark with no clear signified
132- **Cultural collision** — metaphor fails outside one audience's assumptions
133- **Obsolete metaphor** — the convention is still learned by some but dead to others (e.g., the floppy-disk save icon)
134
135---
136
137## 4. Affordance Theory
138
139| Concept | Application |
140|---------|-------------|
141| **Real affordance** | What the element can actually do |
142| **Perceived affordance** | What the element appears to allow |
143| **Signifier** | The cue that tells the user action is possible |
144| **Anti-affordance** | The cue that tells the user action is *not* possible |
145
146Rules:
147
148- If an element looks interactive, it should be interactive.
149- Disabled states need a strong anti-affordance, not just a mild color change.
150- Semiotic failures most often appear when the signifier and the true affordance disagree.
151
152---
153
154## 5. Code and API Semiotics
155
156Semiotics also applies to textual and code-facing signs.
157
158| Sign surface | Semiotic question |
159|--------------|-------------------|
160| Function name | Does the signifier actually tell me what the behavior is? |
161| Variable name | Does the label point clearly to the value's meaning? |
162| API endpoint | Does the route name communicate the resource / action correctly? |
163| Error message | Does it communicate both what happened and how to respond? |
164
165**Rule**: a vague name like `processData()` is a signifier failure even when the implementation works. The reader has to *open the function* to learn its meaning — which is exactly the inference cost a good sign eliminates.
166
167This overlaps with `semantics` (which owns identifier-level meaning encoding); semiotics adds the sign-system lens — *is the same concept signed consistently across both code names and visual interface elements?*
168
169---
170
171## 6. Semiotic-Coherence Audit
172
173Use this checklist when reviewing a surface:
174
175- Does each color carry one stable meaning across the product?
176- Does each icon represent one intended concept?
177- Do interactive elements look interactive?
178- Do disabled states look unavailable rather than merely quiet?
179- Are abstract concepts paired with enough textual support?
180- Is the same concept being signed consistently across UI and code-facing surfaces?
181
182---
183
184## Evals
185
186This skill ships a comprehension-eval artifact at [`examples/evals/semiotics.json`](https://github.com/jacob-balslev/skill-graph/blob/main/examples/evals/semiotics.json). The checklist below is the authoring gate for sign-system decisions; the eval file is the grader surface.
187
188## Verification
189
190After applying this skill, verify:
191
192- [ ] No signifier points to multiple unintended signifieds within the same system context
193- [ ] Important interface meanings are not encoded through color alone
194- [ ] Interactive and non-interactive states have distinct affordance signals
195- [ ] Icon metaphors are coherent, learnable, and consistent across surfaces
196- [ ] Direction (denotation) and judgment (connotation) are separated in financial / metric UI
197- [ ] Code-facing signs (function, variable, endpoint names) are not vague signifier failures
198
199## Do NOT Use When
200
201| Instead, use | Why |
202|---|---|
203| `microcopy` | Drafting the actual button labels, empty states, tooltips, or toasts. Microcopy owns the wording; semiotics owns the sign system the wording lives inside. |
204| `semantics` | Deciding the meaning encoding of a single identifier, design token, HTTP status code, or commit type. Semantics owns identifier-level meaning; semiotics owns the multi-channel sign system. |
205| `semantic-relations` | Typing the connection between two concepts (IS-A, PART-OF, thematic, causal). Semantic-relations owns concept-to-concept relations; semiotics owns sign-to-meaning mappings. |
206| `linguistics` | Word morphology, compound-word ordering, abbreviation policy. Linguistics owns word-form rules; semiotics owns broader sign systems including visual ones. |
207| `a11y` | Auditing aria-label correctness, focus management, screen-reader semantics. A11y owns accessibility contracts; semiotics may inform them but does not own them. |
208| `visual-design-foundations` | Palette, typography, spacing, hierarchy, craft quality, and motion feel. Visual-design-foundations owns visual craft; semiotics asks what the visual element *signifies*. |
209| (an ontology skill) | Formal class hierarchies, existence axioms, reasoning constraints. Ontology owns formal classification; semiotics owns sign meaning in interfaces. |
aibot88