Design Systems · 3 min read
A Grammar for Icons Can Outlast a Design Team
Digital Sanskrit turns my Citrix design-system experience into a practical method for giving large icon libraries a shared language.
# A Grammar for Icons Can Outlast a Design Team
Some design-system problems look like an asset problem. Teams draw the same icon more than once, visual styles drift, and a library grows without becoming easier to use. Underneath, the real issue is often that the system has vocabulary but no grammar.
I saw that at Citrix. From 2003 to 2007, our product suite expanded across three products, acquisitions, platforms, and more than 1,000 user interfaces. Sixteen agencies had created separate dialects. A single named icon could require 28 files across sizes and formats. The challenge was not to make every drawing look alike. It was to give teams rules they could use to extend the system without losing its meaning.
That work became the foundation for Digital Sanskrit, the book I am developing as a treatise, reference, and field manual for icon systems. Its central idea is simple: an icon should be more than a finished picture. It should be a meaningful unit that can combine with other units according to rules.
From library to language
The book organizes a complex icon system around eight semantic roots: agent, container, direction, flow, link, severity, state, and time. Those roots describe the kinds of meaning teams repeatedly need. Modifiers then add context—such as urgency or completion—at consistent positions and with bounded combinations.
That distinction changes how a team works. Instead of asking one designer to invent every new state, people can name the job, select the right root, and compose a valid variation. The system becomes teachable. Reviews can focus on whether a new meaning fits the grammar, rather than whether someone likes a particular drawing.
At Citrix, the grammar had to work across products and file formats, not just inside a design presentation. The production model gave the system an owner, a studio team, and product leads who could reuse shared assets and request new ones. Naming conventions, specifications, and quality checks made it possible to find and maintain the files after the original designers moved on.
The book is a working method
Digital Sanskrit is not a catalog of attractive symbols. It is a method for creating, combining, naming, and governing visual language. The historical Citrix work is its proof of practice; the current manuscript extends the method to modern design systems, multiple device surfaces, accessibility, and AI-assisted interface generation.
For product leaders, the lesson is broader than iconography. A system that depends on individual memory is not yet a system. If a team cannot explain how a new state is named, where it belongs, how it is built, and who can approve it, the rules are still hidden in people’s heads.
I want the book to help designers and product teams make those rules visible. The goal is not to replace judgment with a checklist. It is to give good judgment a shared structure, so the product can grow without making every decision from scratch.