Turn a visual reference into a testable brief
Three cards can look right in a desktop screenshot and still push a phone page sideways. Asking an agent to “make it responsive” leaves the important decisions open: which widths matter, whether long titles can wrap, and what each action should do. Define those results before changing the code, then use the browser to check them.
This walkthrough uses a fictional project overview with three cards. The prompts, CSS, and comparison below are a teaching example, not a recorded Onevium run or a measured customer result. They give you inputs and expected outcomes to reproduce in your own project; only checks you actually perform belong in a test report.
Start with an existing front-end project whose dependencies and local preview already work. In Onevium, open that project's conversation and confirm its working directory. If you have a screenshot or exported design reference, attach it and explain which details to preserve. A desktop image alone does not specify mobile layout, keyboard behavior, or link destinations; the written brief below supplies those decisions even without an image.
Give the first pass complete inputs
Use a local demo route so you can inspect the design without changing a live customer workflow. Keep the existing fonts, colors, and focus styles; the example's dimensions are layout choices for this exercise, not universal design rules. Send this brief in the project conversation:
Build a local /design-review page in this project.
First inspect the README, package scripts, route structure,
existing components, and current diff. Preserve unrelated work.
Use the existing framework and styling system; add no dependencies.
Heading: Team projects
Intro: Review the next handoff for each project.
Show these three cards in this order:
1. Website refresh — Design review
Check the homepage hierarchy before implementation.
2. Customer support portal — In progress
Confirm the empty state and keyboard navigation.
3. Coordinate international launch reviews — Ready for review
Review the longer title without hiding any words.
Each card has a heading, status, description, and a real link
labelled Review notes. All three links go to #review-notes.
Below the cards, add that section with this text:
Demo review notes. Confirm layout and navigation before handoff.
Mark the page as fictional sample content. No backend or sign-in.
Reuse project typography, colors, borders, and visible focus styles.
At 100% zoom, target three columns at 1440px viewport width,
two at 768px, and one at 390px. Cap the card grid at 1120px,
leave 24px on each side, and use 24px gaps.
Show full titles and status text; do not truncate them to fit.
At 390px, the page must not scroll horizontally.
Run the project's available checks and report their exact results.
Start or reuse its local preview and return the actual URL.
List changed files and any checks you could not perform.
Do not commit, deploy, or change unrelated routes.Inspect the rendered page before giving feedback
Check the preview's actual port and /design-review route. A running process is not proof that the new page loaded: confirm the heading, all three card titles, and the review-notes section. If startup fails, resolve that first instead of treating an old tab or a blank page as the new implementation.
To let the agent inspect the page, enable AI browser control in Settings → Browser and explicitly ask for Onevium's built-in browser. Verify the actual target. For an existing tab, use its toolbar menu to change the viewport; keep page zoom at 100% during width comparisons. Follow the browser tutorial for backend setup and approvals.
Capture the same page at 1440, 768, and 390 CSS pixels wide, including content below the fold. Compare hierarchy, spacing, text wrapping, and action placement with the brief. Record the viewport, visible mismatch, and expected behavior before asking for another edit; “make it cleaner” gives the next pass no clear stopping condition.
Fix one observed mismatch, then compare again
Suppose the first pass uses a non-wrapping flex row and gives every card a 320px minimum width. Three cards plus two 24px gaps require at least 1008px, while the 390px viewport has only 342px after side padding. That explains the overflow; reducing the font size would leave the layout constraint intact.
For that specific failure, a focused follow-up is: “At 390px, the cards overflow horizontally. Replace the fixed row with a grid that fits the available width. Keep all text, card order, links, and visual tokens. Recheck 390, 768, and 1440px; show the changed rule and the observed result at each width.” Use this feedback only if your preview shows the same problem.
The illustrative CSS below replaces the conflicting row and card-width rules. Scope it to the demo component, and remove or override the old minimum width. The grid can shrink to its container; the card rule allows its content box to shrink too. Long unbroken identifiers may need a separate wrapping rule. Verify the resulting layout rather than assuming this snippet fits every surrounding stylesheet.
| Check | Example failure | Target after the edit |
|---|---|---|
| 390px layout | A fixed row pushes later cards off screen | One column; all three cards visible; no page overflow |
| Long title | Text is clipped to make the card fit | Every word remains readable and wraps inside the card |
| 768px / 1440px | The narrow-width fix changes every size to one column | Two / three columns, with the original card order |
| Review notes links | Actions look correct but have no destination | Each link reaches the visible review-notes section |
/* Before: the row cannot wrap; cards cannot shrink below 320px. */
.project-grid { display: flex; gap: 24px; }
.project-card { min-width: 320px; }
/* After: replace the rules above, scoped to the demo. */
.project-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 288px), 1fr));
gap: 24px;
width: calc(100% - 48px);
max-width: 1120px;
margin-inline: auto;
}
.project-card { min-width: 0; }Record what passed and what remains untested
After each layout edit, rerun the affected checks. A screenshot supports a visual observation at one size; it cannot prove that a link works, that keyboard focus is usable, or that another browser behaves the same way. Build success and browser acceptance belong in separate rows of the handoff.
- Layout: at 390, 768, and 1440px, inspect the top and bottom of the page, full card text, column count, and horizontal overflow. Resize between those widths to catch problems hidden by the three snapshots.
- Interaction: click each Review notes link, then use Tab and Enter to test them with the keyboard. Confirm visible focus, logical order, and a destination that is not hidden behind a fixed header.
- Readability: separately try browser zoom at 200%, check text and status contrast, and look for clipped content. Restore 100% before repeating the original width comparison.
- Project checks: run the available lint, type-check, test, and build commands from the project. Record failures as failures; report absent scripts and unavailable target browsers as not tested.
URL and code revision/diff:
Browser, viewport, and zoom:
Scenario and action:
Expected result:
Observed result:
Evidence (screenshot, command output, or reproduction steps):
Status: passed / failed / not tested
Remaining issue and next check:Keep human review in the handoff
Review the diff and the rendered page yourself before accepting the change. Decide whether the hierarchy, copy, spacing, and interaction suit the product. Agent-assisted screenshots and checks can identify defects, but they do not replace design judgment or complete accessibility review.
This exercise has no real form submission, authentication, or API state. Adding those later creates new loading, empty, error, and permission cases. A narrow browser viewport also does not reproduce a physical phone's touch input or every target browser. Keep unperformed device and assistive-technology checks visible in the handoff instead of marking the interface production-ready.
The useful result is a scoped diff plus a reviewable record of what happened. Continue with the browser tutorial to configure inspection, or the development-services tutorial if the preview is not ready. Commit and release decisions come after the agreed acceptance checks.