Design a newsletter signup widget for a blog

## Role and objective

You are a UI designer creating a newsletter signup widget for a blog. Produce a Figma-ready component specification that another designer can build without guessing the hierarchy, layout behaviour, visual tokens, or interaction states. Design for blog readers who may encounter the widget in the placement specified by the user; if no placement is supplied, leave it as `[FILL IN: widget placement] — provide where the widget appears, such as sidebar, article end, header, or modal`. The deliverable is complete when it defines the widget’s structure, responsive behaviour, content slots, states, accessibility requirements, and design tokens in words, with no invented brand or product facts.

## Scope and given facts

In scope:

- A newsletter signup widget for a blog.
- A web interface component suitable for construction in Figma.
- Frame hierarchy and auto-layout rules stated in words.
- The reader’s input, submission, validation, loading, success, empty, and error experiences.
- Responsive and accessible behaviour.

Confirmed facts:

- The product context is a blog.
- The component’s purpose is newsletter signup.
- The target design engine is Figma.
- The user has not supplied a blog name, brand system, newsletter benefit, field list, legal copy, placement, viewport targets, or post-submission flow.

Out of scope:

- Designing the entire blog, article template, email newsletter, backend, subscription database, or campaign copy beyond the widget.
- Inventing a logo, colour palette, publication name, subscriber count, incentive, legal statement, or confirmation destination.

Use `[FILL IN: item]` for every unconfirmed value. For each slot, add one brief line explaining what information fills it. Do not fill `[FILL IN: blog name or brand description]` with a plausible publication name or fill `[FILL IN: newsletter value proposition]` with an invented benefit.

## Working rules

Use the `ui` modality. Preserve any fixed brand description supplied in the input; none is currently supplied, so use `[FILL IN: brandAnchor] — provide the exact brand wording or visual description to preserve`. Do not create an unsupported visual identity.

Judge the design against these criteria:

1. A reader can identify the newsletter offer, understand the required action, enter the required information, submit it, and understand the result.
2. The component remains usable when content wraps, the viewport narrows, validation text appears, or the form changes state.
3. Every state is represented: loading, empty, and error are mandatory; also include default, focused, validation-error, and success states when relevant to the signup flow.
4. Keyboard operation, visible focus, logical tab order, and screen-reader labels are explicit requirements, not implied behaviours.
5. Text, controls, and spacing remain legible at the supplied viewport sizes. If none are supplied, use `[FILL IN: target viewport sizes] — provide the desktop and mobile widths to test`.

If the user later supplies a fixed `brandAnchor`, repeat its wording exactly wherever the component specification refers to the brand. If no brand anchor is supplied, retain the slot rather than paraphrasing it. If the form fields are unspecified, use `[FILL IN: required fields] — provide each field name, required status, and input type`; do not assume email-only signup.

Apply WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs the audience, and leave the answer as `[FILL IN: governing accessibility regime] — identify whether ADA Title III, Section 508, both, or neither applies`. Require the layout to survive 200% zoom and a 320px viewport without horizontal scrolling. State date, number, currency, and address formats explicitly only if those fields are requested; otherwise do not add them. Do not silently assume that a US address format is appropriate.

## Output structure

Order the specification as follows:

1. **Screen list** — identify the widget as a component and list each required state: default, loading, empty, error, validation error, and success. Allocate a short description to each state and identify the transition that reaches it.
2. **Components per screen** — describe the frame hierarchy from outer component to inner frames, including heading, supporting text, form fields, consent or legal text if confirmed, submit control, feedback message, and any close or dismiss control only if the placement requires it.
3. **Auto-layout specification** — for every frame, state the direction, alignment, gap, padding, width and height behaviour, wrapping rule, and resizing behaviour in words. Explain which elements are fixed, hug contents, fill the container, or grow when validation text appears.
4. **Behaviour per state** — specify keyboard order, focus movement, validation timing, loading treatment, disabled conditions, success feedback, error recovery, and screen-reader announcements. Separate confirmed behaviour from `[FILL IN: submission and recovery behaviour] — provide the intended result after submit and after failure`.
5. **Design tokens** — provide slots or confirmed values for colour, type, spacing, corner radius, border, focus indicator, control height, and responsive breakpoints. Do not invent token values.
6. **Build notes** — state component variants, naming conventions, constraints, and the minimum content needed to test wrapping and error states.

Keep the design limited to the newsletter signup widget; do not supply a full blog page or implementation code.

## Style rules

Use a hybrid style. Use numbered lists and compact tables for screen states, component properties, tokens, and acceptance details. Use short narrative sentences for the design rationale, accessibility explanation, and responsive behaviour. Keep the register practical and designer-facing. Avoid generic conversion clichés such as “Join our community,” “Don’t miss out,” or “Unlock exclusive content” unless the user supplies that wording.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is a newsletter signup widget specification, not a full blog design, email campaign, backend plan, or code sample.
2. Confirm that the screen list includes loading, empty, and error states, plus the default and success states where the signup flow requires them.
3. Confirm that the component hierarchy names the widget’s actual frames and controls rather than using unexplained generic labels.
4. Confirm that every frame description states direction, alignment, spacing, padding, and resizing behaviour in words.
5. Confirm that keyboard operation, focus treatment, and screen-reader labels are explicitly covered.
6. Confirm that 200% zoom and a 320px viewport with no horizontal scrolling are addressed.
7. Check that no blog name, brand description, newsletter benefit, field list, legal text, breakpoint, colour, spacing value, or submission outcome was added beyond the input.
8. Check that `[FILL IN: blog name or brand description]`, `[FILL IN: newsletter value proposition]`, and `[FILL IN: required fields and submission behaviour]` remain unfilled unless the user supplied those facts.
9. Confirm that ADA Title III or Section 508 is left as `[FILL IN: governing accessibility regime]` rather than assumed.
10. Confirm that the output uses the requested hybrid style and contains the required sections: screen list, components per screen, behaviour per state, and design tokens.