UI/UX Design: UX Writing, Forms and Conversion, Research, Ethics, and AI-Era Interfaces¶

Part 4 of 5 of the UI/UX Design Principles — Mobile, Tablet, Web, Desktop reference (plugin ui-ux-design-principles), covering §10–§14. Sibling skills: ui-ux-cognition-heuristics-and-navigation (§0–§3), ui-ux-interaction-layout-and-visual-design (§4–§6), ui-ux-design-systems-platforms-and-accessibility (§7–§9), ui-ux-reference (§15–§20). Section numbers are shared across the set; a reference written as §N → skill points into that sibling skill.

Currency: Verified August 2026. See §17 → ui-ux-reference for the currency snapshot and what goes stale first.

Related: Overlaps the frontend-design:graphic-ux-ui-design skill. That one is oriented to implementation-time component and token decisions; this one is oriented to design reasoning, cross-form-factor principles, research method, and the regulatory landscape. Use both.

How to read this. Reference, not tutorial. Sections are independent. Three markers: - [DURABLE] — grounded in perception, cognition, motor control, or decades of replicated research. Does not expire. Trust it. - [PLATFORM] — a convention of Apple, Google, Microsoft, GNOME/KDE, or the web. Verify against the current HIG; these change. - [CONTESTED] — competent practitioners disagree, or the evidence is thinner than the confidence with which it's usually asserted. Both cases given.

⚠️ GOTCHA boxes mark the mistakes that survive design review and get caught in production, in court, or in the analytics.

The framing that organizes everything below: an interface is a proposal about how a person should think. Good design makes the proposal match how they already think. Every principle in this document is a specialization of that idea — to a thumb, a screen size, a screen reader, a legal regime, or an attention budget.

§10. Content and UX Writing¶

[DURABLE] The interface is mostly words. Most "confusing UI" is confusing language wearing a layout.

10.1 Principles¶

Clarity beats cleverness. Always. Nobody has ever been delighted by a witty error message they couldn't act on.
Front-load the meaningful words. Users scan the first two words of a link, heading, or bullet. "Download the annual report (PDF)" not "Click here to download…"
Use the user's vocabulary, sourced from research, support tickets, and search logs — not the database schema and not marketing.
Be consistent. One concept, one word, everywhere. If it's a "workspace" in nav it's not a "team" in settings.
Active voice, present tense, second person. "Your changes are saved" not "Changes have been saved by the system."
Sentence case for UI labels reads faster than Title Case and is the modern convention on every major platform.
Numbers, dates, and units are localized. 1,234.56 vs 1.234,56 is a real bug.

10.2 The high-value surfaces¶

Buttons — a verb naming the outcome. "Save changes", "Create account", "Delete project". Never "OK", "Submit", "Yes/No" for consequential choices. The button label must match the heading that preceded it.

Error messages — three parts, in this order: 1. What happened, plainly. ("We couldn't process your payment.") 2. Why, if you know and it's actionable. ("Your card was declined by your bank.") 3. What to do next. ("Try another card, or contact your bank.") Never blame the user, never expose a stack trace or code as the only content (a support reference code in addition is fine and useful), never say "invalid input" without saying which input and what would be valid.

Empty states — the most under-designed screen in most products, and a first-run user's first impression. It should: explain what belongs here, why it's empty, and give one clear action to fill it. Distinguish first-use empty (teach), user-cleared empty (celebrate or reassure), no-results empty (offer alternatives and a way to broaden), and error empty (diagnose).

Loading and progress — say what's loading. "Loading your invoices" beats a spinner.

Confirmation and success — name what happened and offer the next step. This is the "end" in peak-end (§1.4 → ui-ux-cognition-heuristics-and-navigation) and it's cheap to do well.

Microcopy on inputs — a persistent hint below the field (not a placeholder) explaining format requirements before the user fails, not after.

10.3 Localization affects design, not just strings¶

Text expansion: German/Finnish run 30–40% longer than English; some languages 100%+ for short strings. Fixed-width buttons break. Design for expansion or use flexible layouts and test with pseudo-localization.
RTL (Arabic, Hebrew, Farsi) mirrors the entire layout — navigation, icons with directionality (back arrows, progress), and reading order. Use logical properties (margin-inline-start, not margin-left) and test with a force-RTL flag.
Never concatenate translated fragments. Word order differs; use positional format strings.
Plurals need real plural rules (Arabic has six categories), not if (n === 1).
CJK has different line-breaking, no spaces between words, and different comfortable line-heights; ideographs need more vertical space.
Names, addresses, phone formats, honorifics, and date orders are not universal. A required "First name / Last name" split is wrong for a large fraction of the world.

§11. Forms, Onboarding, and Conversion¶

11.1 Form design — where usability turns directly into money¶

[DURABLE] Every field you remove increases completion. Ask only for what you need now.

Rule	Why
One column.	Multi-column forms cause skipped fields and ambiguous tab order. Exception: genuinely paired short fields (city/state, expiry month/year).
Labels above fields, always visible.	Fastest to scan; survives zoom; works with autofill; placeholder-as-label is a documented failure.
Group related fields with clear spacing (§1.3 → `ui-ux-cognition-heuristics-and-navigation`).	Proximity does the work.
*Inline validation after* the field loses focus**, not on every keystroke.	Validating while typing tells users they're wrong before they've finished being right.
Show requirements up front (password rules, format).	Error prevention > error handling (Nielsen #5).
Correct `autocomplete` attributes and `inputmode`.	Autofill is a huge completion win and an accessibility feature. `inputmode="numeric"` gives the right mobile keyboard.
Never mask what the user typed (except passwords, and offer a reveal).	Card numbers, codes, and emails all benefit from being visible for checking.
Mark optional fields, not required ones — if most are required.	Fewer asterisks, less noise.
Error summary at the top + inline errors + focus the first error.	Screen-reader users and zoomed users can't see an error 2000 px down.
Preserve entered data on error.	Losing a filled form is the fastest way to lose a user.

11.2 The checkout/conversion evidence¶

Baymard Institute's long-running large-scale checkout usability research is the most-cited data set here. Key figures, with the caveats they deserve: - ~70.2% average cart abandonment, from a meta-analysis of ~50 studies (last updated Sept 2025). This has been structurally stable for a decade, moving under a percentage point in five years. - Baymard estimates the average large e-commerce site could gain ~35.26% conversion from checkout-design improvements alone — framed by them as an upper bound from a decade of documented, solvable issues, not a guaranteed return, and explicitly excluding the large share of abandonment that is pure browsing intent. - Extra costs at checkout (shipping, fees, tax) are consistently the top abandonment reason (~39%); forced account creation ~24%; too long/complicated a checkout ~19%; not trusting the site with card details ~19%. - The average checkout shows ~23.5 form elements / ~14.9 fields, versus an achievable 12–14; most sites can cut 20–60% of elements.

⚠️ Cite these carefully. They are aggregates across many studies and verticals, mostly from one (excellent, commercial) research organization; live-behaviour trackers report higher numbers (Dynamic Yield ~77.8% on a rolling 12-month basis) because they measure something slightly different. Use them to prioritize, not as targets your specific site will hit.

The practical hierarchy: show total cost early → offer guest checkout → cut fields → one obvious next step per screen → visible trust signals near the payment field → support the payment methods your market actually uses.

11.3 Onboarding¶

Show value before you ask for commitment. Delay signup, delay permissions, delay the tour. Permission requests should be contextual ("Allow notifications so we can alert you when your order ships") and at the moment of need, not at first launch — a cold-start permission prompt is the most reliable way to get a permanent denial.
Progressive onboarding beats a carousel. Teach the feature when it's first relevant. Multi-screen intro carousels are almost universally skipped.
Reduce time-to-first-value relentlessly. Sample data, templates, and sensible defaults beat an empty state plus a tutorial.
Let users skip, and let them return. A tour you can't exit is a hostage situation.

§12. Research and Evaluation¶

12.1 Choosing a method¶

Question	Method
Can people do the task?	Usability test (moderated or unmoderated)
Why do they behave that way?	Interviews, contextual inquiry, diary study
What do they do at scale?	Analytics, funnels, session replay
Which version performs better?	A/B test
How do they think about the domain?	Card sort, tree test, mental-model interview
Can they find it?	Tree test (IA without UI) / first-click test
Is it accessible?	Expert audit + AT testing + testing with disabled users (§9.5 → `ui-ux-design-systems-platforms-and-accessibility`)
How do they feel over time?	Longitudinal survey (SUS/UMUX-Lite/NPS), diary
Does it violate known principles?	Heuristic evaluation (§2.1 → `ui-ux-cognition-heuristics-and-navigation`) — cheap, fast, and finds different issues than testing

[DURABLE] Attitudinal ≠ behavioural. What people say they'd do is a poor predictor of what they do. Never ship a feature on survey preference alone.

12.2 Sample sizes — the number everyone quotes and misuses¶

Nielsen & Landauer's "5 users find ~85% of usability problems" is the most cited and most abused finding in UX. What it actually says: with a problem-detection probability of ~31% per user per problem, five users find about 85% of problems in a single homogeneous user group performing similar tasks. What it does not say: - It doesn't apply across distinct user segments — each segment needs its own ~5. - It doesn't apply to quantitative measures (task time, success rate, satisfaction). Those need 20+ per condition for anything resembling a confidence interval. - It doesn't mean five is enough; it means five is the point of diminishing returns for one round, and three rounds of five beats one round of fifteen because you fix things between rounds. - The 31% detection rate itself varies with task and interface complexity.

Rough guide: qualitative usability 5–8 per segment per round; card sort 15–30; tree test 30–50; quantitative benchmark 20+ per condition; A/B test — whatever your power analysis says, calculated before you start.

12.3 Running a usability test that produces truth¶

Give tasks, not instructions. "Find out how much it would cost to ship two of these to Berlin" — not "click the shipping calculator."
Don't lead. When they ask "should I click here?", answer "what would you do if I weren't here?"
Silence is data. Let them struggle for a bit; the struggle is the finding.
Watch behaviour, weight it above commentary. Users are unreliable narrators of their own difficulty and are systematically polite about your work.
Recruit for the actual user, not for whoever's convenient. Testing an enterprise tool on your friends produces confident nonsense.
Separate observation from interpretation in your notes. "Clicked Back three times" is an observation; "was confused by the nav" is a hypothesis.
⚠️ Beware of testing only success paths. Most real-world pain is in errors, edge cases, recovery, and the second session — not the happy path you designed the prototype for.

12.4 Metrics¶

HEART (Google) — pick per-project, and pair each with a Goal → Signal → Metric: Happiness, Engagement, Adoption, Retention, Task success.

Complementary standards: - SUS (System Usability Scale) — 10 items, 0–100; ~68 is average, 80+ is good. Comparable across products and time, which is its real value. - SEQ (Single Ease Question) — one 7-point question after each task. Startlingly informative for its cost. - Task success rate, time on task, error rate — the core behavioural triad. - Core Web Vitals (§6.6 → ui-ux-interaction-layout-and-visual-design) for web performance.

⚠️ Choose metrics that can go down when you make things worse. Engagement metrics are notorious for rewarding dark patterns: time-on-site rises when users are confused, and session count rises when notifications are manipulative. Pair every engagement metric with a quality metric (task success, retention, complaint rate, unsubscribe rate).

§13. Ethics, Persuasion, and Dark Patterns¶

13.1 The line¶

[DURABLE] The test is whose interest the design decision serves when the user's and the business's diverge. Persuasion that helps a user do what they already wanted is design. Design that exploits a cognitive bias to produce a choice the user would not otherwise make is a dark pattern — and increasingly, a legal violation.

13.2 The catalogue¶

Pattern	Mechanism	Regulatory exposure
Roach motel (easy in, hard out)	Asymmetric effort	FTC: Epic $245M; Amazon $2.5B settlement (which surfaced internal emails on deliberately confusing cancellation)
Sneak into basket / drip pricing	Late disclosure	UCPD, FTC
Confirmshaming ("No thanks, I hate saving money")	Social/emotional pressure	DFA target
Preselected options / pre-ticked boxes	Default exploitation	GDPR consent invalidity
Asymmetric consent (bright "Accept all", buried "Reject")	Choice architecture	CNIL fined Google €150M and Microsoft €60M on exactly this; TikTok €345M (Irish DPC) for public-by-default; Amazon €746M
False urgency / fake scarcity ("1 room left!")	Manufactured pressure	UCPD; DFA named target
Disguised ads	Misrepresentation	FTC endorsement rules
Nagging	Repetition until compliance
Obstruction / privacy zuckering	Friction as a weapon	CPRA: "dark patterns are about effect, not intent"
Infinite scroll + autoplay + variable rewards	Attention capture	DFA "addictive design" target

13.3 The regulatory picture (2026)¶

EU DSA Article 25 already prohibits online-platform interfaces that "deceive, manipulate or otherwise materially distort" users' ability to make free and informed decisions. DMA carries fines up to 6% of global revenue for consent manipulation.
EDPB Guidelines 03/2022 define six GDPR dark-pattern categories: overloading, skipping, stirring, obstructing, fickle, left in the dark. Useful as a design checklist, not just a legal one.
Consumer Rights Directive amendments ban dark patterns in distance financial-services interfaces — transposed by 19 December 2025, applicable from 19 June 2026.
EU Digital Fairness Act — confirmed in the Commission's 2030 Consumer Agenda (adopted 19 November 2025); proposal expected late 2026, targeting dark patterns, addictive design, influencer marketing, and personalization. Adoption realistically 2027+, entry into force 2028–2030. Not law yet — do not describe it as such.
US FTC is actively enforcing under Section 5, including naming individual executives as defendants. Its 2024 study of 642 sites/apps found 76% used at least one possible deceptive pattern and ~67% used multiple. The Commission's 2022 EU study found 97% of the most popular EU-used sites and apps deployed at least one.
California CPRA treats dark patterns as consent-invalidating, with the CPPA's standard being symmetry: the privacy-protective option must be as easy as the less protective one.

13.4 The design checklist¶

[ ] Cancelling is as easy as subscribing (same channel, same number of steps).
[ ] The privacy-protective choice is as prominent and as few clicks as the permissive one.
[ ] No pre-ticked consent boxes; consent is a positive, unambiguous act.
[ ] Total price, including all fees, disclosed before the user invests effort.
[ ] Urgency and scarcity claims are literally true and verifiable.
[ ] Decline options are neutrally worded — no shaming.
[ ] Defaults chosen for the user's benefit, and you can say why.
[ ] Ads and sponsored content are unmistakably labeled.
[ ] Consent flows are documented and evidenced.
[ ] No design element manipulates children or exploits known vulnerabilities.

[UNIVERSAL] "It wasn't intentional" is not a defense — the CPPA's stated position is that dark patterns are about effect, not intent. An A/B test that increased conversion by making the reject button harder to find has produced a violation regardless of what anyone meant.

§14. AI-Era Interfaces¶

14.1 What actually changed¶

[CONTESTED, and the most overclaimed area in the field.] Two framings: - NN/g's line (Nielsen, 2023): generative AI is the first new UI paradigm in 60 years — intent-based outcome specification rather than command specification. NN/g's State of UX 2026 extends this: UI is becoming less of a differentiator, AI-mediated interaction sits on top of the interface, and equating UX with UI increasingly misdescribes the work. - The skeptical line: chat is a regression in discoverability, learnability, and efficiency for most tasks; it externalizes the interface designer's job onto the user, who must now guess what the system can do. A blank text box has zero affordances.

The synthesis practitioners actually ship: a hybrid — conversational or intent-based entry, traditional UI for execution and refinement. The rule of thumb that circulates and holds up well: if the user can describe the task in one sentence, conversational works; if the task requires manipulation, comparison, precision, or spatial reasoning, give them a UI.

14.2 Design principles for AI features¶

Set expectations before the first interaction. What can this do? What can't it? What data does it see? Blank-box interfaces produce both over- and under-estimation.
Make capability discoverable — suggested prompts, examples, templates. This is the direct replacement for menus and buttons as an affordance mechanism.
Show provenance and uncertainty. Citations, sources, confidence signals. Users calibrate trust from these; without them they either over-trust or reject wholesale.
Keep the human in control: editable output, regenerate, undo, and a way to not use the AI path. Never make the AI the only route to a function.
Design for failure as a first-class state. Hallucination, refusal, timeout, irrelevance. These are not edge cases; they're the normal distribution's tail and users hit them constantly.
Make cost and latency legible. Streaming output is a UX decision (it converts a 10-second wait into a 300 ms first token, §6.6 → ui-ux-interaction-layout-and-visual-design). Token/credit consumption should be visible where it matters.
Feedback loops — thumbs, corrections, "not what I meant" — both for model improvement and because the ability to complain is itself a control affordance.
Privacy transparency — what's sent, what's retained, what trains. This is a design surface, not a legal footnote.

14.3 Generative UI, and its risk¶

"Generative UI" — interfaces assembled or adapted at runtime — is real and growing, and NN/g frames the shift as outcome-oriented design: designing adaptive frameworks that respond to individual goals rather than optimizing single interfaces for an average user.

Two documented risks worth holding onto: - Homogenization. AI generation draws on dominant patterns; one Adobe study reported >42% of AI-generated interfaces shared similar navigation structures and components. The floor rises; the ceiling doesn't. - Dark patterns at scale. An NN/g survey found 36% of designers fear AI will normalize dark patterns under the banner of UX optimization — because an optimizer pointed at conversion will find manipulation, and it will find it faster than a human. If you let a system optimize choice architecture, constrain it with the §13.4 checklist as hard constraints, not preferences.

Accessibility caution: AI-generated UI and AI-generated code produce plausible markup with unreliable semantics. Everything in §9 → ui-ux-design-systems-platforms-and-accessibility still has to be verified by a human. Figma's own framing of its AI outputs is that they still need human review for accessibility, semantics, and production readiness — take that at face value.

14.4 Tooling reality (2026)¶

Design tooling has moved fast: Figma's State of the Designer 2026 (survey of 906 designers) reports 72% now use generative AI in their workflows, with 98% having increased usage in the past year and 91% of those saying it improves output quality, not just speed. Figma's Config 2026 introduced code layers on the canvas, design agents, and an MCP server that lets AI agents operate on the file with real design-system context; Penpot (open-source, self-hostable, native DTCG tokens, CSS-native output) shipped an MCP server too and is the credible option for regulated or open-source-constrained teams.

The honest read: these tools compress production, not judgment. The bottleneck moved from making screens to knowing which screens to make — which is why the durable content in §1–§4 → ui-ux-cognition-heuristics-and-navigation, ui-ux-interaction-layout-and-visual-design and §12 is worth more now, not less.

Plugin: ui-ux-design-principles · View SKILL.md on GitHub