Lovable Drafts: explore different pages before deciding what goes live
Lovable builds web apps through conversation. Drafts give creators and collaborators separate previews for trying pages, copy and layouts before bringing a chosen direction into the project and publishing it.
Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.
How would you help a team compare drafts for the same goal?
Scenario
A team is using an AI site builder for a course homepage and exploring three directions: outcomes first, syllabus first and instructor first. Each is edited in a separate draft. Design an entry point for choosing a direction based on a first-time visitor’s needs while recognizing whether all drafts still use the same course information.
Given conditions and requirements
Design a draft-comparison entry point for an AI website builder.
- The team keeps three homepage directions with separate chats. A member has just changed the main project version.
- Users need to decide which page better serves first-time visitors, rather than simply choosing a preferred color.
- You may add at most one comparison view and cannot require people to learn Git first.
- Explain what the view shows, how it prevents comparisons across different content baselines, and how it preserves reasons for a choice. Do not assume the system can automatically judge conversion effects.
Work through this case
The main project changes the course from six lessons to eight. Drafts A and B still say six while C says eight. Show how the comparison view exposes this difference before the team evaluates page organization, so content freshness is not mistaken for a better design direction.
What to deliver
Deliver a comparison-view sketch, a flow from entry to recording a choice, and a task asking users to explain why they chose a draft and what remains unverified. Three polished page designs or invented conversion figures are unnecessary.
Explore the reasoning
- Define the comparison unit. Separate page direction, copy and screen width. Different course information can hide behind visual differences. You could show the source version and a difference notice, but compulsory updates also impose waiting costs.
- Bring the question into the view. A place for goals or checks, such as whether visitors can identify the intended audience, may support the decision better than showing every pixel difference by default. People confirm the checks; a model score is not an experiment result.
- Keep the reason and the rejected direction. The reason can be brief. Recording it should help people understand the decision later without turning experimentation into paperwork. Compare individual choices with decisions that need team approval.
- Validate through observed tasks. Give participants three pages with slightly different content and see whether they notice the baseline change and can explain their choice. Also try a narrow screen and returning from editing. Only report effects after actually running the experiment.
How would you explain shared data inside an unpublished draft?
Scenario
You are designing draft preview for a course-registration app. Page wording is not public yet, but the preview uses the same registration records as the live app: browsing reads them, a test submission adds a real record, and deletion changes real data. Help nontechnical users distinguish an unpublished page from an action without real data effects, explaining the impact at the appropriate moment.
Given conditions and requirements
The draft's page changes are not published, but it uses real application data. Design a way for nontechnical users to understand this boundary.
- Users will browse a list, submit a test registration and delete a record. These actions have different effects.
- Do not turn every click into a confirmation dialog or claim that deleting a draft restores its data.
- Specify where to place state information, when to request confirmation and what feedback follows the operation.
- Explain how to tell whether users understand shared data rather than mistakenly believing the whole draft is already live.
Work through this case
A user adds “Test student” in a draft, then deletes the page draft expecting the test record to disappear too. Design the before/after information so they can predict what happens to the real record without knowing database terminology.
What to deliver
Deliver a table of reminder placement/intensity for the three actions, a complete feedback flow for a write or deletion, and a comprehension check about what remains after deleting a draft. Do not invent undo or recovery features where none are specified.
Explore the reasoning
- Separate the page version from the data object. A persistent indicator can identify the draft, while shared data needs its own understandable name and scope. One “test” label should not carry both meanings.
- Match the reminder to the impact. Read-only browsing suits a low-interruption notice; deletion or bulk writes need concrete impact information near the action. Confirmation does not make recovery concerns disappear.
- Point feedback at the actual outcome. Explain where a new record went. If recovery is needed, identify the real recovery route or make clear that deleting the draft cannot undo the write.
- Check predictions rather than repeated wording. Before a click, ask what will change. Then ask whether the record remains after deleting the draft. Observe the point of confusion and adjust wording and placement.