Direct answer
Review the screen's purpose first, its component system second, then its accessibility and responsive behavior in the browser.
Before implementation
- Name the user and the one task the screen must support.
- Choose the design system or extract the existing one.
- Identify the reusable components before creating new primitives.
- Write the primary action as a specific verb and outcome.
During implementation
- Use semantic tokens instead of page-specific colors and radii.
- Keep heading levels and action hierarchy clear.
- Use real buttons, links, labels, and form controls.
- Handle loading, empty, error, disabled, and success states that the flow can reach.
- Preserve the project's existing data and navigation behavior.
Rendered review
- Check text contrast and non-text contrast against WCAG requirements.
- Navigate the full task with a keyboard and confirm visible focus.
- Test the narrowest supported viewport for clipping and horizontal overflow.
- Open every changed menu, dialog, popover, and validation state.
- Respect reduced-motion preferences and avoid motion that blocks the task.
- Read the copy aloud and remove labels or explanations that repeat the same point.
What automated checks cannot prove
TypeScript, lint, and automated accessibility tests catch important failures, but they cannot prove that hierarchy is obvious, spacing feels coherent, copy is understandable, or an overlay looks correct over real content.
Treat the browser review as part of implementation. Capture the states that changed and compare them with the original screen job before reporting completion.
Questions
What is the first thing to check in AI-generated UI?
Check whether a first-time user can identify the screen's purpose and primary action without an explanation. If not, fix the hierarchy before polishing details.
Are automated accessibility tests enough?
No. They are necessary but incomplete. Keyboard flow, focus order, meaningful labels, responsive behavior, and visual clarity still need hands-on review.
Should every generated screen introduce new components?
No. New components are justified when existing primitives cannot express the needed behavior cleanly. Reusing the current system usually produces a more coherent product and a smaller diff.