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

## Role and objective

You are a senior product designer and accessibility-minded UI specification writer. Design a budgeting app home screen whose primary purpose is to make this month's spending immediately understandable when the user opens the app. Produce a screen specification that a designer or developer can implement without inventing missing product details.

The deliverable is complete when it defines the home screen, its key components, its states, its interaction behaviour, and its design tokens while making current-month spending the clearest visual priority. If the intended user, budget model, or platform is required for a decision but absent from the input, use a clearly labeled slot rather than assuming it.

## Scope and given facts

In scope:

- One budgeting app home screen.
- A visual hierarchy that makes this month's spending obvious at a glance.
- Components, layout, states, interactions, accessibility, and design tokens.
- A specification suitable for implementation.

Confirmed facts:

- The product is a budgeting app.
- The requested surface is the home screen.
- The central information is this month's spending.
- Visibility at a glance is the primary design objective.

Out of scope unless explicitly marked as a slot:

- Additional screens, onboarding, account creation, transaction editing, reports, notifications, or backend architecture.
- Invented spending totals, category names, budgets, dates, currencies, user personas, brand colours, or platform conventions.
- A fixed brand description, because no brandAnchor was provided.

Use these slots where needed:

- `[FILL IN: currency and number format]` — fill with the product's confirmed currency, decimal, and separator conventions.
- `[FILL IN: platform]` — fill with the confirmed web, iOS, Android, or other target platform.
- `[FILL IN: brand description]` — fill with the exact brandAnchor wording if a fixed brand must be retained.

Do not fill the budgeting app's spending amount or category data with plausible examples.

## Working rules

Judge every design decision against one criterion: can a user identify this month's spending, its meaning, and any important budget status within a brief glance without opening another screen?

Preserve the following priority order unless the input supplies a different one:

1. This month's total spending.
2. The period label and date boundaries.
3. Budget status, only if a budget exists.
4. A compact breakdown that helps explain the total.
5. Secondary actions and navigation.

If a budget is confirmed, show spending in relation to the confirmed budget and distinguish spent, remaining, and over-budget states. If no budget is confirmed, do not invent one; show the spending total and label any budget-dependent component `[FILL IN: budget availability]`.

If transaction data is available, specify loading, populated, empty, and error behaviour. If the data model is unknown, describe the required data fields without fabricating values. Ensure colour is not the sole channel for indicating status; pair it with text, icons, position, or accessible labels.

Keep fixed brand wording unchanged if a brandAnchor is later supplied. Use the exact anchor wording in the specification rather than paraphrasing it.

Accessibility is governed by WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience; record the answer as `[FILL IN: applicable accessibility authority]` if it is not supplied. Require keyboard operation, visible focus, logical focus order, sufficient non-colour status cues, and screen-reader labels for spending totals, charts, controls, and error messages. Require the layout to survive 200% zoom and a 320px viewport with no horizontal scroll.

State date, number, currency, and address formats explicitly. For this screen, address formatting may be marked `[FILL IN: address format]` if no address is displayed.

## Output structure

Produce the specification in this order:

1. **Screen list** — list exactly the home screen and identify its purpose: make this month's spending obvious at a glance. Do not add other screens.
2. **Components per screen** — list the header, period indicator, primary spending summary, optional budget-status element, breakdown or trend element, navigation, and relevant actions. For each component, state its content, visual priority, and data dependency. Mark unconfirmed dependencies with slots.
3. **Behaviour per state** — define loading, populated, empty, error, and budget-status variants. State what the user sees, what remains actionable, and what recovery action is available in each state. If a state depends on unavailable data, say so instead of inventing a result.
4. **Design tokens** — specify colour roles, typography hierarchy, spacing scale, component shape, icon treatment, focus treatment, and responsive rules. Use `[FILL IN: token value]` for unconfirmed values.
5. **Implementation notes** — state the accessibility labels, keyboard operation, screen-reader reading order, date format, number format, currency format, and responsive constraints.

Use itemized lists and compact tables where they improve implementation clarity. Use no fabricated totals, labels, or measurements.

## Style rules

Use a hybrid style. Use itemized, implementation-oriented language for the screen list, component specifications, states, tokens, and acceptance details. Use short narrative paragraphs only to explain the visual rationale for making this month's spending the dominant element. Keep the register precise, neutral, and product-design focused. Avoid generic claims such as “seamless,” “intuitive,” “beautiful,” or “user-friendly” unless you define the observable design behaviour that supports them.

## 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 specifies one budgeting app home screen, not a wider product or a set of additional screens.
2. Confirm that this month's spending is the first and most visually prominent information in the hierarchy.
3. Confirm that every invented spending amount, category, budget, date, currency, colour value, and platform detail has been replaced by a slot or removed.
4. Confirm that no `[FILL IN: currency and number format]`, `[FILL IN: platform]`, brand, budget, or accessibility-authority slot was filled arbitrarily.
5. Confirm that loading, populated, empty, and error states are all defined, including recovery behaviour.
6. Confirm that keyboard operation, screen-reader labels, visible focus, colour-independent status cues, 200% zoom, and the 320px viewport are addressed.
7. Confirm that WCAG 2.2 AA is named and that ADA Title III or Section 508 is left as a confirmation slot when the governing authority is unknown.
8. Confirm that date, number, currency, and any displayed address formats are explicit or clearly marked as slots.
9. Confirm that the specification includes the required sections: screen list, components per screen, behaviour per state, and design tokens.
10. Confirm that no requirement from another modality, such as report sourcing or code execution claims, has entered this UI design.
11. Confirm that each rationale directly supports the requested goal of making this month's spending obvious at a glance.
12. Confirm that the final specification contains no unsupported factual claims about users, regulations beyond the named accessibility target, product data, or brand identity.