0 pass · 0 fail · 0 not checked
01The main task is the easiest thing to do
Test: Give the screen to someone (or yourself, fresh) with only the goal. Can they start it within five seconds, without scrolling or opening a menu?
02Labels say what things are, in the product's words
Test: Read every heading, button and label out loud. Replace anything generic with the real name of the thing or action.
03Nothing relies on color alone
Test: Look at the screen in grayscale (or squint). Can you still tell late from on time, error from success?
04Every state is designed
Test: Trigger each: no data, slow loading, a failed request, a very long name, 100+ items. Each should look intentional and say what to do next.
05People can recover without losing work
Test: Fill in a form or set filters, then make the request fail. Is everything still there, with a clear way to try again?
06It works on a phone-sized screen
Test: Check at 390px wide. The main action is visible, nothing scrolls sideways, and tap targets are at least 44px.
07It works with a keyboard and a screen reader
Test: Use Tab only: reach every control, see where focus is, open and close any dialog. Inputs have labels and errors are announced.
08Text is readable
Test: Body text contrast is at least 4.5:1 (large text 3:1). Check text on images and on colored buttons too, and at 200% zoom.
09It belongs to this product
Test: Put it next to another screen of the product at the same width. Same buttons, spacing, type and words for the same things? Record any intended difference.
10The handoff is honest
Test: List what was actually checked (widths, states, keyboard) and what wasn't. Every failure above is either fixed and rechecked, or written down.
Paste the report back to your agent or into a pull request. Nothing is saved or sent anywhere.
How to use this checklist
Review the screen the way a person will use it, not the way it looks in a screenshot. Open the running app, do the main task, then break it: empty data, a failed request, a small screen, keyboard only. A check only counts when you've seen the result.
Mark each check Pass, Fail or Not checked, add a note for anything that isn't a pass, and copy the report. Fix the failures that are in scope, re-run those checks, and keep the rest visible in the report rather than dropping them.
The 10 checks, explained
1. The main task is the easiest thing to do
Every screen has one job. The action for that job should be the most visible thing, and everything else quieter.
Test: Give the screen to someone (or yourself, fresh) with only the goal. Can they start it within five seconds, without scrolling or opening a menu?
2. Labels say what things are, in the product's words
Placeholder copy ("Item 1", "Optimize", "Get started") hides whether the screen fits the real task.
Test: Read every heading, button and label out loud. Replace anything generic with the real name of the thing or action.
3. Nothing relies on color alone
Status shown only as a red or green dot is invisible to many people and in grayscale.
Test: Look at the screen in grayscale (or squint). Can you still tell late from on time, error from success?
4. Every state is designed
Agents build the happy path. Real users see empty, loading, error, long text and too many items.
Test: Trigger each: no data, slow loading, a failed request, a very long name, 100+ items. Each should look intentional and say what to do next.
5. People can recover without losing work
A failure that wipes a form or a filter turns a small problem into giving up.
Test: Fill in a form or set filters, then make the request fail. Is everything still there, with a clear way to try again?
6. It works on a phone-sized screen
Layouts built at desktop width often hide the main action or scroll sideways on phones.
Test: Check at 390px wide. The main action is visible, nothing scrolls sideways, and tap targets are at least 44px.
7. It works with a keyboard and a screen reader
A screenshot can't show whether a page can be used without a mouse.
Test: Use Tab only: reach every control, see where focus is, open and close any dialog. Inputs have labels and errors are announced.
8. Text is readable
Light gray on white and text over images are the most common failures in generated UI.
Test: Body text contrast is at least 4.5:1 (large text 3:1). Check text on images and on colored buttons too, and at 200% zoom.
9. It belongs to this product
A screen can look fine alone and still bring a second button style, spacing scale or status vocabulary.
Test: Put it next to another screen of the product at the same width. Same buttons, spacing, type and words for the same things? Record any intended difference.
10. The handoff is honest
"Done" should mean checked, not compiled. Untested states are fine to have; hidden ones aren't.
Test: List what was actually checked (widths, states, keyboard) and what wasn't. Every failure above is either fixed and rechecked, or written down.
Let your agent run it
Coding agents that can run and look at your app can do most of this themselves, and they're good at the mechanical checks: every width, every state, every label. Ask for evidence, not a verdict: the width it used, the state it triggered, what it saw. A report full of "looks good" hasn't checked anything.
Keep two checks for yourself: whether the main task really is the easiest thing to do, and whether the screen belongs to your product. Both depend on knowing your users and your product.
A prompt you can use
Paste this after your agent finishes a UI task. It asks for the same 10 checks, with evidence:
Review the screen you just built against its main task. Don't give it a score; report what you observed. Run it, then for each check below report PASS, FAIL or NOT CHECKED with one line of evidence (the width, state or action you tried): 1. The main task is the easiest thing to do: Give the screen to someone (or yourself, fresh) with only the goal. Can they start it within five seconds, without scrolling or opening a menu? 2. Labels say what things are, in the product's words: Read every heading, button and label out loud. Replace anything generic with the real name of the thing or action. 3. Nothing relies on color alone: Look at the screen in grayscale (or squint). Can you still tell late from on time, error from success? 4. Every state is designed: Trigger each: no data, slow loading, a failed request, a very long name, 100+ items. Each should look intentional and say what to do next. 5. People can recover without losing work: Fill in a form or set filters, then make the request fail. Is everything still there, with a clear way to try again? 6. It works on a phone-sized screen: Check at 390px wide. The main action is visible, nothing scrolls sideways, and tap targets are at least 44px. 7. It works with a keyboard and a screen reader: Use Tab only: reach every control, see where focus is, open and close any dialog. Inputs have labels and errors are announced. 8. Text is readable: Body text contrast is at least 4.5:1 (large text 3:1). Check text on images and on colored buttons too, and at 200% zoom. 9. It belongs to this product: Put it next to another screen of the product at the same width. Same buttons, spacing, type and words for the same things? Record any intended difference. 10. The handoff is honest: List what was actually checked (widths, states, keyboard) and what wasn't. Every failure above is either fixed and rechecked, or written down. Fix every FAIL that's within this task, re-run those checks, and list anything you couldn't check and why.
Questions
Why pass/fail instead of a score out of 10?
A score hides what's wrong. "7/10" doesn't tell anyone what to fix; "Fail: the error clears the form" does. Each check here has a test with a result you can see.
Is "Not checked" a failure?
No. It's honest. Some checks need a device, a screen reader or real data you don't have yet. Mark it, say why in the note, and it stays visible in the report instead of being quietly skipped.
Can my coding agent run this checklist itself?
Mostly. Agents that can run and view the app can check widths, states, labels and keyboard paths. Copy the prompt at the end of this page. Always look at the result yourself for the checks that depend on judgment, like whether it fits your product.
Does this checklist save my answers?
No. It runs in your browser only; nothing is stored or sent. Use Copy report to keep a record, and paste it into your pull request or back to your agent.
Sources and review
Checked against UXKIN's live tools on September 29, 2026. Client apps change their settings screens over time; follow your client's own documentation for the exact steps.
Put it to work
The no-ui-slop skill makes your agent run these checks as part of the work, and UXKIN's references help when a check fails and you're not sure what good looks like. Browsing the library is free.