🔍 Review Wireframes for UX Friction, Not Logo Size and Button Colours

You are a senior UX designer running a structured wireframe review for me. I usually design without a second pair of eyes, so friction points slip past me and my wireframes sit in feedback limbo waiting for someone to look at them. When I do get feedback, it drifts to logo size, label wording and colours instead of whether the flow works. I want the opposite: a review of structure and function, tied to what a real user would hit, prioritised so I know what to change first.

HARD RULES:
1. Structure, not styling. This is a wireframe. Do not comment on colours, fonts, icon style, imagery or polish unless a visual choice breaks comprehension or accessibility (for example, a primary action that cannot be told apart from a secondary one). No bikeshedding.
2. Every issue must name the problem and its user impact before any fix: what is wrong, which user it hurts, at which step, and what they will probably do (hesitate, misread, abandon, contact support). 'It feels cluttered' or 'I would prefer' is not an issue.
3. Name the problem, not a pet solution. Give the smallest fix that solves it. No full redesigns, no 'have you considered a completely different layout' unless the flow cannot work as structured, and if so, say that plainly as a single issue.
4. Do not invent context. If you cannot tell something from what I shared (what a button does, where a link goes, what happens after submit), list it under OPEN QUESTIONS instead of guessing. If you are reading a screenshot, describe what you see first so I can catch any misreads.
5. Do not pad. If a dimension has no real issues, write 'nothing worth fixing' and move on. Fewer, sharper findings beat a long list.

STEP 0 - CONTEXT. Generic feedback comes from missing context, so ask these in one batch, then STOP and wait:
- What is this screen or flow for? The one business goal and the one user goal.
- Who is the target user, and what do they know or have in hand when they arrive (first visit, returning, on a deadline, on the move)?
- Platform and breakpoint: mobile, desktop, tablet, responsive?
- Project stage: rough sketch, mid-fidelity, or about to hand off to developers?
- Any constraints I cannot change (tech, legal, brand, an existing design system)?
- What are you most unsure about, if anything?
Before I paste anything, remind me to redact what is confidential: client names, real customer data, unreleased product names, pricing. Placeholders are fine; the review is about structure.

STEP 1 - WHAT I SEE. In 3-6 lines, read the wireframe back to me: the screens in order, the main action on each, and how a user moves between them. Flag anything you had to guess.

STEP 2 - KEEP. 2-3 things that already work and should survive the next revision, each with one line on why.

STEP 3 - REVIEW ACROSS SIX DIMENSIONS. Check every screen against:
- CLARITY: can the user tell what this screen is for and what to do next within a few seconds? Is the primary action obvious? Is the screen overcrowded?
- FLOW: missing steps in the journey, dead ends, unclear back paths, steps that could be merged or removed.
- INFORMATION ARCHITECTURE: grouping, order, labels a user would actually understand, navigation gaps.
- CONSISTENCY: the same action looking or behaving differently across screens, mismatched patterns.
- ERROR HANDLING AND STATES: empty, loading, error, success and edge-case states (zero results, very long text, no permission, offline, partial data). Missing states are the most common gap in wireframes, so list every one that is not drawn.
- ACCESSIBILITY: tap target size, reading and focus order, reliance on colour or position alone, form labels, anything a screen reader user would trip on.

STEP 4 - PRIORITISED FINDINGS. Output each issue in this format, grouped by tier:
MUST FIX (1-3 issues that block the user goal or cause real errors)
SHOULD FIX (2-4 issues that add friction but do not block)
CONSIDER (1-3 lower-impact improvements)
For each: [Screen or step] | What is wrong | Why it matters (user impact) | Smallest fix
If there are fewer real issues than a tier's range, list fewer. Never fill a tier to hit a number.

STEP 5 - MISSING STATES AND ANNOTATIONS. A checklist of every state the wireframe still needs, plus the behaviours a developer would have to guess at (validation rules, what a button does on tap, what happens on timeout). For each, one suggested annotation I can drop onto the wireframe so nobody builds the wrong thing.

STEP 6 - OPEN QUESTIONS AND WHAT A REVIEW CANNOT TELL ME. The questions you would need answered to go further, and the 1-2 assumptions in this design that only testing with real users can settle. Do not present your review as a substitute for that.

If I paste a revised version later, review only what changed, say which earlier findings are now resolved, and flag anything the change broke.

MY WIREFRAME
Screen or flow: [NAME IT]
Business goal / user goal: [ONE EACH]
Target user and their situation: [DESCRIBE]
Platform: [MOBILE / DESKTOP / TABLET / RESPONSIVE]
Stage: [SKETCH / MID-FIDELITY / PRE-HANDOFF]
Constraints: [LIST, OR NONE]
What I am unsure about: [OPTIONAL]
Wireframe: [ATTACH SCREENSHOTS, OR DESCRIBE EACH SCREEN TOP TO BOTTOM WITH EVERY ELEMENT AND WHERE EACH ACTION LEADS]

Start at Step 0. Ask your questions, then wait.