Design Intelligence: The Infrastructure Design Has Always Needed
For the past two years, engineering teams have grappled with a conundrum that has quietly bedevilled design for decades: how do you manage what remains unseen? Design, as a discipline, has long persisted in silos, its decisions dispersed across a patchwork of documents, its progress measured by subjective reviews rather than shared evidence. This is not merely inefficient; it renders the discipline invisible to the business, to its collaborators, and, all too often, to itself.
Engineering’s solution was to construct an infrastructure: a living catalogue of services, ownership, and dependencies, with metrics calculated against this foundation and agents acting upon the insights revealed. The outcome is a discipline capable of measuring its own health, governing its output, and articulating its impact in terms the wider organisation can readily comprehend.
Design requires a comparable infrastructure—not a borrowed construct from engineering, but one conceived for the realities of design itself.
The pattern observed in engineering is instructive, precisely because it reflects a persistent failure mode that design has yet to resolve.
Engineering teams building AI agents discovered the limiting factor wasn’t the model—it was the context. One team’s breakthrough came when they asked an agent when a service was last deployed, and it knew. It found the right repository without being told, understood which team owned it, and followed their conventions. Not because the model was more capable. Because the context was structured, connected, and available.
The corollary failure was equally instructive. When the context came back empty during a live incident, everyone noticed immediately. Missing service ownership, incomplete runbooks, stale data — invisible in normal conditions, catastrophic under pressure.
Design has long endured the problem of empty context: decisions consigned to Sketch files that have long since vanished, brand guidelines last touched by a colleague who left a year and a half ago, and design rationale that lived solely in the mind of a senior designer who has since moved on. Components are documented in ways that engineering never discovers. The absence of context is not carelessness; it is the inevitable result of never building the infrastructure required to capture and connect it.
The engineering intelligence conversation has produced a useful distinction: measuring the delivery lifecycle is different from operating it. Measurement observes and reports. Operating runs the lifecycle — and includes measurement as one output of the same system that acts on what it finds.
For much of its history, design has measured the wrong things: portfolio quality, stakeholder satisfaction, the sheer number of screens produced in a sprint, and has labelled the resulting data as intelligence. In truth, these are not intelligence at all; they are little more than anecdotes adorned with graphics.
Design intelligence, when properly understood, is the structured visibility of design decisions across the entire delivery chain: what was designed, for what reason, by whom, under which constraints, validated by what evidence, and linked to which outcomes. When this information is live, accessible, and connected—to the product backlog, the engineering build, the brand system, and the content model—it becomes operational. Teams make decisions more swiftly and cohesively, rework diminishes, and accountability is distributed.
The DaS™ model has described this infrastructure since its founding. The knowledge base is not a Confluence wiki that someone updates when they remember to. It is a live operating record — the same source of truth designers read when they begin a new brief, engineers read when they begin a build, product owners read when they assess feasibility, and leaders read when they need to understand where delivery stands. Figma holds the design truth. Confluence holds the decision rationale and knowledge. Jira holds the action. Automation keeps them synchronised.
When a token changes in the design system, it propagates across every component that uses it — across 40 or more properties simultaneously. When a content decision changes, it surfaces to the developer building the feature through the same connected system. When a new designer joins the team, they don’t inherit a folder of stale PDFs. They inherit the operating record of every decision the team has made, structured in a way they can navigate and build from immediately.
This is not mere documentation. This is design intelligence, and it fundamentally alters what the discipline is capable of achieving.
Three structural investments make Design Intelligence operational, not aspirational.
Construct the design catalogue before the silos become irretrievable. The lesson from engineering is unambiguous: four separate teams independently developed the same agent within three weeks, simply because no shared registry existed. Design repeats this error at every scale—four designers addressing the same interaction challenge across four product areas, with no mechanism for their solutions to converge. The DaS™ Component List and Feature List serve as the design catalogue: a living record of what exists, its function, its connections, and the constraints that govern it. This is not a Figma library languishing in someone’s bookmarks, but a structured, versioned, and accessible foundation upon which every discipline can rely.
Render design decisions visible in the language of the business. The BoK is unequivocal: if you cannot express design decisions in business terms, you cannot hope to influence the business. Design intelligence is not a private ledger for designers; it is the means by which design demonstrates its value to the organisation—through OKRs linked to design outcomes, KPIs that trace the impact of design on user behaviour and commercial performance, and a Definition of Ready that equips engineering with all it requires to proceed unambiguously. Broadcasting, in DaS™ parlance, is precisely this: structured, deliberate, organisation-wide knowledge sharing that amplifies design’s impact far beyond the confines of the design team.
Measurement must be connected to action within the same system. The distinction between measuring the design lifecycle and operating it is as pertinent here as it is in engineering. A dashboard that highlights inconsistent design decisions is helpful; a system that not only surfaces the inconsistency but links it to the relevant component and empowers the designer to resolve it within the same environment is truly operational. The DaS™ integrated ecosystem—Figma, Confluence, Jira, synchronised through automation—exists for precisely this purpose: decisions generate actions, actions update the record, and records inform subsequent decisions. The loop is completed, and the context remains ever-present.
“We already document our design decisions — that’s what Confluence is for.” Documentation and design intelligence are not the same thing. Documentation records what happened. Intelligence connects what happened to what comes next — to the component that carries the decision, to the user story that specified it, to the outcome that validated it. A Confluence page that nobody reads during delivery is not intelligence. A structured knowledge base that engineering reads when they begin a build is operational context. The difference is connection, not content.
“Design metrics are too subjective to measure reliably.” The engineering experience confirms that the model is not the variable — the context is. The same is true for design: the difficulty is not in defining what good design looks like, but in making the evidence that determines it visible and connected. Behaviour-driven requirements, validated prototypes, and acceptance criteria that design and engineering agree on before a sprint begins are measurable. They produce evidence rather than opinion, and evidence is what makes design visible to the business.
“Our team is too small to invest in this infrastructure.” The DaS™ broadcasting data is specific: after a three-month investment in standardising the design system and building structured documentation, 75 units across seven banks adopted the system — representing approximately 3,500 digital properties moving to a unified experience, with a 12% reduction in learning curve and a 17% increase in customer interaction speed. That outcome came from broadcasting, not headcount—the infrastructure scales. The team does not have to.
Engineering constructed its intelligence infrastructure out of necessity: the complexity of its systems surpassed what any individual or team could reasonably retain. Design, too, is entrusted with systems of comparable intricacy—brand coherence spanning dozens of touchpoints, interaction consistency across hundreds of components, content accuracy over thousands of pages—and has, until now, managed this complexity through proximity, goodwill, and the institutional memory of individuals who inevitably depart.
Design Intelligence offers the structural remedy to this predicament. It is not a new tool or a novel methodology, but a connected, living operating record of every design decision the organisation has made: why it was made, what it is connected to, and what would need to change if the surrounding context shifts.
When context is present, the team flourishes. Without it, the deficiency is immediately apparent. Design ought not to be in the business of empty context.
The discussion of what this infrastructure entails in practice—how to construct the design catalogue, connect it to engineering and product, and render design decisions visible in the language of the business—is one we continue at designatscale.co.
