"Anyone who devises courses of action aimed at changing existing situations into preferred ones designs." Herbert Simon's definition of design, from The Sciences of the Artificial, mentions no colors, no fonts, no screens. The center of design isn't the output—it's the judgment involved in devising a course of action. Design is a continuous sequence of decisions entangled with business metrics, user behavior data, past successes and failures, and agreements among stakeholders. The screen is merely the final output of that judgment. In an era where a single prompt can produce a plausible-looking screen, what AI commonly generates is output, not judgment.
The real problem is that the grounds for design decisions are never fully preserved anywhere. The results of design remain on the canvas or in the actual product, but the reasoning behind those decisions quietly gets buried—in the designer's head, in unshared personal documents, or in threads scattered across various channels. Organizations flounder because they can't grasp the context of past decisions, and even AI spits out plausible-sounding hallucinations, because it's impossible to infer logic from data that was never recorded in the first place.
Even when records do exist, they don't help much. Pure LLMs and typical RAG pipelines are forced to treat design assets as unstructured text and images, which makes it fundamentally difficult to extract "good design" from them. Today, when AI makes it easy to churn out "reasonably decent" UI designs, the importance of design itself is being undervalued. Those who proclaim "design is dead" tend to have only the most superficial understanding of design. Claude Design and Design.md are perhaps evidence of this. I agree with the direction of externalizing design knowledge into a readable form, but the problem lies in structure and granularity. A plain markdown document is not an ontology. A statement like "our brand conveys trust" gives an agent no way to infer why a particular button should be a particular color, and systems that pursue only shallow visual consistency lose the true meaning of their components as they scale.
Without a structure for knowledge, accumulation can't happen easily either. A Design Agent that depends on one-off conversation sessions can't learn from decisions made in previous projects. Once a session ends, the context behind those decisions evaporates, and the same concept inevitably ends up meaning slightly different things across different projects.
To move beyond these limitations and enable AI to perform truly creative design, we need formalized modeling of design knowledge and an ontology that an agent can parse. I've been thinking about how to structure not only screen-level designs created on canvases like Figma and actual product business metrics, but also qualitative decision criteria like a designer's reasoning process—all encoded as an ontology and woven into a knowledge graph.
Round and Round, We Arrive at Ontology Again
An ontology is a formal, logical specification that describes the entities within a specific domain, the properties they possess, the relations they participate in, and the constraints they must satisfy. Philosophically, it explores the fundamental categories of existence; from an engineering standpoint, it's the infrastructure that enables semantic interoperability—allowing machine systems to understand and reason about complex knowledge structures.
About a year ago, I briefly helped out at a startup aiming to offer an AX solution similar to Palantir's Ontology Platform (this didn't end up becoming an actual venture), and I also put together a pitch deck for a solution that would connect all the data across in-house SaaS tools into a searchable search engine and knowledge base. After returning from leave and immersing myself in building tools and agents for designers within the UX Platform organization, I eventually arrived at the conclusion that what we needed most was a Design Knowledge Base capable of searching scattered knowledge, along with a data pipeline to support it. Building on this, I went beyond simply raising the problem and drafted a one-pager containing a concrete solution and goals, which won the Head's full enthusiasm—leading to team building and the launch of a full-fledged project.
Design Ontology
To structure the act of design from an ontological perspective, the Function-Behaviour-Structure (FBS) framework seems like it could serve as a solid cognitive and philosophical foundation. The FBS ontology isn't confined to any specific design discipline (architecture, mechanical engineering, software, etc.)—it provides an independent schema capable of describing any designed artifact, whether physical, virtual, or social. This becomes an essential criterion for breaking down and reassembling complex UI/UX design assets into units that a machine can understand.
The FBS framework defines the object of design in terms of three fundamental components. First, Function is the teleological aspect of the artifact—what this artifact is for. This is assigned by establishing a connection between human goals and the measurable effects of the artifact. Second, Behaviour is a property derivable from the artifact's structure, indicating what the artifact does. This provides measurable performance criteria—quality, time, cost, etc.—for comparing different artifacts. Third, Structure is the components that make up the artifact and the relationships among them, defining what the artifact consists of.
What's worth noting here is that there is no direct connection between Function (F) and Structure (S). Humans construct the links between function, behavior, and structure through experience and by developing causal models based on interaction with artifacts. The design process is essentially expressed as a set of transformations among these three concepts, with the most basic form being the transformation from function to behavior ($F \rightarrow B$) and then from behavior to structure ($B \rightarrow S$). A requirement enters as function ($F$); the agent then retrieves behavior metrics ($B$) from a historical database that previously improved conversion rates, and traces back the specific structure ($S$)—UI patterns, colors, spacing—that caused those metrics. When this logical flow is systematically incorporated into a knowledge graph, we can say that AI is truly "designing," reasoning on its own beyond mere combination.
Turning Design Decisions into Ontology
If the geometric information contained in a design system—UI components, color tokens, typography, patterns—along with a product's quantitative metrics forms the skeleton and muscle of the ontology, then the neural network that moves it is the context of "why this decision was made"—namely, Design Rationale (DR). Design is the product of countless feedback loops and compromises among diverse stakeholders—not just designers, but developers, marketers, planners, and users. A system that fails to encode these qualitative judgment criteria into knowledge is only half-intelligent at best.
DR documents the justification and decision-making process behind product components, and it's an essential category of knowledge that stimulates creative ideation and drives new solutions during conceptual design. However, in traditional workflows, this kind of knowledge has always remained as tacit knowledge locked inside individual designers' heads, never properly recorded due to various constraints.
Fortunately, there's already a long lineage of attempts to structure DR. IBIS (Issue-Based Information System) records discussions as a graph of Issues-Positions-Arguments, while QOC (Questions, Options, Criteria) lays out the design space as a matrix of questions-alternatives-evaluation criteria. Using these models as schemas, even the back-and-forth of a Slack thread or comments from a critique session become material that can be incorporated into an ontology. For example, these could be expressed as the following triples:
checkout_button --hasVariant--> solid_high_contrast
solid_high_contrast --justifiedBy--> experiment_2412
experiment_2412 --improved--> checkout_cvr
experiment_2412 --rejectedOption--> ghost_buttonThis is also precisely where a division of labor between neural networks and symbolic systems becomes necessary. Extracting candidate issues and arguments from unstructured conversation is something LLMs excel at; verifying that the extracted knowledge conforms to the schema and constraints, and maintaining consistency with the existing graph, is something the symbolic layer excels at. The most reasonable structure is one where neural networks handle generation, while the ontology handles verification and maintaining the grounds for reasoning.
In Actual Organizations
Applying AI and knowledge graphs to reality carries no small engineering cost. Even with a crystal-clear blueprint in mind of what needs to be built, implementing it as a system that actually works within one's own organization is an entirely different matter. Separate from building the knowledge graph itself, there's also the need to construct a data pipeline that unifies unstructured data and decision records—fragmented across various SaaS platforms like Figma, Slack, and Notion—into a single ontology.
While systems for systematically gathering and utilizing work data from other domains (data marts, data lakes, etc.) are already well-established, it's hard to find a precedent where design has been clearly turned into an ontology encompassing both metrics and qualitative decision rationale.
In the industry today, the organization contemplating a role most similar to this is probably the Design Platform team responsible for operating and optimizing in-house design systems. However—while they handle many tasks—from an outside observer's view, they often remain limited to managing the deployment of Design System UI components, automating design-to-dev handoff, and coordinating work among team members. What's missing is a pipeline where the design platform provider observes practitioners' actual working patterns, inductively extracts recurring patterns, and automatically accumulates these as new rules for the design system. It was hard to find a single case of an organization running a genuine data pipeline that extracts scattered design rationale and context from various sources and links them into a knowledge graph.
Building such a pipeline in-house requires connectors and parsers using each SaaS's API. For instance, automatically detecting inconsistencies between a Slack discussion thread or a Notion document and a Figma asset requires an organization-wide ground rule mandating a common reference point, such as an issue tracker ID. One also needs to comprehensively weigh factors like data scraping, text vectorization, and the cloud infrastructure costs required to maintain real-time synchronization. Therefore, to truly achieve the grand goal of a design ontology, the data engineering capability and resources of a Design Intelligence organization are essential—capable of supporting an initiative substantial enough to offset the large upfront investment with clear, tangible value.
For a design ontology to function successfully, it needs more than a theoretical model—it requires an engineering pipeline that extracts the enormous volume of design data generated in real working environments in real time and maps it into structured knowledge. Had the in-house design editor I'd been building (Deus) still existed, this might have been considerably easier, but unfortunately, we decided to sunset Deus a few months ago with the adoption of Figma. Because of this, building a pipeline with complete, ground-up control is no longer possible. In fact, the idea of building a single platform that perfectly controls all data and workflows is nothing more than an appealing "utopia." The realistic completion of a design ontology will hinge not on building a massive proprietary platform, but on how seamlessly and organically we can weave together already-sophisticated third-party SaaS tools in each domain—including Figma.
Conclusion
We need to understand design not as arranging visual elements flatly on a screen, but as an engineering process of negotiation entangled with user behavior metrics, complex business logic, and multiple stakeholders. A Design Agent that merely learns screen-level patterns to churn out average-quality designs can neither understand this context nor sustain a coherent design ecosystem. What's needed is a Design Ontology that encompasses canvas structural data, quantitative A/B test metrics, and even the critique and design rationale exchanged among designers. This is supported by a pipeline where the FBS framework structures artifacts, IBIS and QOC structure decisions, and symbolic constraints verify the knowledge extracted by neural networks. Once every output an agent produces can be traced back to evidence within the knowledge graph, the opening question—"Why is the checkout button this color?"—will no longer end in silence.
If we can convert all this tacit knowledge into explicit knowledge and build a continuously improving knowledge base, the role of the designer will undergo a radical paradigm shift. I expect the center of gravity to shift further away from refining pixel-level visual forms, toward becoming the curator of a knowledge system—defining design rules and ontologies, and reviewing and approving the reasoning processes of AI agents.
These days, I'm leading this project by asking questions that are just as much big-picture as they are engineering questions like "what technology should we use to build the data pipeline." Who will build and maintain this ontology, and how? To what extent should DR be automatically extracted from unstructured conversation, and at what point should a human step in to approve it? Who will revise the ontology schema, and how often? What core scenarios should we base a PoC on, and how can we narrow down the problem from there?
p.s. If there's one thing I've deeply felt while running several projects lately, it's that when a project collapses or drifts amid clashing philosophies, it's usually because people are trying to find "the most perfect answer." What completes a project isn't the right answer so much as the relentless will to turn one's own choice into the right answer. Even the most beautiful, perfect architecture or solution becomes the "wrong" choice if it fails to win the team's buy-in or if no one has the will to see it through to completion, taking responsibility to the end. Words like theoretical perfection or logical soundness are seductive, but we shouldn't get lost in them. In the end, it's simply a matter of who sees through to the end what they believe to be right.