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 [FILL IN: primary employee audience and approval decision-makers]. Produce a practical screen specification that can guide design and implementation without inventing company-specific facts. The output must describe the home screen, its components, state behavior and reusable design tokens in the required structure. Completion means that a reader can identify how users find announcements, review pending approvals, act on approval items, and use the screen in loading, empty and error conditions without needing unstated product decisions.

## Scope and given facts

In scope:
- A company intranet home.
- Announcements as a central content area.
- Approvals as a central task area.
- The screen structure, components, interactions, states and visual tokens.
- The relationship between employee-facing information and approval actions.

Confirmed facts:
- The product is a company intranet.
- The requested home is centered on announcements and approvals.

Leave these items as slots and add the stated completion instruction:
- `[FILL IN: brand description and visual identity]` — fill with the approved brand name, logo treatment, colours, typography and visual constraints.
- `[FILL IN: approval types, roles and workflow states]` — fill with the actual approval requests, eligible approvers, statuses and available actions.
- `[FILL IN: navigation inventory and connected systems]` — fill with confirmed destinations, integrations and data sources.
- `[FILL IN: target devices, accessibility governance and regional formats]` — fill with supported devices, whether ADA Title III or Section 508 governs, and date, number, currency and address formats.

Do not add departments, employee counts, policies, integrations, deadlines or approval rules unless supplied or confirmed.

## Working rules

Use the fixed facts as requirements, not as evidence for invented product behavior. Treat announcements and approvals as distinct but coordinated priorities:

1. If the approval workflow is confirmed, show its actual states, roles and actions. If it is not confirmed, label workflow details `[FILL IN: approval workflow details]` and describe only the component structure needed to display them.
2. If announcement priority rules are confirmed, apply them. Otherwise, define the ranking as a configurable product decision rather than choosing recency, urgency or audience without evidence.
3. If an approval action is reversible, identify the reversal path. If reversibility is unknown, do not promise undo; mark `[FILL IN: reversal and correction behavior]`.
4. Separate read-only announcement actions from consequential approval actions. Approval controls must make the item, decision, confirmation and resulting status distinguishable.
5. Cover loading, empty and error states for both announcements and approvals, plus the overall page. Explain what remains usable, what message appears, and what recovery action is offered.
6. Specify keyboard operation, visible focus, logical tab order, semantic labels and screen-reader labels for navigation, announcement cards, filters, approval controls and status changes.
7. Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience; mark the answer `[VERIFY]` if it is not provided.
8. Require the layout to survive 200% zoom and a 320px viewport without horizontal scrolling.
9. State date, number, currency and address formats explicitly. If a format is not supplied, use `[FILL IN: format]` rather than selecting one.
10. Preserve `[FILL IN: brand description and visual identity]` throughout the design rather than substituting a generic brand style.

## Output structure

Return the specification in exactly this order:

1. **Screen list** — list the intranet home and any directly necessary responsive or modal views. For each, state its purpose and relationship to announcements or approvals. Do not expand into unrelated intranet sections.
2. **Components per screen** — identify the header, navigation, announcement area, approval area, search or filtering controls if justified, status indicators, action controls and supporting elements. For every component, state its content, hierarchy, interaction and data dependency. Mark unknown dependencies with `[FILL IN: item]`.
3. **Behaviour per state** — provide subsections or a table covering loading, populated, empty and error states for the announcement area, approval area and page-level failures. Include keyboard behavior, screen-reader feedback, confirmation behavior and recovery actions.
4. **Design tokens** — specify tokens for colour, type and spacing. Keep values as `[FILL IN: token value]` unless the user supplied them. Include contrast considerations, focus indication, status differentiation and responsive rules.

Output contract:
- Use markdown headings and lists.
- Keep the deliverable focused on the company intranet home.
- Include all four required output sections above.
- Do not invent approval types, brand values, content counts or integrations.
- Mark every unresolved item with `[FILL IN: item]` or `[VERIFY]`.
- State the WCAG 2.2 AA target and the applicable ADA Title III or Section 508 status.
- Explicitly cover 200% zoom and a 320px viewport with no horizontal scroll.

## Style rules

Use a hybrid style. Write the screen list, component inventory, state matrix and design tokens in itemized form for scanning. Write short narrative explanations only where interaction logic, prioritization, accessibility behavior or a design trade-off needs context. Use a clear enterprise UX register: precise, neutral and implementation-oriented. Avoid clichés such as “seamless experience,” “single source of truth,” “empower employees,” and “streamline everything.” Do not use promotional language or unsupported claims.

## 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 company intranet home specification, not a general intranet strategy or a finished visual mockup.
2. Confirm that announcements and approvals are both first-class areas and that their hierarchy is explained.
3. Confirm that the output contains **screen list**, **components per screen**, **behaviour per state**, and **design tokens** in that order.
4. Confirm that loading, empty and error behavior is specified for both announcements and approvals.
5. Confirm that keyboard operation and screen-reader labels are addressed for the home screen’s interactive elements.
6. Confirm that WCAG 2.2 AA, ADA Title III or Section 508 status, 200% zoom and the 320px viewport requirement appear explicitly.
7. Check every added fact about approval types, roles, statuses, integrations, branding or formats; replace anything not present in the input with the appropriate `[FILL IN: item]` slot.
8. Check that no slot for the approval workflow, brand description, navigation inventory or regional formats was filled arbitrarily.
9. Check that the specification does not drift into unrelated intranet modules, implementation code, research, marketing copy or invented content.
10. Confirm that the output contract is satisfied, including markdown conventions, required sections, unresolved-item markers and the requested hybrid style.