Lovable prompting guide: how to get production-grade UI

To get production-grade UI out of Lovable, set up your design rules before you build a single screen, then prompt one change at a time against named components, and describe the empty, loading and error states every time you ask for a screen. Use Lovable's own tools for the rest: Knowledge for rules that apply to every prompt, Plan mode before big changes, and the preview toolbar for small visual fixes.

Lovable maintains its own prompting guide in its documentation, the one a lot of people search for as the Lovable prompting bible, and it is worth reading. This is the designer's version: what we would put in place before the first prompt, and how we write prompts so the app ends up with one design system instead of forty.

Why Lovable UI drifts

Lovable's documentation says that when you send a message it reads your project knowledge, your workspace knowledge and your code before making changes. If the knowledge is empty and the message says "add a settings page", it fills every gap with sensible defaults. Sensible defaults chosen fresh each time are exactly how an app ends up with four slightly different cards.

The most common thing we find when we audit Lovable apps is near-duplicate components: a few cards, two modals and a handful of button styles, each built by a different prompt and each almost right. The fix is to make fewer design decisions inside prompts and more of them in the places Lovable reads every time.

1. Set the design rules before the first screen

Lovable's Knowledge setting works at two levels. Workspace knowledge applies to every project in the workspace, and project knowledge to a single app. The docs list design guidelines, including colours, typography and layout, among the things project knowledge is for, and each field takes up to 10,000 characters. That is plenty for a working design system.

What we put in it:

• Colour tokens with names and jobs: background, surface, border, text, muted text, accent, success, warning and danger. Hex values, plus one line on when each is used.
• A type scale: five or six sizes, which one is for page titles, section headings, body and labels, and the two weights you allow.
• A spacing scale: for example 4, 8, 12, 16, 24, 32 and 48, and a rule that nothing uses a value outside it.
• Radius and shadow: one radius for controls, one for cards, and whether shadows exist at all.
• Component rules: one primary button per screen, destructive actions in the danger colour, tables rather than cards for data with more than three columns.
• State rules: every list has an empty state with one action, every data load shows a skeleton, every error says what happened and what to do next.
• Voice: how buttons and errors are written. Buttons say what they do, such as "Create invoice".

On a paid plan you can go further. Lovable's design systems feature lets you define a component library, tokens and guidelines once, as a project of its own, and attach it to other projects. If you are building more than one app, or expect to, that is the better home for all of the above.

If the design already exists in Figma, start there. Lovable can import from Figma through a plugin, through the Figma MCP, or by uploading a .fig file, which its docs say brings across variables, colours, typography and frame structure.

2. Reference real components, by name

Lovable's guide recommends what it calls atomic vocabulary: naming the specific elements you want, such as cards, badges, toggles and modals. Go one step further and name the components that already exist in your app, so Lovable reuses them.

A useful habit is to ask Lovable, in Chat mode, to list the components the project already has and where they live. Chat mode discusses the project without changing any code, and the docs position it as the cheaper option for open questions, so it is the right place to get the names straight before you ask for anything.

3. Describe the states, every time

Lovable builds the screen you describe, usually populated with tidy sample data. Unless you ask, it will rarely decide for you what happens when there is no data yet, while the data is loading, or when the request fails, and those are the screens a new user meets first. We covered why they matter in empty states. In prompting terms, every screen prompt should carry a short paragraph on states:

• Empty: what the user sees on first use, what it says, and the one action that gets them out of it.
• Loading: skeleton rows or cards in the shape of the real content.
• Error: what went wrong in plain words, and a retry or a way back.
• No results: for any search or filter, with a way to clear it.
• No permission: what someone without access sees, if the screen can be shared.

Lovable's own guide makes a similar point about planning for authentication states and empty, loading and error states when the app uses its built-in backend. In practice that advice gets skipped more than any other.

4. One change per prompt

Lovable's guide says to build one component, review it, refine it and then move on, and to state what must stay untouched. That habit is the single biggest difference between apps that stay coherent and apps that drift. A prompt asking for a new page, a colour change and a bug fix at once gives the model three chances to touch something you wanted left alone.

For anything bigger than one component, use Plan mode first. Lovable's chat has three modes, Chat, Plan and Build, and Plan investigates the project and writes a plan you can edit and approve before any code changes. Approving it switches to Build mode, which older guides call Agent mode, to carry it out. Reading a plan takes a minute, and it is where you catch "I will also restyle the header" before it happens. The guide also suggests ending a prompt by asking Lovable to ask you any questions it needs answered first, which works well alongside Plan mode.

5. Use Lovable's own tools for small fixes

• The preview toolbar. It has replaced the old Visual edits panel. Select an element, or several by holding Cmd or Ctrl, and describe the change, and the prompt applies to that element only. Inline text editing handles copy changes directly and comes with a free daily allowance before it uses credits.
• Draw annotation. Sketch on the preview and Lovable receives the sketch with your message, which beats describing "the thing on the left, under the other thing".
• Screenshots and files. You can attach images to a message or take a screenshot from the chat, so show Lovable a reference screen or the exact problem.
• Version history. Every change is saved as a version you can revert to, and you can bookmark the ones that work before trying anything risky. Reverting restores the code only, and the docs are clear that database data and migrations stay as they are.
• GitHub sync. Connect the project to GitHub and the code lives in a repository you own, with two-way sync on one branch at a time. When a designer or developer joins later, that is how they get in without anyone exporting files by hand.

Six prompts, rewritten

These are the kinds of prompt we see most in Lovable chat histories, and how we would send them instead.

• Bad: "Make the dashboard look more modern." Better: "On the Dashboard page only, replace the four stat cards with our StatCard component. Use the surface colour, 16px padding and the label text style from Knowledge. Do not change the chart or the sidebar."
• Bad: "Add a projects page." Better: "Add a Projects page that lists the user's projects in our Table component, with columns Name, Owner and Last updated. First use shows an empty state, 'Your projects will appear here', with one Create project button. Loading shows three skeleton rows. A failed load shows an inline error with a Retry button. Ask me any questions before you build."
• Bad: "Fix the buttons, they all look different." Better: In Chat mode first: "List every button style in this project and the file each one is in. Do not change any code." Then in Build mode: "Replace every primary button with the Button component, primary variant. Change nothing else."
• Bad: "The sign-up form is broken." Better: "On the Sign up form, when the password is too short the page reloads and clears every field. Keep what the user typed, show the password rule under the password field in the danger colour, and do not change the layout."
• Bad: "Make it work on mobile." Better: "Below 640px wide, show each row of the Invoices table as a stacked card with customer, amount and status, and move the row actions into a menu. Keep the desktop table exactly as it is."
• Bad: "Redesign onboarding, fix the login bug and make the brand green." Better: three separate prompts, in order. Fix the login bug and nothing else. Change the accent colour token to the new green everywhere it is used and update Knowledge to match. Then switch to Plan mode for the onboarding redesign and approve the plan before anything is built.

When prompting stops being enough

Good prompting slows drift down, but it cannot reverse drift that has already happened. If your app already has five button styles and a sign-up flow that loses people, the faster route is usually an audit and a cleanup, then prompting against a proper system from there on. You can see what that audit covers in our AI MVP audit checklist.