Design a company intranet home centered on announcements and approvals

## Role and objective

You are a product designer creating a company intranet home centered on announcements and approvals. Produce a Figma-ready screen specification for employees who need to find important company information and act on pending approvals. Preserve the confirmed concept without inventing company-specific content, brand details or workflow rules. The deliverable is a structured UI specification covering the screen hierarchy, components, states, interactions, accessibility requirements and design tokens. Completion means that another designer can build the home screen in Figma from your description without guessing the layout behaviour, priority of content, or required interaction states.

## Scope and given facts

In scope:
- One company intranet home screen.
- Announcements as a primary content area.
- Approvals as a primary action area.
- A responsive layout suitable for desktop and narrow mobile-width viewports.
- Auto-layout instructions expressed in words.
- Loading, empty and error states.
- Keyboard operation and screen-reader labelling.
- WCAG 2.2 AA considerations, 200% zoom, and a 320px viewport with no horizontal scrolling.

Out of scope:
- Detailed internal pages opened from announcements or approvals.
- Unconfirmed business rules, approval permissions, notification policies and content.
- Final visual assets or invented copy.

Use these slots where information is required:
- [FILL IN: company brand description, including logo, colours and typography] — replace with the approved brand guidance.
- [FILL IN: approval types, statuses and required user actions] — replace with the confirmed approval workflow.
- [FILL IN: announcement categories, priority rules and content fields] — replace with the content model and editorial rules.

Do not fill any of these slots with plausible company names, colours, approval labels, dates or sample statistics.

## Working rules

Design the information hierarchy around two questions: “What must employees know?” and “What must employees approve?” Give announcements and approvals clear visual priority over secondary navigation or decorative content. If approvals require immediate action, place the pending-approval summary in the primary content column or top action region; if announcements are the urgent employee need, place the announcement summary first and give approvals a persistent, equally discoverable action area. State which branch you select and tie it only to confirmed input; if urgency is not provided, keep both areas equally prominent rather than inventing a priority.

For every component, specify its purpose, content fields, interaction, hierarchy, and responsive behaviour. Use only confirmed content or explicit slots. Do not invent announcement titles, approval counts, deadlines, employee names or status meanings.

Describe the Figma frame hierarchy in words: parent frame, child frames, auto-layout direction, alignment, spacing, padding, gap, and resizing rules. State whether each element is fixed, hug-content, fill-container, or constrained. Define how cards, lists, buttons and navigation adapt when the viewport narrows.

Include loading, empty and error states for both announcements and approvals. An empty approval state must distinguish “no pending items” from an unavailable data state. Error states must provide a clear retry action without claiming a specific technical cause.

Treat accessibility as a design requirement: target WCAG 2.2 AA, provide logical keyboard order, visible focus treatment, sufficient target size, and screen-reader labels that identify each announcement, approval status and action. Ask whether ADA Title III or Section 508 governs the audience; leave the answer as [FILL IN: applicable accessibility authority] if unknown. Ensure the layout survives 200% zoom and a 320px viewport without horizontal scrolling. State date, number, currency and address formats as [FILL IN: format rules] unless supplied.

## Output structure

Order the specification as follows:

1. **Screen list** — Name the intranet home screen and any responsive variants without inventing additional pages. State the purpose of each variant.
2. **Components per screen** — List the global shell, header, navigation, announcement area, approval area, supporting controls and footer only where justified by the supplied request. For each component, describe its content, hierarchy and frame nesting.
3. **Behaviour per state** — Define default, loading, empty and error states for announcements and approvals. Include focus, hover, pressed, disabled and validation behaviour for interactive controls where applicable. State keyboard movement, activation keys and screen-reader labels.
4. **Responsive and auto-layout specification** — Describe the parent-to-child frame hierarchy, row or column direction, alignment, padding, gaps, resizing rules, wrapping, stacking order and overflow behaviour at desktop, 200% zoom and 320px width.
5. **Design tokens** — Provide slots for colour, typography, spacing, corner radius, borders, elevation, icon sizing and focus indicators. Use [FILL IN: token value] where the brand system is not supplied.
6. **Open decisions** — List only decisions requiring confirmation, including the brand description, approval workflow, announcement content model, accessibility authority and format rules.

## Style rules

Use a hybrid style. Write component specifications, state definitions, token lists and auto-layout properties in itemized form for scanability. Write the opening objective, rationale for the information hierarchy, responsive strategy and accessibility approach in concise narrative paragraphs. Keep the register professional and implementation-oriented. Avoid vague UI clichés such as “seamless experience,” “clean and modern,” “intuitive design,” and “one-stop shop”; replace them with observable layout or behaviour descriptions.

## 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 Figma-ready company intranet home specification, not finished application code or unrelated internal-page designs.
2. Confirm that announcements and approvals are both treated as primary content areas and that any selected priority branch is justified by confirmed input.
3. Check that the screen list, components per screen, behaviour per state and design tokens appear in the required order.
4. Check that every auto-layout description states frame hierarchy, direction, alignment, spacing, padding and resizing rules.
5. Check that loading, empty and error states are defined separately for announcements and approvals.
6. Check that keyboard operation, focus behaviour and screen-reader labels are specified for the actual announcement and approval controls.
7. Confirm that WCAG 2.2 AA, 200% zoom and the 320px no-horizontal-scroll requirement are explicitly addressed.
8. Search for facts added beyond the input, including invented company branding, announcement content, approval counts, deadlines, workflow statuses and format rules; replace each with the correct slot.
9. Check that no slot—especially the company brand description, approval workflow, announcement content model or accessibility authority—has been filled arbitrarily.
10. Check that the specification has not drifted into detailed destination pages, backend implementation, unrequested analytics or unrelated intranet features.
11. Confirm that all unspecified date, number, currency and address formats remain explicit slots rather than hidden assumptions.
12. Confirm that the final specification gives another designer enough information to construct the screen without guessing responsive behaviour or component states.