Design a newsletter signup widget for a blog

## Role and objective

You are a UX/UI designer creating an implementation-ready specification for a newsletter signup widget for a blog. Produce a responsive component design for blog readers and the team that will build it, without inventing the blog’s brand, audience, data practices, or technical stack.

The output must use the required UI structure: screen list, components per screen, behaviour per state, and design tokens. Completion means every required state, interaction, accessibility item, and responsive constraint is specified clearly enough for implementation or for a targeted follow-up question.

Use “[FILL IN: item]” for any value not supplied. Add one line explaining what information belongs in each slot.

## Scope and given facts

In scope:

- A newsletter signup widget for a blog.
- The widget’s visible layout, fields, actions, states, responsive behaviour, accessibility behaviour, and design tokens.
- The experience before submission, during submission, after successful submission, and after failure.
- The smallest necessary set of screens or component states needed to describe the widget completely.

Confirmed fact:

- The product is a blog newsletter signup widget.

Not confirmed and therefore requiring slots:

- Blog topic or audience: [FILL IN: blog audience or topic]. Fill this with the intended reader group or editorial subject.
- Brand identity: [FILL IN: brand description]. Fill this with confirmed logo, colour, typography, voice, and visual-identity details, or state that none exists.
- Signup fields: [FILL IN: newsletter fields]. Fill this with the fields the widget must collect.
- Consent and privacy copy: [FILL IN: consent wording and privacy-link destination]. Fill this with approved legal and editorial text.
- Submission destination and integration: [FILL IN: submission destination or service]. Fill this with the confirmed endpoint, email platform, or implementation boundary.
- Confirmation behaviour: [FILL IN: post-submit behaviour]. Fill this with the approved success message, redirect, double-opt-in flow, or other confirmed outcome.

Do not fill the blog audience, brand description, newsletter fields, consent wording, submission destination, or confirmation behaviour with plausible guesses.

## Working rules

Judge each design decision against four criteria: clarity of the signup task, low interaction effort, accessibility, and resilience across viewport sizes. Use only the confirmed input and clearly label recommendations as recommendations. Do not claim that a layout improves conversion unless that claim is supported by measured evidence; otherwise describe the intended UX benefit without quantifying it.

Apply these branches:

1. If required fields are confirmed, use only those fields. If they are not confirmed, show the field area as a design decision with “[FILL IN: newsletter fields]” rather than choosing fields arbitrarily.
2. If a brand description is confirmed, preserve its stated visual characteristics. If it is absent, use neutral design tokens marked “[FILL IN: brand tokens]” and do not invent a brand identity.
3. If consent or privacy requirements are supplied, represent them exactly. If they are absent, include a clearly marked “[FILL IN: consent and privacy treatment]” decision point rather than asserting that consent is or is not required.
4. If the widget is embedded in a page, specify how it behaves within the surrounding blog layout. If placement is unknown, mark “[FILL IN: widget placement]” and cover the component without assuming a sidebar, footer, modal, or inline location.
5. If an interaction cannot be completed, define the visible error, focus movement, correction path, and whether entered values remain. Do not invent backend error codes.

Use WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs the audience; leave the answer as “[FILL IN: applicable accessibility regime]” unless confirmed. Require keyboard-only operation, visible focus, logical tab order, accessible names, useful error associations, and screen-reader announcements for asynchronous status changes.

Ensure the layout survives 200% zoom and a 320px viewport with no horizontal scrolling. State US date, number, currency, and address formats explicitly only if those data types appear; otherwise mark them “[FILL IN: applicable format]”.

## Output structure

Produce the specification in this order:

1. **Screen list** — Provide a compact list of the widget’s required views or states. Include the initial form, loading/submission state, successful completion state, and error state. Add an empty state only if the design has a meaningful empty condition; otherwise state why it does not apply. Allocate no more than 150 words.
2. **Components per screen** — For every listed screen or state, specify the container, heading, supporting text, fields, consent area, submit control, status message, close or reset control if applicable, and any required accessible name. Mark unconfirmed content with “[FILL IN: item]”. Use a table where useful.
3. **Behaviour per state** — Describe focus order, keyboard operation, validation timing, preservation of entered values, loading feedback, success handling, failure recovery, and screen-reader announcements. Include responsive behaviour at 320px and 200% zoom. State the conditional behaviour for confirmed versus unconfirmed submission and consent requirements.
4. **Design tokens** — Provide tokens for colour, typography, spacing, borders, radius, focus indication, control height, and breakpoints. Use “[FILL IN: token]” for values not provided; do not fabricate brand colours or type scales.

Use concise tables and bullets for specifications. Use short narrative notes only where a design rationale or conditional branch cannot be expressed clearly in a row. Do not provide production code unless explicitly requested.

## Style rules

Use a hybrid style. Use tables and numbered or bulleted lists for screens, components, states, requirements, and tokens. Use brief narrative paragraphs only for rationale, assumptions, and conditional branches. Keep the register professional and implementation-focused. Avoid generic UX clichés such as “seamless experience,” “delight users,” “best-in-class,” “frictionless,” and unsupported claims that the widget will increase subscriptions.

## 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 production code, marketing copy, or a full blog redesign.
2. Confirm that the output contains all four required UI sections: screen list, components per screen, behaviour per state, and design tokens.
3. Confirm that loading, success, failure, and any applicable empty state are explicitly handled.
4. Confirm that keyboard operation, focus behaviour, accessible names, error associations, and screen-reader status announcements are specified.
5. Confirm that WCAG 2.2 AA is named and that ADA Title III or Section 508 is left as a confirmation slot rather than assumed.
6. Confirm that 200% zoom and a 320px viewport are addressed with no horizontal scrolling.
7. Check that the blog audience, brand description, newsletter fields, consent wording, submission destination, and confirmation behaviour were not filled arbitrarily.
8. Check that no facts about the blog, platform, privacy regime, conversion performance, or backend were added beyond the input.
9. Check that any date, number, currency, or address format is stated only when relevant and otherwise remains a slot.
10. Check that the response stays within the newsletter widget’s design scope and does not drift into unrelated blog navigation, content strategy, or implementation code.
11. Confirm that every “[FILL IN: item]” slot includes a one-line instruction describing what must replace it.
12. Confirm that the final specification is concise enough to implement while retaining every required state, accessibility condition, responsive constraint, and design-token category.