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: intended employee groups and approval roles]. Produce a screen-level UI specification that a design and engineering team can use to create the home screen, its components, interaction states, and visual tokens. Completion means the specification clearly shows how users discover announcements, review pending approvals, and move from each item to its relevant action without adding unsupported organizational facts.

## Scope and given facts

In scope:

- A company intranet home.
- Announcements as a primary content area.
- Approvals as a primary action area.
- The screen structure, components, behavior, accessibility, and design tokens.
- The relationship between announcement information and approval tasks where the interface presents both.

Out of scope unless explicitly supplied: detailed department architecture, employee directory, chat, document management, analytics dashboards, payroll, HR policy content, or backend workflow implementation.

Confirmed input: the requested product is a company intranet home centered on announcements and approvals.

Leave the following unresolved:

- [FILL IN: company brand description and brandAnchor, if a fixed brand must be preserved]. Fill this with the approved brand wording, visual identity, or state that no fixed brand description applies.
- [FILL IN: user roles and approval types]. Fill this with the actual roles and approval actions supported.
- [FILL IN: announcement categories, priority rules, and content ownership]. Fill this with the organization’s confirmed taxonomy and governance.
- [FILL IN: date, number, currency, and address formats]. Fill this with the formats required by the intended audience and locale.
- [FILL IN: accessibility governance]. Fill this with whether ADA Title III or Section 508 governs the audience, or another confirmed authority.

Do not invent a company name, departments, approval deadlines, notification counts, brand colors, or workflow rules.

## Working rules

Apply the UI modality. Treat the home screen as a task-oriented entry point, not as a generic portal. Judge each proposed element by whether it helps users understand an announcement, identify an approval requiring attention, or reach the correct next action.

Use these rules:

1. Preserve any fixed `brandAnchor` exactly as supplied. If none is supplied, use neutral labels and leave branding as a slot.
2. Define the information hierarchy between announcements and approvals. If approvals are time-sensitive or assigned to a specific user, place the relevant task summary where it is immediately discoverable; if priority rules are not supplied, label the prioritization logic as [FILL IN: approval priority rule] rather than choosing one.
3. Cover loading, empty, and error states for announcements, approvals, and the home screen. State what users see, what action is available, and whether stale content is disclosed.
4. Specify keyboard operation for navigation, announcement cards, filters, approval actions, dialogs, and menus. Provide meaningful screen-reader labels, landmarks, heading order, focus movement, and status announcements.
5. Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience; name the applicable authority without asserting what it requires.
6. Require the layout to survive 200% zoom and a 320px viewport without horizontal scrolling. Identify responsive changes rather than merely shrinking every component.
7. State date, number, currency, and address formats explicitly using the confirmed format slots. Do not assume US formatting or create sample values.
8. If a decision depends on supplied business rules, branch explicitly: use the supplied rule when confirmed; otherwise mark the dependency [FILL IN: rule] and show the interface behavior that still can be designed safely.

## Output structure

Order the deliverable exactly as follows:

1. **Screen list** — Name the intranet home and any directly necessary states or destinations. For each, state its purpose and relationship to announcements or approvals. Do not expand into unrelated screens.
2. **Components per screen** — Describe the header, navigation, announcement area, approval area, search or filtering controls if justified, notification or status elements, and primary actions. For every component, specify content, hierarchy, interaction, and responsive behavior.
3. **Behaviour per state** — Cover loading, populated, empty, error, success, permission-restricted, and stale-data conditions where relevant. Explain keyboard behavior, focus management, screen-reader announcements, and recovery actions.
4. **Design tokens** — Specify colour roles, typography, spacing, borders, elevation, icon treatment, focus indication, and responsive breakpoints. Use confirmed brand values or `[FILL IN: token value]` slots; never fabricate brand colors.
5. **Open decisions** — List only decisions needed to complete the design, including roles, approval rules, content ownership, brandAnchor, date/number/currency/address formats, and accessibility authority.

Use concise tables for component inventories, state behavior, and design tokens. Use short narrative paragraphs only to explain hierarchy, task flow, and responsive rationale.

## Style rules

Use a hybrid style. Use itemized, table-ready language for screens, components, states, tokens, requirements, and open decisions. Use concise narrative paragraphs for the design rationale and the relationship between announcements and approvals. Keep the register professional, direct, and suitable for cross-functional product teams. Avoid vague UX clichés such as “seamless experience,” “single source of truth,” “intuitive design,” and “empower users” unless you define the observable interface behavior they describe.

## 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 an intranet home design specification, not implemented code, marketing copy, or a general employee portal plan.
2. Confirm that announcements and approvals are the central information and action areas in the screen hierarchy.
3. Check every role, approval type, category, priority rule, deadline, count, company name, and brand value against the input; mark anything absent as a slot.
4. Check that no `[FILL IN: company brand description and brandAnchor]` or other slot was filled with an arbitrary example.
5. Confirm that loading, empty, and error states are specified for both announcements and approvals, with recovery behavior.
6. Confirm that keyboard operation and screen-reader labels appear as explicit requirements rather than implied accessibility claims.
7. Confirm the WCAG 2.2 AA target is present and that ADA Title III or Section 508 is treated as an authority to identify, not as an assumed applicable regime.
8. Confirm that 200% zoom and the 320px viewport are addressed without horizontal scrolling.
9. Confirm that date, number, currency, and address formats remain explicit slots unless the input supplies them.
10. Remove any invented feature or content area outside the requested announcements-and-approvals intranet scope.
11. Confirm that tables cover components, state behavior, and design tokens, while narrative text is limited to hierarchy and rationale.
12. Confirm that the final specification preserves any supplied `brandAnchor` wording verbatim and does not introduce unsupported visual details.