UI States and Wireframe Review Checklist

A wireframe is useful when it resolves a question: Can a visitor find a product? Can an agent identify the next ticket? Is the next onboarding step understandable? Name the primary task and what feedback you need before adding screens.

Separate layout decisions from working behavior. Vinyasa provides an editable prototype document, not a connected application. A linked button can demonstrate a screen transition without authenticating a user, submitting a form or saving a record.

Use separately named pages for representative states. Link actions explicitly and label static sample content. You do not need every state for every control; cover the ones that materially affect the task.

Walk from the entry page to completion. Then test the conceptual reverse journey: going back, cancelling, changing a selection and retrying after failure. Verify page IDs and navigation targets in the document.

A prototype link does not imply that form values persist between screens. Note the required behavior in the brief. The onboarding example demonstrates a forward/back wizard; the booking example demonstrates returning from a summary to selection.

Check the main action, heading hierarchy, visible labels and the relationship between nearby controls. Prefer meaningful frame rows and columns over accidental visual proximity. Look for overflow, excessive density and labels that become ambiguous when they wrap.

Try long names, longer translated labels, missing images, zero values and unusually large counts. A mobile-width page and a desktop page can document alternative compositions, but do not generate responsive CSS. Specify which content reflows, hides or changes order in the production layout.

Review whether meaning depends only on color, fields have understandable labels, errors explain a correction and actions have enough visual distinction. Plan keyboard order, focus after navigation, error announcements and accessible names.

A visual canvas does not prove semantic HTML, screen-reader support or WCAG compliance in the future application. Implement and test those requirements in the final UI. For tables and charts, specify how people can access the information without relying solely on visual position or color.

Ask for one bounded change with explicit elements or page IDs. Compare the proposal against the request: additions, removals, property updates and affected links. Validate the document, then inspect whether the resulting design is useful. Schema validity does not prove that the layout, copy or workflow is correct.

Keep unrelated elements unchanged where possible. If the canvas changed after a text draft was created, reload and reconcile it deliberately rather than overwriting newer work. See AI proposal review and YAML revision practices.

Keep an editable .rvv project and a description of the reviewed revision. Include document YAML when a structured diff helps. Share PNG/SVG for visual discussion, but do not treat an image as the editable source.

List the behavior still to implement: data sources, validation, authentication, permissions, persistence, transactions, error recovery, accessibility, responsive layout and deployment. Use synthetic data and remove secrets before sending document content to a provider, coding agent or reviewer.

Return to the example library to choose a starting workflow rather than recreating the same form or list from scratch.