AI Product Design · 3 min read
Make the Visual System Legible to People and Machines
A visual language becomes more useful when its names, meanings, states, and accessible labels share one source of truth.
# Make the Visual System Legible to People and Machines
AI coding tools are starting to choose and assemble interface elements. That raises a design question I keep returning to: what does the tool actually know about the symbol it is using?
A folder of files can show an agent what is available. It cannot reliably tell the agent what an icon means, when it is safe to use, or how its meaning changes across states. Without that context, the system asks people and machines to infer semantics from pixels. That is a fragile contract.
Digital Sanskrit, my book in development, starts from the opposite direction. Define the grammar first; let the pixels express it. The system names eight semantic roots and rules for composing them. An icon can represent an agent, container, direction, flow, link, severity, state, or time. A modifier adds a controlled meaning—such as urgency, transfer, or completion—without turning each variation into an unrelated drawing.
One meaning, carried through the system
The practical extension is a structured manifest: names, roots, modifiers, sign type, state, and an accessible label belong together. That information can guide the asset library, design tokens, code components, documentation, and the agent that is assembling a screen.
This is also an accessibility decision. If an icon carries an action or status, its accessible name should come from the same defined meaning as its visual form. A button that only shows a symbol should not leave a screen-reader user guessing. If an icon is decorative, the system should say that too. Accessibility is easier to maintain when meaning is part of the source material instead of an annotation added at the end.
A grammar also gives AI a bounded choice. Rather than asking a model to invent a new symbol for every prompt, the team can expose approved roots and compositions, with labels and rules attached. That does not remove the need for human review. It makes the review more specific: is this the right meaning, is the combination allowed, and does the result remain understandable on this surface?
Put the rules in the build
My working proposal is to make the rules testable. Naming and grid checks can catch malformed assets. Accessibility checks can flag missing names. Visual regression can catch unintended changes. Comprehension testing can show whether people understand the meaning rather than simply whether the file compiled.
The same visual grammar must behave differently on a phone, desktop, watch, car display, or voice interface. The roots remain stable; each surface decides how many layers it can show. That separation lets teams adapt the interface without quietly changing the meaning.
This is one of the main ideas I am developing in Digital Sanskrit: meaning belongs in the grammar, not only in the pixels. For product and engineering leaders, that is a practical way to make design systems more governable, more accessible, and safer to extend with AI.