Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

09 — User Behaviour (Biometric Module)

Observed-behaviour patterns that drive the interaction design of the Biometric console. Derived from personas (02) and journeys (03); backend facts cited where behaviour is bounded by server reality.

1. Morning-gate burst (persona Riya, Arjun)

  • Pattern: 07:30-09:00 the clerk is at the device, the ops manager is on the hub; both act in < 30 s windows between arrivals.
  • Design consequence: hub must render health before interaction (no pull-to-refresh as the only path); sync status must be glanceable (SyncStatusTile, 07 §2); enroll flow ≤ 3 taps (persona Arjun).
  • Server bound: sync cadence is */15 * * * * (scheduler.service.ts:70-76) — the UI must never imply real-time; "next sync in ~12 min" copy is honest.

2. Trust the machine until it isn't (dispute behaviour)

  • Pattern: teachers/parents accept biometric-derived attendance silently; the moment one mismatch appears, the whole pipeline is questioned.
  • Design consequence: verify check-in screen (06 §8) is evidence-first: raw punch timeline above the derived verdict; "mismatch" state must say where it broke (punch exists, derivation missing), not a generic error.
  • Server bound: logs are immutable (biometric-log.schema.ts:7, blueprint COLLECTIONS.md:1866) — the UI can promise "records can't be edited here" truthfully.

3. Sync anxiety (IT admin Dev)

  • Pattern: Dev checks the queue before checking devices; failure means "did I lose data?".
  • Design consequence: retry semantics surfaced verbatim — "4 retries, exponential 2000 ms, then dead-letter" (blueprint RETRIES.md:38, Biometric.md:58); a "Sync now" escape hatch per device (POST /biometric/devices/:id/sync, blueprint :28).
  • Server bound: today the worker is missing (OQ-4) — until then, any sync UI reads "0 processed" and breeds distrust; ship sync UI only with the worker.

4. Permission-scoped curiosity (Meera, parents)

  • Pattern: teachers peek at biometric screens only to settle "who was in"; parents never do.
  • Design consequence: no biometric navigation for non-biometric.* roles (permissions.constants.ts:41-43); teachers get derived attendance via their existing attendance endpoints (attendance.controller.ts:31-35). Keep module boundary clean (AGENTS.md: module boundaries, no cross-module service calls).

5. Evidence retention for disputes

  • Pattern: disputes surface days later; clerks need the original punch, not a summary.
  • Design consequence: log detail shows absolute + relative timestamp, deviceId, mode, raw payload (biometric-log.schema.ts:12-22); retention bound 1 year visible (blueprint DATA_RETENTION.md:25) so "why is April gone?" never surprises.

6. Offline-device drift

  • Pattern: an offline device is ignored for days unless flagged; then a burst of manual re-entry.
  • Design consequence: offline is a banner on the hub (not a badge); the device detail suggests "Sync now" + notes punches arrive with original timestamps (COLLECTIONS.md:1883) so the catch-up is data-correct.
  • Server bound: DeviceStatus.OFFLINE exists (biometric-device.schema.ts:10) but nothing sets it today (no health-check implementation, blueprint Biometric.md:19) — flag in QA (14 §7).

7. Behaviour invariants (module)

  1. Every verdict is backed by at least one visible raw punch — no "trust us" UI.
  2. Every destructive action (disable device, overwrite enrollment) has a confirm dialog.
  3. No screen pretends the pipeline is real-time; sync copy always references the 15-min cadence.
  4. Biometric data never appears on student/parent-facing surfaces (privacy, 14 §8).