Make precise visual website edits with AI

Capture the affected state before requesting the change. A menu that fails only after opening, a headline that breaks only with the real business name, or a form that overflows only after validation needs that context. Include the state in your request so the builder repairs the situation a visitor encounters. Otherwise it may improve the resting screenshot while leaving the original problem intact.

A visual edit works best when it starts with an observable problem. The headline may dominate the opening image, the navigation may look detached from the page, or the phone layout may hide the main action. These observations are more useful than asking for a premium, modern, or polished result. Name the element, explain how it interferes with the visitor's task, and describe the relationship you want to change.

Separate taste from usability. A color preference is a legitimate design choice, but it is different from insufficient text contrast. A large heading may suit an editorial portfolio while making a dense application harder to scan. Use the purpose of the page to judge the change. The goal is not to apply the same fashionable styling everywhere; it is to make this particular page clearer, more coherent, and easier to use.

Uvilno's canvas selection can attach an element target to the same conversation input you use for other requests. This helps distinguish one repeated button or heading from another. Selection supplies location; your instruction supplies intent. Say what should change and what the visitor should experience afterward. If the target appears on multiple pages, specify whether the request applies to one instance or the shared pattern throughout the site.

Before sending, confirm that the selected element belongs to the displayed version you mean to edit. If you restored another version or changed routes, recheck the context. Avoid piling unrelated selections into one ambiguous request. A targeted revision should remain understandable even when read later in conversation history. Mention the section or route in plain language so the request is useful beyond the temporary outline drawn around the element.

A screenshot can show a problem that is difficult to describe, such as an awkward image crop or a menu clipped on a phone. Attach it through the source controls and explain what it demonstrates. Include the route, approximate viewport, and state if the issue depends on an open menu or validation message. A screenshot of the resting page cannot show how focus moved, where a form submitted, or why a button failed, so add those details in text.

For a design reference, identify the qualities you want: a quieter header, a larger project image, or tighter caption spacing. Say which aspects should not be copied. Do not treat another business's screenshot as permission to reproduce its identity, photographs, reviews, or copy. Your own assets and verified facts should remain the content of the site. Reference-driven editing is most effective when the borrowed relationship is clear and the result still belongs to your project.

A useful edit names both the intended change and the parts that already work. Preserve the page order, palette, supplied photographs, and functioning interactions when those remain approved. This gives the builder a narrower problem and gives you a regression checklist. ‘Keep everything else the same’ is less helpful than naming the important boundaries, especially when the requested change touches shared spacing or typography that may legitimately affect several elements.

Think in coherent groups. Adjusting a heading's size, line length, and nearby introduction can be one visual decision. Adding a new account system while changing the heading is a separate decision with different verification needs. Split those requests. After an edit, inspect both the changed section and the neighboring content. A shorter heading may improve the first screen while exposing an awkward gap below it; a local fix still needs to fit the surrounding composition.

Many pages feel weak because the relationships are unclear, not because they need more effects. Check which element should be read first, which content belongs together, and where one section ends. Heading size, line length, alignment, and space can solve those problems directly. Increase the separation between distinct sections while keeping related labels and fields close. If every gap grows equally, the page becomes longer without becoming easier to understand.

Use the real copy when judging the result. A two-word sample title and a real seven-word service name create different line breaks. Check image focal points at desktop and phone widths; a beautiful wide crop may cut off a face on a narrow screen. Avoid asking for layers of shadows, gradients, and animation merely to compensate for weak structure. Decoration can support an approved direction, but it cannot make an unclear task or missing destination useful.

A desktop screenshot is only one arrangement. Describe the intended phone behavior when revising a layout: columns may stack, navigation may collapse, and secondary detail may move below the main action. Do not simply ask the builder to shrink everything. Text still needs a readable size, controls still need room, and the important journey should remain possible. Check an intermediate width as well as the largest and smallest previews when a layout changes dramatically.

Pay special attention to fixed and sticky elements. A floating action can be useful on a tall desktop but cover half a short phone screen when the keyboard opens. Menus and dialogs need a reachable close action, sensible internal scrolling, and focus behavior. Review long labels, validation messages, and expanded content rather than only the default state. A responsive design is a set of workable relationships, not a collection of screenshots with identical content scaled down.

Visual changes can affect behavior even when the request sounds cosmetic. Replacing a button with a styled text element can break keyboard use. Moving a form can detach its labels or obscure feedback. Changing an overlay can trap focus or let background content remain interactive. Ask the builder to preserve semantics and existing service connections, then actually test the control. A screenshot review and a behavior review answer different questions.

Test focus, hover, active, disabled, loading, and error states where relevant. The main action should remain identifiable without relying on color alone. Reduced-motion preferences should reduce decorative movement without hiding content or disabling essential behavior. If an edit changes the order of content, check the reading and tab order. A visually pleasing rearrangement that leaves keyboard focus jumping unpredictably is not a finished improvement.

After the revision completes, review the saved version named by the workspace. Compare it with the intended outcome, not just the previous screenshot. Did the original issue disappear? Did the preserved areas remain intact? Complete the primary task on desktop and phone. If the change missed the goal, explain the remaining difference precisely rather than requesting a fresh redesign. The accumulated context is useful when it stays focused.

Keep a known-good version before larger experiments. Restoration changes the displayed version; check it before making another request or exporting. A saved version is different from a recoverable unfinished draft, which may still contain unverified behavior. If you work through GitHub, review diffs and resolve conflicts before pushing a new release. Visual iteration becomes much less risky when you can name what changed, verify its effect, and return to a working baseline.