Turn an interface brief into a usable, testable implementation.

Choose tools around the interaction, not the screenshot

The example is a reading-list interface with a URL field, a saved-items list, and recoverable errors. The design task is to make each state understandable: first use, saving, success, duplicate, invalid input, and storage failure. A polished default screenshot proves only one of those states.

Use a design canvas when you need to compare flows and visual directions with other people. Use a browser prototype when the main uncertainty is interaction. Keep your existing component library if it already expresses the product; a generated mockup should not quietly replace its accessibility behavior or invent a second design system.

Make a state inventory before giving the agent a design prompt

Build the reading-list flow from the agreed brief.
States: empty, typing, invalid URL, saving, saved, duplicate, storage unavailable.
Keep the user's input after a recoverable error. Disable repeated submission
while saving, but leave the rest of the page usable. Announce status changes
to assistive technology and preserve a sensible keyboard focus order.
Show a compact layout at 360px and a wider layout at 1280px.
Use our existing components. Return the state inventory and browser checks
actually performed; distinguish unchecked behavior from passing behavior.

For each state, specify the user's next useful action. An error should help someone correct input or retry; a red box with ‘something went wrong’ gives neither. Use real-length labels and a long saved title before judging spacing. Test with the keyboard before decorating hover states.

The linked agent skill includes a disposable browser lab, source files, a review rubric, and a structured issue format. Start by intentionally triggering the bad cases. Record what you saw and the exact steps, then change one behavior and recheck it. Keep a separate list of aesthetic preferences so they do not hide broken interactions.

Make the prototype and the browser agree

In your design canvas, create four frames named Empty, Invalid URL, Saved, and Storage unavailable. Keep the URL field and Save link control in the same location. Mark Empty as the start. Make separate invalid and valid input scenarios so each Save link hotspot has one unambiguous destination. The failure frame retains the entered value and gives a retry path. These frames explain intended behavior; they cannot prove storage works.

In the portable reading-list kit, enter https://example.org/article with title Example article and activate Save link. Expect one row. Save the same URL again: expect one row plus duplicate feedback. Reload: the kit should retain it in browser storage. The standalone tutorial lab instead uses memory and intentionally resets on reload; choose the expected result for the artifact you are testing.

For validation, type javascript:alert(1) into the URL form without navigating to it. Submit and check that no link is created, the text stays available to correct, and the error is associated with the field. Simulate storage failure using the chosen artifact's failure control, then retry. Test the same journey with keyboard navigation and a narrow viewport.

Artifact and version:
State: Empty / Invalid URL / Saved / Storage unavailable
Input and exact actions:
Expected screen and stored state:
Observed screen and stored state:
Pass / fail / not tested:
Reproduction and remaining gap:

Complete one record per state. A screenshot supports a visual finding, while reload and row-count checks support persistence. Keyboard and visual inspection do not by themselves establish screen-reader conformance. Keep those verification claims separate.