Key takeaways
- Never let AI choose the metric, ethical line, exclusions, brand voice, or user promise; you own them.
- These look safe to delegate, but the failure shows up later in who you attract, what you promise, and what you measure.
- Set the single event, metric, and flip threshold before prompting, then grade artifacts on whether they make tomorrow’s proof cheap.
- Write ethical red lines and language blocks, name a kill list and remove one item, and anchor voice with an objection–evidence near the primary action.
- Define the smallest guarantee and instrument slow, empty, and error states; enforce with pre-prompt proof and flagged changes read next day.
The real ai design limitations are not technical. A model will render anything you ask; what it cannot do is own the consequence. Five calls stay yours: which metric you optimize, where the ethical line sits, what you leave out, how the brand sounds, and what you promise the user. Delegate any of them and the bill arrives months later.
Why these five break quietly
These five feel safe to delegate because the surface still looks fine today. The failure shows up in who you attract, what you promise, and what you measure three quarters from now. A model executes; it does not decide why. Before you ship, audit the screen for the bet it refused to make and name the mechanism with the behavioural principles behind interface decisions.
Do not let AI choose the metric
Moment: before the first prompt or seed. Mechanism: the model optimizes for easy proxies like clicks, completions, or “looks consistent,” and those pull you off the outcome you must win. Check: you write the single event, the metric, and the flip threshold first, then ask whether the artifact makes the proof cheap to get tomorrow. If not, you are aiming nothing.
You set the metric and where it flips; the tool renders paths that make that threshold likely. The quick guardrail is the order in the product designer's AI workflow: constraint, decision, smallest proof, then artifact. Never accept “engagement” as the target. Name the behavior that matters, and the risk you refuse if it rises.
Do not let AI draw the ethical line
Moment: when persuasion, personalization, or data use appears. Mechanism: averages blur consent, bury warnings and normalize “just one more nudge,” turning short-term lift into long-term distrust. Check: you state red lines in writing — what you will not collect, not infer, not time — and mirror them as language blocks in the prompt.
Examples: no dark defaults, no pre-checked boxes, no silent personalization on identity or health, no manufactured urgency on a financial risk screen — real scarcity is a fact about supply, and inventing it is where the line gets crossed. The test that separates the two, claim by claim, is where persuasion ends and a dark pattern starts. Log every nudge and its opt-out rate. Leave the boundary unwritten and the model takes the option that hides its cost today.
Do not let AI decide what to exclude
Moment: at scope and layout. Mechanism: generators preserve structure and hedge, so extras survive by default and the real trade-off never lands. Check: name the kill list before render, then cut one field, one step or one message and watch whether risk rises. If risk stays flat and throughput climbs, the template was the lie.
This is the inverse test of “more is safer,” and it catches silent drag. Start with anything that demands data entry without lowering fraud or error. Remove it behind a flag and read next-day drop-off. If you cannot state the reduction a field earns, it is friction-by-accident.
Do not let AI set your brand voice
Moment: in claims, objections, and the commit point. Mechanism: polite, placeless copy sounds safe and converts nobody; “benefits” land without proof and your page could belong to any tool. Check: you write the one doubt a real user has and answer it at the moment it arises, using patterns like the calibrated testimonial to anchor the promise.
Voice is not tone; it is what you choose to say when the user is about to act. You pick the objection to pre-empt and the detail to reveal. The model can draft options; you choose the stake. If a paragraph could survive anywhere, it belongs nowhere. Your guardrail is an objection–evidence pair near the primary action, not adjectives.
Do not let AI set the user promise
Moment: the line that binds you to an outcome, explicit or implied. Mechanism: generated copy over-commits by accident (“instant,” “guaranteed”) or hedges so hard it erodes trust. Check: you define the smallest guarantee you will stand behind and the slow, empty, and error states that keep that promise under stress, then you instrument whether you kept it.
Promises are operational debt. A good one is specific, measurable and owned in the fallback. Name your minimums — response within X, delivery by Y, refund on Z — and what happens on the miss. Then read the failure paths: does progress survive, is recovery ranked, does the copy admit it? If not, you are shipping a leak you cannot talk your way out of.
Train the boundary
Your edge is not typing faster. It is naming why, where the line sits, and how you will check it. The model will keep getting better at execution; it will not carry your metric, your ethics, your exclusions, your voice or your promise. So write the constraint and the smallest proof before you prompt, and treat every gap as a flagged change with one event to log. Each mechanism you reach for carries its own ethical line, and they are trainable one at a time in the Quest skill library — starting with what to delegate and what to keep.
Act as a senior product designer coach enforcing AI design limitations. First, ask me concise questions to fill: [product], [target audience], [primary user outcome], [single success event], [flip threshold], [risky behavior to avoid], [ethical red lines: will not collect/infer/time], [fields/steps/messages to consider removing], [one real user objection], [evidence I can prove], [minimum guarantee], [slow/empty/error realities], [events we can log tomorrow]. After you have answers, produce a Boundary Memo for [describe the design decision], with sections: 1) Metric: event, metric, flip threshold, and why. 2) Ethical lines: “won’t” list plus exact prompt language blocks. 3) Exclusions: kill list, one removal test, and next-day reads (drop-off and bad-event). 4) Brand voice: one objection–evidence snippet placed at the primary action. 5) User promise: minimums, fallback behaviors for slow/empty/error, and instrumentation to track kept/missed promises. 6) Rollout ritual: pre-prompt checklist and flagged-change logging plan. Then output: a starter generation prompt that references this memo and refuses to proceed if any section is missing or vague.
Frequently asked questions
What is a flip threshold and when should I set it?
A flip threshold is the explicit boundary where your metric changes state from fail to pass (e.g., activation within 24 hours). Set it before the first prompt so every artifact aims at producing cheap proof tomorrow; see the guardrail order in the product designer's AI workflow.
What does a UX kill list include and how do I test exclusions?
A kill list names fields, steps, and messages you will cut to expose hidden drag. Remove one item behind a flag, then read next-day drop-off and bad-event rate; if risk stays flat and throughput climbs, the exclusion stands and the template was lying about “safety.”
How do I write ethical red lines into an AI prompt?
State non-negotiables as “won’t” rules and mirrored language blocks: won’t collect X, infer Y, or time Z; no dark defaults, no pre-checked boxes, no urgency copy on financial risk. Paste these verbatim into the prompt so the model cannot optimize past consent or bury warnings.
What is an objection–evidence pair and where does it go?
It is the one real doubt a user has plus a specific proof that answers it (e.g., calibrated testimonial with constraints). Place it beside the primary action, not in a features list; the calibrated testimonial and the behavioural principles behind interface decisions are where those patterns are written down.
How do I instrument a user promise and slow states?
Define minimums you will honor (response by X, delivery by Y, refund on Z), then log events for kept/missed promises and next-day reads. Specify slow, empty, and error behaviors that preserve progress and admit misses in copy; this turns a promise into operational checks you can enforce.
