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 for people who need to understand this month's spending immediately. Produce a structured screen specification that makes the current month's spending the primary visual priority without inventing financial values, account data, or brand details.

The output must identify the screen, its components, its behavior in each required state, and its design tokens in the prescribed order. Completion means a reader can implement or review the home screen and can tell, without opening another screen, how this month's spending is surfaced, interpreted, and accessed.

## Scope and given facts

In scope:

- A budgeting app home screen.
- A visual hierarchy that makes this month's spending obvious at a glance.
- The information, components, interactions, states, accessibility details, and visual tokens needed to specify that screen.

The only confirmed product fact is the requirement to design a budgeting app home screen where this month's spending is obvious at a glance.

Treat the following as unconfirmed and do not choose values for them:

- **[FILL IN: target platform and viewport]** — provide the primary device, operating system, and supported viewport sizes.
- **[FILL IN: brandAnchor]** — provide the exact fixed brand description if a brand identity must remain unchanged.
- **[FILL IN: currency and locale]** — provide the supported currency, date format, and locale.
- **[FILL IN: data model]** — provide the available spending, budget, account, category, and transaction fields.
- **[FILL IN: accessibility governance]** — confirm whether ADA Title III or Section 508 governs the audience.

Do not fill the actual monthly spending amount, budget amount, percentage, category names, account names, or brandAnchor arbitrarily. If a value is needed to explain a component, label it as a slot or describe its role without supplying a sample value.

Out of scope are backend implementation, financial advice, regulatory conclusions, and screens other than the home screen unless a secondary screen is necessary to explain a clearly marked interaction destination.

## Working rules

Judge every design decision against one question: can a user identify this month's spending, understand what the figure means, and notice whether it relates to a budget without searching the screen?

Use the confirmed requirement as the primary evidence. Separate confirmed facts from design proposals. When proposing a visual treatment, explain the usability reason: prominence, comprehension, comparison, actionability, or error prevention. Do not claim that a pattern improves engagement, retention, or financial outcomes unless evidence is supplied; otherwise mark the claim **[VERIFY]** or omit it.

Use these branches:

1. If a monthly spending total is available in the data model, make it the primary summary element and define its label, unit, period, and comparison context.
2. If a monthly spending total is unavailable, do not manufacture one; specify the missing field as **[FILL IN: monthly spending total]** and design a clearly labeled unavailable-data state.
3. If a monthly budget is available, show spending against that budget with an explicit remaining or exceeded state.
4. If no monthly budget is available, do not imply that a budget exists; present spending independently and identify the missing budget field.
5. If category or transaction data is available, use it only as supporting context after the primary monthly total. If it is unavailable, specify an empty or unavailable state.

Always cover loading, empty, and error states. Define keyboard operation, visible focus, screen-reader labels, and accessible names for interactive elements. Set the accessibility target to **WCAG 2.2 AA**. Ask whether **ADA Title III** or **Section 508** governs this audience; do not assume either applies.

The layout must remain usable at 200% zoom and at a 320px viewport with no horizontal scrolling. State date, number, currency, and address formats explicitly; use slots where they are not provided. Keep the fixed brand description unchanged if a brandAnchor is supplied.

## Output structure

Produce the specification in exactly this order:

1. **Screen list**
   - Name the home screen.
   - State its single primary user purpose.
   - Identify any secondary destination only when required by an interaction, and label it as outside the home-screen implementation scope.

2. **Components per screen**
   - List the component that displays this month's spending first.
   - For each component, provide its purpose, content, hierarchy, data dependency, interaction, and accessible name.
   - State how the primary spending summary remains visually dominant.
   - Mark every unconfirmed value with its exact **[FILL IN: item]** slot.

3. **Behaviour per state**
   - Specify loading, populated, empty, and error behavior.
   - Include the conditions that trigger each state, the user-visible message, recovery action, keyboard behavior, focus handling, and screen-reader announcement.
   - Explain the branch for available versus unavailable monthly spending data and available versus unavailable budget data.
   - Include behavior for 200% zoom and a 320px viewport with no horizontal scroll.

4. **Design tokens**
   - Define colour roles, typography, spacing, sizing, borders, focus indication, icon treatment, and responsive rules.
   - Provide values only when confirmed; otherwise use **[FILL IN: token value]** and state what supplies the value.
   - State the date, number, currency, and address formats explicitly using slots where necessary.

Use concise implementation-ready descriptions. Do not provide invented numbers, percentages, category totals, product names, or visual test results.

## Style rules

Use a hybrid style. Use itemized lists and compact tables for the screen list, component specifications, state behavior, and design tokens. Use short narrative paragraphs only to explain the hierarchy and why the monthly spending summary satisfies the “obvious at a glance” requirement. Keep the register practical and precise. Avoid vague UI clichés such as “seamless experience,” “clean and modern,” “intuitive design,” and “ユーザー中心” equivalents unless replaced by an observable property.

## 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, backend architecture, financial advice, or a multi-screen product plan.
2. Confirm that the first and most prominent component makes **this month's spending** identifiable at a glance.
3. Confirm that every monthly spending amount, budget value, category value, account name, brand detail, locale, and token value absent from the input remains a slot rather than an invented value.
4. Confirm that no facts were added beyond the single confirmed design request, including unsupported claims about user behavior, financial outcomes, accessibility compliance, or product performance.
5. Confirm that no **[FILL IN: item]** slot was filled arbitrarily and that every slot includes a line identifying what information supplies it.
6. Confirm that the output includes the required **screen list**, **components per screen**, **behaviour per state**, and **design tokens** sections in that order.
7. Confirm that loading, empty, and error states each have conditions, messaging, recovery, focus, keyboard, and screen-reader treatment.
8. Confirm that WCAG 2.2 AA, the ADA Title III or Section 508 governance question, 200% zoom, and the 320px no-horizontal-scroll requirement are addressed.
9. Confirm that date, number, currency, and address formats are explicit or marked with slots.
10. Confirm that the work does not drift into implementation code, regulatory conclusions, or unsupported claims, and mark any unresolved claim **[VERIFY]**.