Lovable UI design without the AI look

Ask Lovable for "a landing page for my app" and you'll get something that works and looks familiar: a purple gradient, a glowing badge, three cards with icons, and a headline about unlocking your potential. None of it is wrong. It just looks like it was made by the same tool as everyone else's, and visitors notice.

Example task used in this guide: redesign the hero and features section of a SaaS homepage built in Lovable, so it stops looking generated.

Why Lovable apps look alike

When a request doesn't say how something should look, Lovable fills the gaps with the most common choices it has seen. Common choices are safe, which is exactly why they feel generic. The fix isn't a longer prompt full of adjectives like "modern" and "clean". It's a concrete direction: specific colors with jobs, a type pairing, and a few things it must never do.

Pick a real direction first

The quickest way to get a concrete direction is to borrow one from a real website whose style fits your product, then make it yours. With UXKIN connected, Lovable can call find_ui_materials with something like "light editorial SaaS" and get real design systems back, each with its colors and what they're used for, its fonts, and its components.

One result for that search is Equals: warm cream background, black text, a condensed serif for headlines at regular weight, and a single violet reserved for the main button. Sections are split by thin black lines instead of shadowed cards. That's a direction you can describe in a few rules, and it looks nothing like the default.

Don't paste the whole design system into the chat and say "copy this". Take the decisions (palette roles, type, how sections are separated) and keep your own words, logo and images.

Put the rules in Knowledge

Lovable includes Knowledge with every request in a project, so design rules written there apply to every new page without repeating them. Open Project settings → Knowledge and add short, checkable rules. For the direction above:

Design rules (follow them on every page):

- Colors: page background #FAF9F5 (warm cream), text #000000, secondary text #646462. One accent, #B074CE, used only on the main call-to-action button.
- Type: headings in a condensed serif at regular weight (never bold), body in a tight sans-serif. Headings are large; weight stays 400.
- Sections are separated by 1px black rules, not by cards with shadows.
- No gradients, no glow, no glassmorphism, no floating blobs, no emoji in headings.
- Buttons: one primary per screen. Pill-shaped primary, square-cornered inputs.
- Copy: say what the product does in plain words. No "unlock", "supercharge", "seamless" or "next level".
- Every page must work at 390px wide.

Rules work when you could check them by looking: "one accent color, only on the main button" is checkable; "make it feel premium" isn't. If you build several apps in the same style, put the shared rules in workspace Knowledge instead.

Rebuild one section at a time

Asking for a full redesign in one message tends to break things that worked. Go section by section: the hero first, then features, then pricing. After each one, look at it on a phone width and a desktop width before moving on. If something drifts (a gradient creeps back, a second accent color appears), point at the rule in Knowledge rather than describing the fix again.

Check it before you publish

Two quick checks catch most of what makes a site look generated:

• Run the AI Slop Detector on your published preview. It lists the giveaways it finds, like gradient text, emoji headings, buzzwords and identical card grids, so you know exactly what to ask Lovable to remove.
• Read the headline out loud. If it could describe any product ("Supercharge your workflow"), rewrite it so it could only describe yours.

Connect UXKIN to Lovable

UXKIN connects to Lovable as a custom MCP server, which Lovable calls a chat connector. It's personal to your account and only used while you build; your published app never calls it.

1. In Lovable, open Connectors (from the dashboard sidebar, or the + menu in a project's chat).
2. Click + and choose MCP server.
3. Server name: UXKIN. Server URL:

https://uxkin.com/mcp

4. Leave authentication on OAuth and click Add & authorize. A UXKIN page opens: log in and click Allow.
5. Back in a project chat, ask Lovable to use UXKIN for the next design task. It can now call find_ui_materials for website design systems and find_ui_references for real app screens and flows.

If sign-in doesn't complete, add the server again with Bearer token or API key and paste the token from your setup prompt. Treat that token like a password.

A prompt you can use

Adapt it to your own page. It asks for one reference, names the decisions to take from it, and keeps the scope small:

Redesign the homepage hero and the features section. Keep the content and the sign-up form working; change only how it looks.

If the UXKIN connector is available, use find_ui_materials with "light editorial SaaS" and pick the best match. Tell me which site you chose and the three design decisions you're taking from it (colors, type, layout). Use its DESIGN.md as the style reference, not as content to copy: our words and logo stay ours.

Follow the design rules in Knowledge. Then:
- Hero: one headline that says what we do, one sentence under it, one primary button.
- Features: a simple list separated by thin rules, no icon cards.
- Remove gradients, glows and emoji.

Show me the hero at 390px and 1440px when you're done.

Questions