State what the screen is for
Open the design at a realistic size and describe the person using it. What are they trying to accomplish? What do they already know? A checkout page, a photo editor, and a weekly report need different kinds of hierarchy. A critique without a purpose can drift into preferences about colors and rounded corners.
Ask Rayito to read the screen before proposing improvements. Keep any relevant state visible, such as a selected tab or an error message. If you are reviewing a mockup, say so. A static design cannot demonstrate keyboard behavior or what happens after a button is pressed.
Follow attention before changing decoration
Identify the first element that attracts attention, then the next. Does that sequence match the intended task? The example above singles out one primary action and a grouping boundary. Those are separate observations that can be discussed without covering the entire interface in marks.
A visual walkthrough should point to the region being discussed while the explanation stays short. If the problem is competing emphasis, show the competing elements together. If the problem is spacing, mark the relevant gap. A generic red circle is less useful than an annotation that explains the relationship.
Turn an observation into a hypothesis
Instead of saying a page is cluttered, describe the consequence: two buttons appear equally important, or a label looks closer to the wrong field. Then propose a specific change and the expected result. That gives the team something they can inspect or test.
Be careful with claims about accessibility. Visible text contrast, labels, and layout can be discussed from the screen, but a screenshot cannot prove that a control has an accessible name or works with a keyboard. Check those behaviors in the actual application with the appropriate tools.
Compare alternatives without losing the original
Try one change at a time. Reduce a competing emphasis, adjust one spacing relationship, or clarify one label. Keep the original visible long enough to compare the intended effect. A complete restyle may look different while leaving the underlying problem unresolved.
Rayito can help describe these alternatives with annotations and short explanations. If you want it to perform an edit in a supported app-control session, request that separately and review the proposed action. Feedback and editing are related activities, but they should remain distinct decisions.
End with a small decision, not a giant critique
Choose the one or two changes most likely to help the person complete the task. Record why you chose them and what would count as an improvement. That might mean a clearer first action, fewer ambiguous labels, or a more understandable empty state.
A useful review leaves the designer with a direction and room for judgment. It does not pretend that the assistant has measured user behavior from one screenshot. Use the visible evidence to form a better question, then validate it with the real interface and the people who use it.
A question to try“Review this screen for someone trying to finish the main task. Show me the biggest source of confusion and explain one focused change that could help.”