Why a good AI prompt is not yet a repeatable design-system workflow
7 min read
A prompt that works once is not yet a repeatable workflow. The process must preserve the same system logic, context, constraints, and review criteria whenever the task is repeated.
Founder of Design Systems Surf
A designer writes a detailed prompt to adapt a color system to a new brand. The result feels coherent, preserves semantic roles, and appears ready for review. A month later, another designer reuses the prompt in a new chat with an updated Figma file. Some roles are interpreted differently, contrast checks become inconsistent, and the model introduces values the first designer would have rejected.
The first result depended on more than the prompt. It also relied on local knowledge, previous messages, remembered constraints, and an experienced reviewer.
The wording was reusable, but the workflow was not. Repeatable design-system work begins when those hidden conditions become part of the process.
The same prompt can still produce a different system decision
Prompts look like the reusable part of AI-assisted work. They describe the task, request a format, and may include detailed instructions about the expected result. But the same prompt can produce different system decisions when the surrounding context changes.
Consider a request to adapt an existing color foundation to a new brand. The prompt may ask AI to preserve semantic roles, generate accessible values, and keep the scale compact. It still does not explain which roles already exist, how brand and interaction colors relate, which states must remain distinct, or where exceptions are allowed.
The first designer may know this context. They reject a brand color that fails in a focus state, notice when selected and primary states begin to overlap, and understand which token names must remain stable for implementation. Their review supplies the missing logic.
A reusable prompt repeats the request. A repeatable workflow preserves the conditions that make the answer acceptable.
When another person repeats the prompt, that knowledge may be absent. AI follows the visible instructions and creates a plausible result, but the decisions are no longer anchored to the same system.
Repeatability is not whether the output looks similar. It is whether another person can use current materials and reach a result that follows the same roles, constraints, and review standards.
The workflow starts before the prompt
A prompt should not rebuild the system every time a task begins. Before AI can adapt a color foundation, it needs a current explanation of the palette, semantic roles, states, modes, naming logic, and decisions that remain open.
The prompt can then focus on the current task instead of carrying every piece of background knowledge. This makes the workflow easier to repeat across different users, chats, and source files.
The prompt describes what should happen now. The context explains what must remain true while it happens.
The task also needs a clear boundary. “Improve this color system” allows AI to reinterpret almost everything. “Adapt the palette to the new brand while preserving semantic roles, state logic, token names, and contrast requirements” defines what may change and what must remain stable.
GitLab Pajamas follows a similar principle for system contributions. Work begins with an issue or merge request and is classified by scope before implementation. Core contributions are expected to include design specifications, Figma assets, code, documentation, accessibility compliance, and ongoing maintenance. The task enters an explicit system context before the final asset is produced.
This principle applies across different Foundation areas. A Spacing task may change the scale while preserving grouping and density logic. A Layout task may explore containers without replacing the breakpoint model. Radius, Border, Elevation, and Motion require different context, but each workflow should explain the current decision model before asking AI to modify it.
Within Color Foundation, the Figma file provides the working token structure, while the AI context explains purpose, roles, naming logic, states, modes, and assumptions that values alone cannot safely communicate. Setup guidance also establishes whether the task starts from a new system, an existing brand, or an audit of current decisions.
An AI-ready workflow begins with a system that can introduce itself consistently, rather than depending on one person to reconstruct that context in every chat.
A cleaner result can still weaken the system
Stable context and a bounded prompt improve the output, but review is still necessary. AI can follow the system and produce a cleaner decision that weakens real product hierarchy.
For example, an audit may simplify a type scale, remove duplication, and improve naming while making page titles, section headings, labels, or body text less effective across real content and responsive contexts.
Review should not ask only whether the result is cleaner. It should test whether the decision still supports the system’s real content, constraints, and implementation needs.
Typography Foundation connects the visible scale to semantic hierarchy, responsive use, readability, accessibility, and implementation guidance. These materials provide a stronger review model than a general instruction to check the result.
Accessibility guidance makes constraints visible before they become late-stage corrections. Developer handoff reveals whether the proposal can move into implementation without losing naming logic or creating unsupported mappings. Task-specific prompts direct attention to the risks of the current Foundation area.
Review is not a final human glance after AI finishes. It is part of the workflow definition.
IBM Carbon applies the same principle across several forms of guidance. Its components and patterns include usage, style, code, and accessibility documentation. Together, these materials explain how the same element should be selected, presented, implemented, and made accessible. A reusable contribution therefore requires more than a completed visual or coded asset.
The criteria must reflect the decision being reviewed. Color requires checks for semantic separation, state coverage, contrast, and modes. Typography requires checks for hierarchy, reading conditions, responsive behavior, and implementation fit. Other Foundations require their own constraints and failure conditions.
The workflow can remain consistent across all eight areas even when the content of the review changes. This makes the process reusable without treating every Foundation problem as the same type of decision.
A reviewed result can still remain one-off
A reviewed answer remains a one-off result if it stays inside the chat. An approved color system may be added to Figma while the AI context still describes the old role structure. Token names may change without updating developer handoff, or a new contrast boundary may be discovered without reaching accessibility guidance. The next task then begins with outdated assumptions.
A workflow becomes repeatable only when the approved decision returns to the materials used next time.
Shopify Polaris closes this cycle through explicit migrations. Polaris Migrator translates deprecated component properties, token names, and implementation patterns into documented replacements. The updated decision becomes a transformation that another team can apply, rather than something reconstructed from previous examples, individual experience, or an earlier AI conversation.
The same principle applies to Foundation work. An approved change may require updates to the Figma file, usage guidance, developer handoff, accessibility notes, or AI context. Not every task changes every representation, but the workflow should show which ones are affected.
Successful work becomes reusable only when the accepted decision updates the system that will guide the next task. Otherwise, the result may be approved while its logic becomes hidden knowledge again.
The cycle begins with current context, frames a bounded task, reviews the result against defined criteria, and returns accepted changes to the working system. The next task then starts from an improved version of that system rather than from assumptions left inside the previous chat.
This becomes concrete across Foundation products. The Figma file holds the working model, setup guidance defines how to begin, AI context explains the decision logic, prompts frame bounded tasks, and accessibility and developer handoff support review and transfer. The content changes across Color, Typography, Spacing, Layout, Radius, Elevation, Border, and Motion, but the workflow remains consistent.
Repeatability closes the loop
A saved prompt can repeat the same request. A repeatable workflow preserves the system logic, boundaries, review standards, and path back into the system each time that request is made.
The goal is not to produce identical AI answers. It is to ensure that every accepted answer remains accountable to the same design-system decisions, and that each approved change becomes part of the context used next time.
