Design an attendance app for a tutoring academy with parent notifications

## Role and objective

You are a product-interface designer creating a tutoring academy attendance app for academy staff, tutors, and parents. Produce a Figma-ready interface specification for [FILL IN: web, iOS, Android, or responsive app] that covers attendance recording and parent notifications without inventing operational details.

The deliverable must define the screen list, components, interaction states, visual system, and auto-layout behaviour in words so the design can be implemented consistently. Completion means that a reviewer can identify how a tutor records attendance, how academy staff monitors it, how a parent receives or views a notification, and what happens in loading, empty, and error states.

## Scope and given facts

In scope:

- An attendance app for a tutoring academy.
- Attendance-related workflows for academy staff and tutors.
- Parent notifications connected to attendance events.
- Screens, components, states, interactions, accessibility requirements, and layout rules.
- A design specification suitable for implementation in Figma.

Out of scope unless confirmed: payment, grading, lesson planning, messaging unrelated to attendance, student enrollment, staff payroll, analytics beyond attendance, and backend implementation.

Confirmed facts are limited to the tutoring-academy setting, attendance purpose, and parent-notification requirement. Use these unresolved slots:

- Platform: [FILL IN: web, iOS, Android, or responsive app]. Fill this with the intended deployment platform.
- Roles and permissions: [FILL IN: user roles and allowed actions]. Fill this with the academy’s confirmed role model.
- Notification channels: [FILL IN: push, SMS, email, or other channels]. Fill this with approved delivery channels.
- Trigger events: [FILL IN: attendance events that notify parents]. Fill this with the academy’s confirmed notification policy.
- Student data fields: [FILL IN: fields shown in the interface]. Fill this with the minimum approved data set.
- Brand system: [FILL IN: logo, colours, typefaces, and visual references]. Fill this with supplied brand assets.

Do not fill the attendance-app platform, role permissions, notification channels, trigger events, student data fields, or brand system with plausible guesses.

## Working rules

Apply UI-design rules to every proposed screen.

1. Preserve any supplied brand description as `brandAnchor`; if none is supplied, keep branding as `[FILL IN: brandAnchor]` rather than creating a logo, colour palette, or typeface.
2. Treat attendance as the primary task. Each attendance action must have a visible status, a clear confirmation state, and a recoverable correction path.
3. Separate user roles. If a role or permission is unconfirmed, display `[FILL IN: permission rule]` and do not imply that parents can edit attendance or that tutors can access academy-wide records.
4. Branch notification behaviour by confirmed trigger:
   - If a trigger event is supplied, show its notification status, delivery channel, timestamp, and failure or retry state.
   - If no trigger event is supplied, show the notification area as a configurable design slot and label the missing policy.
5. Cover loading, empty, success, error, offline or unavailable, and permission-denied states wherever the relevant action exists. Error states must explain the next safe action without claiming that a notification was sent when delivery is unconfirmed.
6. Require keyboard operation for all interactive controls and meaningful screen-reader labels for navigation, student identity, attendance status, notification status, dialogs, and validation messages.
7. Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience; leave the answer as `[FILL IN: governing accessibility regime]`.
8. Make every layout survive 200% zoom and a 320px viewport with no horizontal scrolling. At narrow widths, stack controls or move secondary information below the primary task.
9. State date, number, currency, and address formats explicitly where they appear. If a format is not needed, do not add a field merely to satisfy this rule.
10. Use only facts supplied by the user or clearly marked slots. Do not make performance, delivery, compliance, or notification-reliability claims.

## Output structure

Produce the design specification in this order:

1. **Screen list** — Name each screen and state its user, purpose, entry point, and exit path. Include only screens needed for attendance and parent notifications. Allocate approximately 10–15% of the output to this list.
2. **Components per screen** — For each screen, list navigation, headers, filters, student rows or cards, attendance controls, notification indicators, actions, dialogs, and validation messages. State which items are reusable. Allocate approximately 35%.
3. **Behaviour per state** — For every major component, describe default, loading, empty, success, error, unavailable, and permission-denied behaviour where applicable. Include the result of recording attendance and the notification handoff. Allocate approximately 30%.
4. **Design tokens** — Define colour, type, spacing, radius, borders, elevation, icon treatment, and responsive breakpoints as confirmed values or `[FILL IN: token value]` slots. Include semantic states for present, absent, late, excused, pending, sent, failed, and unknown only where those statuses are confirmed or explicitly marked as proposed. Allocate approximately 15%.
5. **Auto-layout specification** — For every screen and reusable component, state the frame hierarchy, layout direction, alignment, spacing, padding, min/max dimensions, fill or hug behaviour, and resizing rules in words. State how the layout changes at 320px and 200% zoom. Allocate approximately 10%.

Do not provide implementation code or invent populated student records, dates, notification contents, or operational metrics.

## Style rules

Use a hybrid style. Use itemized, compact language for screen lists, component inventories, tokens, states, and auto-layout properties. Use short narrative paragraphs only to explain the primary attendance-to-parent-notification flow and key branching behaviour. Keep the register professional, calm, and suitable for an education setting. Avoid vague product clichés such as “seamless,” “best-in-class,” “revolutionary,” “effortless,” and “one-stop solution.” Describe observable interface behaviour instead.

## 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 design is specifically for a tutoring academy attendance app, not a generic school-management product.
2. Confirm that parent notifications appear in the screen list, component definitions, state behaviour, and primary user flow.
3. Confirm that the deliverable contains screen list, components per screen, behaviour per state, and design tokens in that order.
4. Confirm that every screen and reusable component includes frame hierarchy, direction, alignment, spacing, and resizing rules.
5. Confirm that loading, empty, error, permission-denied, and relevant success states are covered.
6. Confirm that keyboard operation, screen-reader labels, WCAG 2.2 AA, 200% zoom, and 320px no-horizontal-scroll behaviour are addressed.
7. Check that no platform, role permission, notification channel, trigger event, brand asset, student field, date, or status policy was added beyond the input.
8. Check that the slots for the platform, roles, notification channels, trigger events, student data, brand system, and governing accessibility regime remain unfilled unless explicitly provided.
9. Check that no screen or feature drifts into payments, grading, unrelated messaging, enrollment, payroll, or unrequested analytics.
10. Check that no notification is described as delivered, read, or successful unless its status is supplied or clearly represented as a proposed state.
11. Confirm that proposed semantic statuses are labelled as proposals when the input does not confirm them.
12. Confirm that the final specification is implementable as a Figma design description without requiring invented content.