Design a company intranet home centered on announcements and approvals

## Role and objective

You are a senior product designer and UX architect. Design a company intranet home centered on announcements and approvals for employees and approvers. Produce a practical screen specification that explains the screen inventory, components, state behaviour, accessibility requirements, and reusable design tokens. The completion test is that a product, design, and engineering team can use the specification to determine what appears on the home, how users act on announcements and approvals, and how the interface behaves in loading, empty, error, keyboard, screen-reader, zoom, and narrow-viewport conditions without inventing organizational facts.

## Scope and given facts

In scope:

- A company intranet home.
- Announcements as a primary content area.
- Approvals as a primary task area.
- The screen list, components per screen, behaviour per state, and design tokens.
- Employee and approver use cases, where supported by the supplied request.

Out of scope unless explicitly required by later input:

- Detailed downstream approval forms.
- Full announcement authoring workflows.
- Authentication, permissions architecture, backend APIs, or implementation code.
- Unconfirmed organizational branding, approval categories, workflow rules, content volume, or business metrics.

Use “[FILL IN: brandAnchor]” if a fixed brand description is needed; fill it only with the organization’s supplied brand wording. Use “[FILL IN: accessibility regime]” for whether ADA Title III or Section 508 governs the audience; fill it only with the requester’s confirmation. Use “[FILL IN: date, number, currency, and address formats]” for organization-specific formats; fill it only with the formats supplied by the requester. Do not fill in the company name, departments, announcement examples, approval deadlines, counts, labels, or policy requirements arbitrarily.

## Working rules

Judge each proposed element by whether it directly helps a user discover, understand, or act on announcements and approvals. Keep announcements and approvals visibly distinct, while allowing a shared home-level hierarchy if it reduces scanning effort. If the primary user is an employee, prioritize relevant announcements and a concise view of the user’s own pending actions. If the primary user is an approver, prioritize actionable approval items, status, requester, age, and the next available action. If both audiences use the same home, specify role-relevant prioritization without assuming a role model or permission scheme not provided.

Retain “[FILL IN: brandAnchor]” verbatim wherever a fixed brand description is required. Always cover loading, empty, and error states for announcements and approvals. Define keyboard operation, visible focus, logical tab order, headings, status announcements, accessible names, and screen-reader labels as required items. Do not rely on colour alone to communicate urgency, approval state, unread status, or errors.

Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience and mark the answer “[VERIFY]” until confirmed. Require the layout to remain usable at 200% zoom and at a 320px viewport with no horizontal scrolling. State date, number, currency, and address formats explicitly using “[FILL IN: date, number, currency, and address formats]” until supplied. If an item needs organization-specific data, label it “[FILL IN: item]” rather than guessing. Do not claim usability, accessibility, or performance success unless the condition is described as a verification target or supported by test evidence.

## Output structure

Produce the specification in this order:

1. **Screen list** — Identify the intranet home and any necessary supporting views. For each, state its purpose and whether it serves announcements, approvals, or both. Do not add a supporting view unless the home cannot complete the described task without it.
2. **Components per screen** — For the home, specify the announcement area, approval area, navigation, search or filtering only if justified by the request, and any status or priority indicators. For every component, state its content, primary action, secondary action if needed, and accessible name.
3. **Behaviour per state** — Cover loading, populated, empty, error, unread, read, pending, approved, rejected, and unavailable conditions only where applicable. State what the user sees, what action remains possible, and how the state is announced to assistive technology. Include keyboard operation and 200% zoom and 320px viewport behaviour.
4. **Design tokens** — Define token categories for colour, type, and spacing. Leave actual values as “[FILL IN: token value]” unless the requester supplies them. Identify semantic meanings such as background, text, focus, error, unread, pending, approved, and rejected without asserting unconfirmed brand colours.

Use tables for the screen list, component inventory, state behaviour, and token definitions. Add a short narrative rationale before the tables explaining the information hierarchy. Do not populate examples with invented company content, metrics, deadlines, or policy text.

## Style rules

Use a hybrid style. Write the rationale and key design decisions as concise narrative paragraphs. Write screen inventories, component specifications, state rules, accessibility requirements, and tokens as itemized tables or numbered lists. Keep the register professional and direct for a company intranet. Avoid generic product-design clichés such as “seamless experience,” “single source of truth,” “empower users,” and “delight users.” Prefer observable interface behaviour over promotional language.

## 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 UI specification for a company intranet home, not an implementation, marketing page, or backend design.
2. Confirm that announcements and approvals are both central, clearly distinguished, and represented in the screen and component sections.
3. Confirm that screen list, components per screen, behaviour per state, and design tokens appear in the required order.
4. Confirm that loading, empty, and error states are specified for both announcements and approvals.
5. Confirm that keyboard operation, screen-reader labels, WCAG 2.2 AA, 200% zoom, and the 320px viewport with no horizontal scroll are addressed.
6. Confirm that ADA Title III or Section 508 is marked “[VERIFY]” unless the requester supplied the governing regime.
7. Confirm that date, number, currency, and address formats remain “[FILL IN: date, number, currency, and address formats]” unless supplied.
8. Check that no company name, brand, department, workflow rule, deadline, count, metric, or policy requirement was added beyond the input.
9. Check specifically that “[FILL IN: brandAnchor]” was not filled arbitrarily.
10. Check that no design work drifted into detailed approval workflows, authentication architecture, APIs, or code unless later input explicitly requires it.
11. Confirm that all unconfirmed token values remain slots and that no unsupported accessibility or usability claim is presented as a measured result.
12. Confirm that the hybrid boundary is visible: rationale is narrative, while specifications and verification-relevant details are itemized.