02 — User Personas (WS / Realtime Module)
- 1. Org Admin — "the overseer"
- 2. Teacher — "the worker"
- 3. Student — "the consumer"
- 4. Parent / Guardian — "the watcher"
- 5. IT / Operations Admin — "the debugger" (proposed)
- Cross-persona patterns
The realtime layer has no screens of its own (except the proposed debug view, 05). Personas describe who benefits from pushed data on existing screens, and how they perceive the connection. All personas are web clients; native app excluded per PRD (see 01).
1. Org Admin — "the overseer"
| Attribute | Detail |
|---|---|
| Profile | Principal / owner; monitors school-wide operations from the dashboard |
| Realtime needs | Live fee-collection totals, admission pipeline changes, attendance % movement; wants the dashboard to update without refresh |
| Connection context | Desktop web, stable office network; often has the dashboard open for hours |
| Failure tolerance | Low patience for stale numbers — if the socket drops, they expect a visible offline indicator and auto-recovery |
| Priority events | payment.completed, crm.*, attendance.* (dot-namespace per API_STANDARDS.md:642) |
| Quote | "If the number is wrong I reload the page — please just tell me when it's stale." |
2. Teacher — "the worker"
| Attribute | Detail |
|---|---|
| Profile | Takes attendance, posts homework, handles leave requests |
| Realtime needs | New message / announcement toasts while working; live refresh of lists after colleagues submit |
| Connection context | Mixed: school wifi, sometimes a classroom AP with NAT; short sessions between classes |
| Failure tolerance | High for disconnects (they close laptops), low for missed messages — mis-delivery is worse than no delivery |
| Priority events | notification.created, communication.* (planned), leave.* (planned) |
| Quote | "Tell me once, in the corner. Don't make me hunt for it." |
3. Student — "the consumer"
| Attribute | Detail |
|---|---|
| Profile | Receives announcements, homework, results; watches live class/DPP content later (forward-looking) |
| Realtime needs | Instant announcements; homework-published nudge; result-published nudge |
| Connection context | Phone browser on school wifi / mobile data; tab often backgrounded → throttled |
| Failure tolerance | High; background tabs lose the socket — badge must be reconciled via REST on resume |
| Priority events | homework.published, notification.created, examination.* (planned) |
| Quote | "If the app was closed, at least show me the badge when I open it." |
4. Parent / Guardian — "the watcher"
| Profile | Receives fee receipts, attendance alerts, transport status (planned) |
| Realtime needs | Alerts only — no dashboard residency; expects reliability of delivery, not of live updates |
| Priority events | payment.*, attendance.updated alerts, transport.* (planned) |
| Failure tolerance | Lowest of all — an undelivered alert is an incident. REST refetch on resume is mandatory |
5. IT / Operations Admin — "the debugger" (proposed)
| Profile | Owns connectivity: kiosk displays, CCTV-adjacent dashboards, school lab terminals |
| Realtime needs | See connection state, event stream, fan-out correctness — a realtime debug view (proposed) (05 §5) |
| Priority events | Any; wants the event log, not the domain semantics |
Cross-persona patterns
- Passive consumers: nobody sends realtime messages today; the only client→server
traffic is
subscribe/unsubscribe(ws.gateway.ts:63-74). The API must stay this way until the Communication module defines its protocol(planned). - Multi-tab reality: every persona may have 2+ tabs open → one socket per tab; the
server broadcasts to all sockets in the tenant room (
ws.gateway.ts:50,76-78), so clients must deduplicate (see 10_Interaction_Specification.md). - Roles exist on the socket (
client.roles,ws.gateway.ts:17,48) but are not yet enforced for room access — see gap in 12_API_Mapping.md.