Lovable UI Prompts: 14 Design Templates for Screens and States

Which growth channels do these prompts serve?

Every prompt in this category carries a distribution section naming the channel it is built for, so the generated app has a way of being found rather than only a feature set. The chart counts primary and secondary coverage together, computed from the prompt bodies when the site is built.

What is a Lovable UI prompt, and why do most of them produce a screenshot rather than an interface?

A Lovable UI prompt is a Build mode message that names the components, the states and the responsive behaviour of one part of an interface, plus the look it should have. Lovable's prompting best practices put it as building "in modular parts, not full pages at once", with each prompt "like building with Lego bricks" that has "one clear purpose and structure" (read on 26 September 2026). A prompt that says "a clean, modern dashboard" fails that test twice: it names no part, and it names no state.

The look is the half most people get right, because it is the half Lovable makes easy. Its design guidance shows three design directions for any UI request unless the prompt "already commits to a concrete visual direction", which it defines as prompts that "specify fonts, colors, or branding", reference another product, paste a URL to copy, or use a named design system. So the visual side either gets one committed line in the prompt or a side-by-side choice of three before anything is built.

The states are the half that gets skipped, and no picker exists for them. Lovable's own prompts ask for them by name where they matter: its dashboard prompt ends with "include loading and empty states", and its dark mode prompt asks that "every page, chart, and form looks right in both themes" (prompt library, read the same day). The fourteen prompts here take that habit to its conclusion: every list, form and detail screen gets its empty, loading, error and partial states specified, and one prompt exists only to define them once for the whole app.

How is a UI prompt in this library built?

Every UI prompt follows the same skeleton, and the most useful one to read is the states system, because every other screen in the category inherits it. Its sections, read from the prompt body rather than described from memory, are below. The two newest, Visual Direction and Before Building, were added on 26 September 2026 from the rules in Lovable's docs: a committed look skips the three-direction step, and a closing "ask me any questions" line is what the best-practices page recommends adding to any prompt that needs context.

The State Rules section is where this prompt differs from a feature request. "Zero data and failed-to-load are never the same screen" is a rule about honesty, not styling: an app that renders an outage as an empty list hides the outage. "Skeletons match final layout dimensions" is a rule about layout shift. Neither is something Lovable will infer from "add loading states", which is why the prompt spells them out and then asks for a gallery page that renders every variant so the rules can be checked by eye.

What happened when we ran the states prompt in Lovable?

On 26 September 2026 we pasted the Empty States & Loading Skeletons prompt into a fresh project in Marco's own Lovable workspace, in Build mode, with the Visual Direction line removed as the prompt itself suggests. Before building anything, Lovable asked two questions, exactly as the Before Building line requests: who will use the app and what its screens show, and which screen should receive the states system first. We answered with a small team task tracker and chose its offer to create a representative screen. It then enabled Lovable Cloud for task data and sign-in, built the four base components, a gallery at /states and a working task-list screen, and reported that it had verified creation, completion, slow loading, failure and retry before removing its test data.

The gallery is the artifact. It renders first-use and cleared empties as separate cards, skeletons sized like the list rows and cards they replace with a stated 220 ms delay threshold and a replay control, retryable and non-retryable errors with a reference id on the second, a compact form failure, and a partial-data notice that keeps the rows that arrived. Every one of those is a line in the prompt's State Rules. Cost, read from the workspace's credit page before and after: the balance went from 77.3 to 72.8 credits and the 5 daily build credits were used first, so the whole run, Cloud provisioning and sign-in included, was 9.5 credits. That is the honest number to plan with for a system-level prompt, against 1.8 for the single landing page we ran in July.

How do these prompts differ from Lovable's own design prompts?

Lovable's prompt library opens with a "Design and style" section: six one-sentence prompts that each set a look (minimal, premium and glassmorphic, bold, playful, calm, editorial), plus "Show me three options for the hero section" and "Use the logo and color palette from @BrandSite". Its minimal prompt reads, in full: "Design the note-taking app with radical minimalism: a pure white background, a single centered column, neutral tones, no visual clutter, and soft, quiet transitions." That is a good visual brief, and it is exactly the kind of line the Visual Direction slot in each prompt here is for.

Use both. Paste one of Lovable's look sentences into the Visual Direction line of a prompt from this page, and you get the committed direction that skips the three-way picker plus the states, the accessibility rules and the build order that the look prompt does not carry. The library page also says to save the chosen direction to the project knowledge so "every later prompt builds on them automatically", which is what the Before Building line asks Lovable to do.

How does Lovable's design direction step work with these prompts?

If a prompt from this page goes in with the Visual Direction line left out, Lovable runs its design guidance flow before building. The steps, as its documentation describes them, are the flow below; the refine step allows at most six rounds, and the chosen direction is then locked in for the project. Fill the line with one committed sentence and the flow is skipped, which is the faster path once you know the look you want.

Either path is fine. What matters is that the look is decided once, saved to the project knowledge, and never restated in the prompts that follow. The design systems feature is the heavier version of the same idea: a dedicated project holding components, tokens and setup instructions that other projects connect to, one design system per project, React component libraries only.

Which UI/UX prompts do builders upvote most?

Every card on this page carries an upvote, one per visitor, and the cards are sorted by it. The counts below are read from the database when the page is rendered and refresh hourly, so they can lag a card by a vote or two. They are the first thing we look at when deciding which prompt in a category to extend.

Which UI prompt to use

If you are building the shell of an app, start with Responsive Navbar Builder and Custom Footer & Header Templates, then Settings & Preferences Panel UI. Those three cover the frame that every other screen sits inside, and getting them right once saves repeating the breakpoint work per page.

If you are displaying data, Analytics Dashboard UI and Table UI with Sorting & Filters are the two that matter, and the table prompt is the one to reach for when the dataset is large enough that virtual scrolling and URL-persisted filter state stop being optional.

If users have to do something multi-step, User Onboarding Flow UI and Modal & Dialog Component System handle the sequencing and the interruptions. File Upload + Tagging UI covers the case Lovable most often gets partially right, and it is the third most upvoted prompt in the whole library.

Suggested build order

The frame first, then the states, then the specific screens. Doing it in the reverse order means every screen invents its own loading treatment. Lovable's idea-to-app guide makes the same point from the other side: set the design direction early, because design problems are harder to fix later than to decide up front.

1. 1

   Build the frame

   Navigation and breakpoints once, not per page.

   Prompt: Responsive Navbar Builder

2. 2

   Define the states before the screens

   Empty, loading and error as a system. This is the single most consequential prompt in the category, because it changes every screen that follows.

   Prompt: Empty States & Loading Skeletons

3. 3

   Add the interruption pattern

   One dialog system, so confirmations and forms do not each get their own.

   Prompt: Modal & Dialog Component System

4. 4

   Then the data-heavy screens

   Tables and dashboards inherit the states and the frame rather than redefining them.

   Prompt: Table UI with Sorting & Filters

Where UI prompts usually go wrong

• Describing the aesthetic instead of the components. Lovable responds to named shadcn/ui components, spacing values and breakpoints. Words like sleek, minimal or premium only work inside a committed visual sentence of the kind Lovable's own library uses, where they sit next to a palette, a layout and a transition rule.
• Prompting screen by screen. Each screen then gets its own loading spinner, its own empty message and its own idea of what 8px means. Specify the system once and reference it. Lovable's best-practices page says the same about change prompts: name what to build, where it goes, and what must stay untouched.
• Forgetting the state where there is no data. It is the first thing a new user sees and the last thing anyone prompts for.
• Skipping the questions. A prompt this detailed has context Lovable cannot see, such as who the users are and what the screens hold. The Before Building line exists so it asks before spending credits, and in our run it asked exactly that.

Frequently asked

Sources

All checked on 26 September 2026.

• Lovable docs: Prompting best practices
• Lovable docs: Prompt library, Design and style
• Lovable docs: Design guidance
• Lovable docs: Design systems
• Lovable docs: How to build a real product with Lovable