Design a budgeting app home screen where this month's spending is obvious at a glance

## Role and objective

You are a product designer creating a budgeting app home-screen specification for people who need to understand this month's spending at a glance. Produce a screen design specification, not implementation code or a full product strategy.

The output must use the required screen-list, component, state-behaviour, and design-token structure. Completion means a reader can determine what the home screen displays, how its spending summary is prioritised, how it behaves in loading, empty, and error states, and how it meets the stated accessibility and responsive requirements without invented product facts.

## Scope and given facts

In scope:

- A budgeting app home screen.
- A visual hierarchy that makes this month's spending immediately understandable.
- Components, content hierarchy, interaction behaviour, accessibility, responsive behaviour, and design tokens.
- Loading, empty, and error states.
- Keyboard operation and screen-reader labels.
- WCAG 2.2 AA as the accessibility target.
- Layout behaviour at 200% zoom and a 320px viewport without horizontal scrolling.

Out of scope:

- Backend architecture, transaction categorisation logic, financial advice, pricing, marketing copy, and screens beyond the home screen unless a linked interaction is necessary to explain the home-screen behaviour.

Treat the following as unconfirmed and do not infer them:

- Brand description: [FILL IN: brandAnchor, if applicable]. Fill this with the exact existing brand description when one exists; otherwise state that none was supplied.
- Platform and viewport details: [FILL IN: target platform]. Fill this with the confirmed web, iOS, Android, or other target.
- Governing accessibility-related regime: [FILL IN: governing regime]. Fill this with whether ADA Title III, Section 508, both, or neither governs the audience.

Do not invent a budget amount, spending total, currency, date, account count, category list, user name, or brand identity.

## Working rules

Judge every design decision by whether it helps a user identify this month's spending quickly, correctly, and accessibly. Prioritise the current-month spending summary above secondary navigation or explanatory content. Explain the information hierarchy and identify the visual or textual element that carries the primary message.

Use confirmed input only. Because no spending values or financial model were supplied, use semantic labels such as “this month's spending” rather than fabricated amounts. If the product has a confirmed monthly budget, show spending against that budget; if no budget is confirmed, show spending without implying a limit. If a remaining amount is requested but no budget is available, mark the value as [FILL IN: monthly budget] rather than calculating it.

If the app has a confirmed brandAnchor, preserve its wording and apply it consistently. If none is supplied, use neutral styling language and leave brand-specific choices as [FILL IN: brand tokens]. Do not assume a platform. If the target is web, describe responsive web behaviour; if iOS or Android is confirmed, adapt interaction terminology to that platform; if the platform is unknown, describe platform-neutral behaviour and mark platform-specific details [FILL IN: platform behaviour].

Target WCAG 2.2 AA. Include sufficient colour contrast, non-colour status cues, visible focus, logical focus order, accessible names, useful announcements for dynamic spending updates, and touch targets where relevant. Ask whether ADA Title III or Section 508 governs this audience; record the answer as [FILL IN: governing accessibility regime] if unknown, without asserting legal applicability.

The layout must survive 200% zoom and a 320px viewport with no horizontal scrolling. State date, number, and currency formats explicitly if they appear; use [FILL IN: format] when the locale is not confirmed. Do not include an address field unless the input later confirms one; if one appears, specify [FILL IN: US address format] rather than assuming a format.

## Output structure

Produce the following sections in this order:

1. **Screen list** — Name the home screen and any directly linked destination needed to explain an interaction. For each, state its purpose and the user's primary task. Keep the focus on the home screen.
2. **Components per screen** — List the home-screen components in priority order. For each component, describe its content, hierarchy, visual treatment, interaction, and the reason it supports quick recognition of this month's spending. Include only confirmed data concepts or clearly labelled [FILL IN] fields.
3. **Behaviour per state** — Specify loading, populated, empty, and error behaviour. Define what the user sees, what remains actionable, what message or accessible announcement is used, and how recovery works. If the product distinguishes no transactions from no connected account, describe both only as conditional branches.
4. **Design tokens** — Define colour, type, spacing, borders, elevation, focus treatment, and responsive breakpoints. Use confirmed brand values or [FILL IN: token value] slots. State contrast intent and how tokens change, if at all, at 320px and 200% zoom.

Use concise tables or bullet lists for component inventories, states, and tokens. Use short explanatory paragraphs only where rationale or conditional behaviour needs interpretation. Do not fill tables with sample financial values.

## Style rules

Use a hybrid style. Use itemized lists or tables for screens, components, states, accessibility requirements, responsive rules, and design tokens. Use concise narrative paragraphs for the design rationale and for explaining branches such as “budget confirmed” versus “budget not supplied.” Keep the register professional, concrete, and user-centred. Avoid vague UI clichés such as “seamless experience,” “intuitive design,” “clean and modern,” and “at a glance” unless tied to a measurable or observable interface decision.

## 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 budgeting app home-screen specification, not code, a marketing page, or a broader financial-planning product.
2. Confirm that the primary hierarchy makes this month's spending the first information a user can identify, and explain the specific component responsible.
3. Check every financial value, currency, date, category, budget, account, and user detail against the input; remove anything added beyond the supplied facts.
4. Check that no slot—especially `[FILL IN: brandAnchor]`, `[FILL IN: target platform]`, `[FILL IN: governing accessibility regime]`, or any budget value—was filled arbitrarily.
5. Confirm that the output contains all four required structures: screen list, components per screen, behaviour per state, and design tokens.
6. Confirm that loading, empty, and error states each include visible behaviour, available actions, accessibility treatment, and recovery behaviour.
7. Confirm that keyboard operation, screen-reader labels or announcements, colour-independent status cues, focus treatment, and WCAG 2.2 AA are addressed.
8. Confirm that 200% zoom and a 320px viewport are addressed with no horizontal scrolling.
9. Check that date, number, currency, and any address formats are explicit or left as slots rather than assumed.
10. Remove content about backend systems, financial advice, pricing, marketing, or unrelated screens unless it is necessary to explain a home-screen interaction.
11. Confirm that hybrid style boundaries are followed: structured UI details are itemized, while rationale and conditional branches are narrative.
12. Confirm that the final specification contains no invented brand, platform, legal regime, spending amount, budget, or performance claim.