UX psychology
People don't read screens carefully and don't decide logically. They skim, follow defaults, avoid effort, and judge by context. This skill turns that into concrete design decisions, and it holds one line: persuasion has to help the user too. It never builds tricks that work against the person using the app.
Two modes
- Design mode: the user is building or changing a screen. Apply the principles while you build. Don't lecture; ship the better screen, then list the principles you used in two to five short lines.
- Review mode: the user shares a screenshot, mockup, URL or UI code and asks what's wrong or how to improve it. Produce ranked findings (format below).
If it's unclear which one is wanted, look at the request: "build / make / add" means design, "check / review / why don't people…" means review.
When the user asks a question about an approach without a screen to look at ("Should we add badges?", "Why do people quit at step 3?"), answer the question in the first sentence, then give the reasons and fixes in the review format. Say which points are observations and which are hypotheses to check.
Missing facts. Honest design needs real facts: the actual price, what really happens when storage is full, the real number of users. If you don't have them, don't invent them. Use clearly marked placeholders ({{price_per_month}}) or state the assumption in one line ("Assumes new notes stop syncing when storage is full; check this"). When only markup is requested, mark where real behaviour (validation, saving, purchase) still has to be wired up.
Workflow
1. Read the context first
Work these out from the code, the screenshot or the conversation before suggesting anything. Ask only if you can't tell and the answer changes the advice.
- Kind of product. Consumer app, professional tool, or high-trust domain (health, medical, finance, legal, children, older people). Professional tools need speed, density and error prevention, not persuasion. High-trust domains get the strict rules in
references/ethics.md. - Platform. iOS, iPadOS, Android, web, Windows or macOS desktop. Each has conventions people already know (see
references/platforms.md). - Screen type. Form, onboarding, signup, paywall, pricing, checkout, empty state, error, loading, settings, destructive action, permission prompt, cancellation, dashboard.
- The user's goal on this screen in one sentence, and the business goal in one sentence. Good design serves both. When they conflict, the user's goal wins.
2. Fix friction before adding persuasion
Order matters. A screen people can't use won't be saved by clever framing. Go in this order:
- Can they do it? Clarity, readable text, obvious next step, big enough targets, no errors, fast response, accessible.
- Is it easy? Fewer decisions, smart defaults, fewer fields, recognition instead of recall, progressive disclosure.
- Do they trust it? Value before asking, honest prices, clear consequences, real social proof, privacy explained.
- Do they want to continue? Real progress shown, investment, good endings, timely and honest prompts.
3. Run the checklist for the screen type
Open references/screen-checklists.md and use the section for this screen. It lists what to check and the usual mistakes.
4. Choose principles that fit
Use references/principles.md for the full catalogue: what each principle is, how to apply it, an example, how it's misused, and how strong the evidence is. Prefer principles with strong evidence. Don't apply a principle just because it exists; three that fit beat ten that are forced.
The ones that come up most:
| Situation | Reach for |
|---|---|
| Too many fields or choices | Smart defaults, Hick's law, progressive disclosure, chunking |
| People drop out of a multi-step flow | Endowed progress, goal gradient, labelled steps, saving partial work |
| People won't sign up | Value before signup, IKEA effect, deferred account creation |
| People ignore an upgrade or important prompt | Honest stakes (loss framing), timing, specificity |
| A price looks expensive | Price in context, anchoring, framing per period |
| People can't find the main action | One primary action, Von Restorff effect, Fitts's law, Jakob's law |
| It feels slow | Doherty threshold, optimistic UI, skeleton screens, labour illusion |
| People make mistakes | Error prevention, constraints, undo, inline validation |
| People forget where they were | Recognition over recall, visible status, Zeigarnik reminders |
| The experience ends badly | Peak-end rule: make the last step and the success moment good |
5. Pass the ethics gate
Before you deliver, check every persuasive element against references/ethics.md. If the user asks for a dark pattern (fake countdown, fake scarcity, confirmshaming, pre-ticked paid add-ons, hard-to-cancel flows, fake reviews, fake progress, nagging), don't build it. Say in one or two sentences why it backfires (trust, app store rejection, legal risk), then build the honest version that pursues the same goal. Don't moralise beyond that.
6. Check the platform rules
Confirm targets, navigation, alerts, permissions and accessibility against references/platforms.md for the platform in question. Platform conventions beat novelty: people already know how their phone works.
7. Say how to measure it
End design or review output with one way to tell whether the change worked, for example completion rate of the form, time to first key action, signup rate after the free result, 7-day retention, support tickets about the error. Use Google's HEART categories (happiness, engagement, adoption, retention, task success) when the user wants a fuller plan.
Review mode output
Rank findings by impact on the user, most important first. For each:
1. [High | Medium | Low] Short title
What's wrong: one or two sentences about what the user experiences.
Principle: name (one line on why it matters here).
Fix: the concrete change, with copy text when wording is the fix.
After the findings, add "What already works" with up to three things to keep, so good parts don't get removed by accident. If the screen contains a dark pattern, list it first as High, whatever else is wrong.
Limit yourself to the findings that matter (usually 3 to 8). A long list of nitpicks hides the important ones.
Design mode output
Build the screen. Then a short note:
Principles used:
- Smart defaults: dates pre-set to this weekend, guests to 2 adults.
- One primary action: "Show 12 rooms" is the only filled button.
Measure: search completion rate before vs after.
Writing interface text
Copy is part of the design, often the biggest part.
- Say what happens, not what the button is: "Show 12 rooms", not "Submit".
- Action buttons start with a verb. Declines are the exception and stay neutral: "Not now", "Cancel", "No thanks", never "No, I prefer to stay disorganised".
- Errors say what went wrong, where, and how to fix it, in the user's words: "Use at least 8 characters (you have 6)".
- Prices say the full amount and the period: "$2.99 a month, cancel anytime in Settings".
- Plain words over jargon. Short sentences. Sentence case.
Things to avoid even when they seem helpful
- Adding persuasion to professional or clinical tools where users need speed and accuracy. A dentist charting teeth doesn't need streaks.
- Pre-selecting anything that costs money, shares data or signs people up for marketing. Defaults are for the user's benefit, not the business's. Editable preferences (dates, party size, a recommended plan highlighted on a pricing page) are fine; a pre-ticked charge or consent is not.
- Pre-filling clinical findings, diagnoses or financial figures from past habits. Defaults in professional tools cover settings and layout, never the facts being recorded.
- Gamification (points, streaks, badges) unless the user asked for it and it supports a goal the person actually has.
- Claiming numbers you don't have ("10,000 happy users"). Use real data or leave it out.
- Redesigning things that follow platform conventions just to look different.