Workflow

How to make Cursor generate better frontend design

Use stable design memory instead of rewriting visual instructions in every chat.

April 28, 20267 min read

Keep DESIGN.md in-repo

Cursor performs better on UI tasks when the design brief is durable and local to the codebase, for one specific reason: context persistence. In-prompt design instructions apply only to the current conversation window. Once a session ends, those instructions are gone. When you reopen the project and ask Cursor to add a new component, it has no memory of the style guidance from last week. A DESIGN.md file in the repository root solves this fundamentally. Cursor can access and read it in every session, across every task. The file is also physically close to the code it governs — one directory level up from any component file — which makes it easy to reference, update when the design changes, and include in code reviews. Cursor can also be instructed to read the file automatically for all UI work using a .cursorrules directive, making the reference automatic rather than relying on per-prompt reminders.

Be explicit

Abstract guidance is the primary reason AI-generated UI drifts from the product design system. When Cursor is told "keep the design clean and professional," it applies its own interpretation of those words — which may differ from yours enough to require multiple correction rounds. Explicit guidance eliminates interpretation. Instead of "clean and professional," write "maximum one decorative element per page section, form inputs have 8px vertical padding, dividers are 1px in neutral-200, hover states change only background color not border or text color." Document the type scale with exact sizes: body text 15px, h1 32px weight 700, h2 24px weight 600, caption 12px weight 500. Document spacing: card padding is always 16px at standard density and 12px at compact density. Document interactive states: focus rings use a 2px blue outline with 2px offset; disabled states use 40% opacity. These exact values give Cursor something to match precisely rather than something to interpret creatively.

Setting up the file and path

Cursor uses several mechanisms for loading persistent design context. The most direct is to place DESIGN.md in the repository root and add a line in .cursorrules: "For all UI and frontend work, read DESIGN.md before proposing or implementing changes." This ensures every Cursor session that involves UI has the design spec available without needing to specify it manually in each prompt. A secondary approach is to use Cursor's @ mention syntax: "@DESIGN.md add a new profile settings page" causes Cursor to read the file before responding. For large DESIGN.md files, mentioning only the relevant sections in the @ reference is more efficient: "@DESIGN.md#components build a data table component following the table density rules." The .cursorrules approach is better for teams where multiple people use Cursor on the same project, because it makes the design reference automatic and consistent across all sessions regardless of individual prompting habits.

Prompt patterns that work

Specific prompt patterns produce reliably better design output from Cursor. Pattern one: declare the source before the task. "Read DESIGN.md, then build a subscription billing page with the standard form layout and destructive action button rules." This ensures the spec is loaded before implementation begins. Pattern two: ask for an audit before editing. "Read DESIGN.md and compare it against the existing SettingsPage component. List any violations before we start." This targets corrections at real gaps in the current implementation. Pattern three: set explicit acceptance criteria. "Implement the checkout form following these DESIGN.md rules: form layout, input spacing, button hierarchy, and validation display. Tell me which rules you followed and which you had to interpret." That structured request gives Cursor a checklist to work from. Pattern four: iterate by rule, not by complaint. When output is wrong, say "the heading weight should be 600 not 700 per the spec" rather than "this does not feel right."

Use for iteration

One of the most valuable uses of DESIGN.md with Cursor is the comparative review step: before making changes to an existing component, ask Cursor to compare the current implementation against DESIGN.md and explain any differences. This surfaces inconsistencies that accumulate over time — a card built before the radius rule was set to 8px, an empty state that uses a background fill when the spec prohibits background fills, a button using 14px padding when the current spec says 12px. Identifying these gaps before adding a new component allows cleanup and new work to happen in the same session, rather than accumulating design debt. It also gives Cursor a concrete reference for the new component: "make the new component consistent with the spec, and flag the two existing components that need updating to match." This turns spec maintenance into an active part of the development loop rather than a separate documentation task.

Building the feedback loop

The feedback loop between Cursor output and DESIGN.md is where design consistency compounds over time. Each session where Cursor generates UI is an opportunity to tighten the spec. When the output is correct, the relevant rules are confirmed as working — no action needed. When the output is wrong because the rule was unclear or missing, update DESIGN.md with a more specific version of that rule before the next session. Over twenty or thirty sessions of consistent use, this loop produces a spec that is empirically tested against real Cursor output. The file no longer reflects what you thought the design rules were — it reflects what actually produces correct output in practice. That distinction matters: a spec validated against real AI behavior is more reliable than one written in isolation, because it accounts for exactly the ambiguities and edge cases that produce real implementation mistakes in your specific codebase.

Use DESIGN.md with a real product reference

Browse curated DESIGN.md examples from product teams, design systems, developer tools, SaaS dashboards, and AI-native apps. Use them as references before your agent builds the next screen.

Browse directory Submit DESIGN.md

Related guides

Workflow7 min read