What turns reusable assets into usable system context
8 min read
Reusable assets do not preserve their meaning by themselves. That meaning must survive every product, person, tool, and workflow that applies the decision next.
Founder of Design Systems Surf
Design systems are built for reuse. Styles, grids, and tokens can move across screens, products, code, and documentation. But reusable assets do not always produce consistent decisions when their purpose or limits are unclear.
An AI-ready system needs enough context to explain what each asset represents, where it should be used, and which rules must remain intact as it moves across design, code, documentation, and different product contexts.
The important shift is from an asset that can be repeated to a decision that can be understood.
Why the same asset creates different results
Reuse often looks more reliable than it is. Imagine a typography library with a complete scale of font sizes, weights, and line heights. Designers, developers, and AI can reuse those styles quickly, but the same style may still create different results.
A 32/40 semibold style could become a page title in one product, a marketing headline in another, and a dashboard metric elsewhere. The value is identical, but the role changes along with expectations around hierarchy, wrapping, density, and responsive behavior. The asset has been reused correctly at the technical level. The system decision has not.
A style, token, property, or API can be available everywhere while still depending on local judgment. A compact component option may support dense operational interfaces without belonging in a customer-facing onboarding flow. When that boundary is missing, people reuse the option because it exists, code supports it because the API allows it, and AI selects it because nearby examples make it look valid.
Possibility starts behaving like approval. AI can repeat an asset accurately while missing the product logic that made its original use correct.
The output may follow the library and still fail to follow the system. The asset answers what can be reused. System context explains what decision must be preserved when it is reused.
For example, Google Material organizes typography around roles such as display, headline, title, label, and body. Each role can include several sizes but its purpose remains the main explanation of what the style should do. Visual properties make the asset reusable, while the named role connects it to a specific kind of content and hierarchy.
Without that second answer, reuse spreads the same material while allowing its meaning to drift.
An asset needs a job, not just a name
Names help people find assets, but they do not always explain what those assets are for. A style called heading-large sounds clearer than font-700, yet important questions remain. Is it the highest level in product UI? Can it appear more than once? Does it support long translated text or dense layouts?
The name points toward a role. It does not complete the decision. A reusable asset also needs a clear purpose, its place in the system, and the situations where it should and should not be used.
Typography Foundation provides a useful example. A type scale becomes a system when sizes and weights connect to semantic hierarchy, reading conditions, responsive use, and readability constraints. The values matter, but the surrounding rules explain what they are meant to achieve.
Visual systems often look complete before their meaning is complete. A clean type scale, organized radius set, or clearly labeled property may still require users to infer purpose from examples. But one valid example does not define the full boundary of a decision.
An AI-ready asset does not only expose an option. It explains the job, limits, and system intent behind that option.
Usable context makes those judgments explicit. It gives people, code, and AI a stronger basis for selecting an asset than appearance or frequency.
A useful system decision is not only easy to find. It is hard to misread.
Base Web makes a related distinction by keeping button intent and size as separate configuration axes. Primary, secondary, tertiary, and danger kinds describe the action, while mini, compact, and default options control size independently. Each property carries one clear part of the component decision instead of asking a single visual variation to communicate several meanings.
The hidden rules behind a reusable asset
No reusable asset works alone. A grid depends on containers and breakpoints, which affect reflow, line length, density, component composition, and visible content. Each part may exist as a reusable value, but the system appears only when those relationships are clear.
A layout library can define columns, gutters, container widths, and breakpoints in both Figma and code. Without rules for how they work together, teams may still produce very different layouts from the same approved assets. One product may keep a wide container too long, another may collapse columns too early, and a third may reflow cards and navigation independently.
The missing layer is not another breakpoint or grid value. It is the relationship between them.
Layout Foundation treats grids, containers, breakpoints, and reflow as one connected decision model. The values become reliable because their dependencies and behavior are defined, rather than left as options that each product combines differently.
The same principle applies to constraints. A radius value may look harmless in isolation, but nested surfaces, small controls, full-screen containers, and overlays can create inconsistent hierarchy when inner and outer shapes do not follow a clear relationship. Radius Foundation makes this explicit through scale, shape roles, nested-radius logic, and product constraints.
Component properties depend on supported states, tokens on reference paths, and patterns on valid product contexts. Relationships explain what a decision affects. Constraints explain what it must not break.
This matters for AI because those connections are difficult to recover from isolated assets. AI-ready context keeps the relationships visible before the model has to infer them.
What gets lost between Figma and the real product
A decision is most vulnerable when its form changes. In Figma, it may appear as a style, variable, grid, or example. In code, it becomes a token, prop, class, or implementation rule. In documentation, it becomes language. In an AI workflow, it becomes context that a model must interpret.
The representation changes, but the decision should not. A typography style may reach CSS while losing its semantic role. A layout token may reach code while reflow logic remains trapped in a Figma example. A radius value may be implemented correctly while the relationship between nested surfaces disappears.
The value can survive while the reason behind it disappears. The handoff remains technically correct, but the system decision becomes thinner at every step.
Portable system context preserves the decision in forms suited to different users. Documentation keeps purpose and usage boundaries visible. Accessibility guidance preserves limits hidden in the asset. Developer handoff explains how intent maps into implementation. Machine-readable tokens preserve references and relationships, while AI context .md provides rules that cannot be recovered safely from Figma alone.
eBay Evo carries this principle across platforms. Its tokens remain recognizably connected as they move from Figma into platform conventions with different syntax. Each platform receives an appropriate representation, while the role behind the token remains part of the shared system language. The asset changes form without losing the decision it represents.
Portability is not duplication. A developer may need implementation constraints and token mappings, while a designer needs usage boundaries and composition examples. AI needs enough purpose, relationships, constraints, and supported use to avoid filling gaps with a plausible rule.
A useful test is whether the decision remains understandable when the original Figma asset is no longer visible. Can the next person or tool still see what it is for, where it belongs, how it relates to the system, and what it must preserve? If not, the asset is portable, but its context is not.
Reuse works when meaning survives
Reusable assets remain essential, but technical portability is not enough. A decision becomes usable system context when its purpose, relationships, and constraints remain recognizable as it moves between design, code, documentation, and AI workflows.
The goal is not to make every source identical. It is to preserve the same system decision in the form each user or tool needs. That is what allows people, code, and AI to apply reusable assets without rebuilding their meaning from examples or assumptions.
