A Design System Is Also a Knowledge System
Components, states, rules, and code mappings make a design system an operational model of how an organization builds interfaces.
Take a button out of a mature design system. It has a name, states, allowed variations, interactions, accessibility requirements, visual properties, and a code implementation. It may have examples of where it belongs and cases where it must not be used.
That is a considerable amount of knowledge for a small rectangle on a screen.
The rectangle matters, but it is the visible end of the arrangement. The design system preserves decisions made by designers, engineers, accessibility specialists, writers, and product teams. It gives those decisions a form that later teams can reuse. In that sense, the system is a maintained model of how an organization builds interfaces.
More than a shelf of components
An early design system may be little more than a library of colors and reusable elements. A stronger one defines a vocabulary. It explains the difference between a warning and an error, a page heading and a section heading, a choice and a destructive action. It names states and specifies how they behave.
These are knowledge-engineering concerns. Which concepts exist? Which properties belong to them? Which combinations are valid? What changes when one component is reused in a different context? Where is the authority for a rule, and who revises it?
The questions become sharper when software agents use the design system. Figma’s published account of design-system context for coding agents describes components, variables, styles, annotations, accessibility information, naming conventions, and code mappings becoming available through its tools. The aim is to give an agent more than a screenshot: it can receive structured information about the intended design. (Figma, design system context for coding agents)
This is a useful test of what the organization actually knows about its interface. A human designer can infer a great deal from an example and ask a colleague about the rest. An agent may produce a plausible page from the example while missing the behavior, constraint, or exception that made the original design work. Making that knowledge available requires more than exporting visual assets.
The role at the seam
The software role now often called a design engineer works across interface design and implementation. The name also has a longer history in physical engineering, so it needs context. In digital products, the practitioner may build interactions, prototypes, and production components while preserving the intended design behavior in code.
The interesting connection is not a new title. It is the seam between a human-facing representation and a computational one. A component can look correct but have the wrong keyboard behavior. It can be implemented correctly but carry a label that misstates the decision. It can follow the design file and still violate a newer rule in the codebase. Someone has to investigate the relation among all three.
Knowledge engineering brings a useful discipline to that seam. Treat the component name, its intended use, the implementation, and the evidence for an accessibility requirement as connected but distinct things. Keep changes traceable. Test the behavior that matters. Make exceptions explicit enough that a later designer or agent can tell an approved variation from an accident.
The same principle applies outside interface components. An engineering drawing, procurement rule, or maintenance checklist may also encode decisions that later work depends on. A design system simply makes the architecture unusually visible. It shows how visual form, operational rules, and executable behavior can become parts of one maintained resource.
The next change is already under way: an interface need not always be a fixed page assembled from fixed components. An AI system can choose a view in response to a question. That makes the relationship between representation and authority harder, not easier.
