Print the steps mentally, then use the terms as labels for what you’re seeing.
Open the page in Firefox (or whatever you use) and walk through the steps top to bottom. You’ll end up with clearer feedback than “it feels off.”
Before you start, pick one target: one screen or one task (like “change password” or “check out”).
Step 1: Intent and job-to-be-done (What is this for?)
If you can’t say what the screen is trying to help someone do, every other UX decision becomes guesswork.
Job-to-be-done (JTBD): The practical thing a person is hiring this screen to accomplish. Example: “Pay an invoice,” not “use billing.”
User intent: What the person believes they can do here, based on what they see first.
Success criteria: What “done” looks like in observable terms (confirmation message, email receipt, updated status).
- Quick check: In 5 seconds, can you tell what the primary action is?
- Quick check: Is there one clear “main thing,” or three competing ones?
- Quick check: If this screen disappeared, what user problem would return?
Step 2: Entry points, context, and mental model (Where did I come from?)
People don’t arrive as blank slates. They arrive from somewhere, with a guess about what happens next.
Entry point: How someone gets here (email link, settings menu, search result, in-app banner). Different entry points imply different expectations.
Context: The surrounding cues that explain what’s going on (page title, account name, breadcrumbs, selected plan, current step).
Mental model: The user’s internal story of how the system works, often borrowed from other products (“This should behave like a form,” “This is a folder,” “This is a cart”).
- Quick check: If you deep-link to this page, does it still make sense?
- Quick check: Are you forcing a new mental model without teaching it?
Single-sentence test: “A first-time user would describe this page as _____.”
Step 3: Information architecture and hierarchy (What do I notice first?)
This is about how the page “talks” without words: what stands out, what groups together, what looks secondary.
Information architecture (IA): How content and actions are organized across screens and within a screen.
Visual hierarchy: The order your eyes naturally follow (size, contrast, spacing, placement).
Progressive disclosure: Showing only what’s needed now, with details available when requested (expanders, “Advanced,” tooltips).
Scanning behavior: Most people scan for headings, keywords, and buttons rather than reading line-by-line.
- Quick check: Is the primary action visually strongest (not just present)?
- Quick check: Do related items look related (and unrelated items look separate)?
- Quick check: Are “advanced” options stealing attention from the main task?
Step 4: Affordances, signifiers, and interaction costs (What looks clickable?)
A lot of usability issues are just mismatches between what looks interactive and what actually is.
Affordance: What an element suggests you can do with it (a slider suggests dragging).
Signifier: The cue that makes the affordance obvious (a handle on the slider, an underline on a link).
Discoverability: How easily someone can find a feature without being told.
Interaction cost: The effort to complete an action (clicks, typing, switching context, thinking). Lower is not always better, but hidden cost is always worse.
- Quick check: Do links look like links and buttons look like buttons?
- Quick check: Are there “mystery meat” icons with no labels?
- Quick check: Is there an avoidable typing step (copy/paste codes, re-enter email, repeated address)?
In Firefox, try keyboard-only for 60 seconds (Tab, Shift+Tab, Enter, Esc). The gaps usually show up fast.
Step 5: Feedback, system status, and error recovery (Did it work?)
People trust a system that explains itself while it’s working and when it fails.
System status: Clear indication of what’s happening now (loading, saving, syncing, queued).
Feedback: The response to an action (button state changes, inline success message, toast, updated list item).
Error prevention: Designing so errors are hard to make (disabled impossible options, sensible defaults, confirmation for destructive actions).
Error recovery: Getting back to a good state after failure (retry, undo, keep entered data, clear next step).
- Quick check: After you click the primary action, is there a clear “something is happening” signal?
- Quick check: If you submit invalid input, does the message explain how to fix it (not just what’s wrong)?
- Quick check: If something fails, can you recover without starting over?
Step 6: Accessibility and inclusivity basics (Can different people use it?)
This step keeps you honest: a design isn’t “clean” if it’s only usable in ideal conditions.
Contrast: Text and UI elements need enough contrast to be readable in varied lighting and by people with low vision.
Focus state: Visible indication of where the keyboard is currently focused.
Hit target: Interactive elements should be large enough to tap/click reliably.
Plain language: Clear, concrete wording that avoids jargon when a user is trying to complete a task.
- Quick check: Can you navigate every interactive element with keyboard focus visible?
- Quick check: Are error messages announced clearly and placed near the field?
- Quick check: Would this still work on a small screen, with zoom at 200%?
Even if you’re not running a full audit, these quick checks catch the most common “looks fine to me” traps.
Step 7: Friction, cognitive load, and “why people bounce” (What feels heavy?)
When someone says “This flow has friction,” they usually mean one of a few specific kinds.
Friction: Anything that slows, confuses, or annoys someone on the way to their goal.
Cognitive load: How much thinking the screen requires at once (choices, unfamiliar terms, multi-step reasoning).
Decision fatigue: Too many similar decisions (multiple plan comparisons, optional add-ons, repeated confirmations).
Trust signals: Cues that reduce doubt (clear totals, recognizable payment steps, transparent permissions, predictable navigation).
- Quick check: Are you asking for information before the user understands why it’s needed?
- Quick check: Are there choices that could be defaults (with an easy change)?
- Quick check: Are you introducing anxiety (pricing surprises, vague permissions, unclear consequences)?
Translate “friction” into a sentence: “The friction is caused by _____, which adds _____ extra steps / decisions.”
Takeaway: The reusable workflow in one line
Review any UX surface in this order: intent → context → hierarchy → affordances → feedback → accessibility → friction.
When your notes use these terms, they stop being vibes and start being fixable.