09 — User Behaviour (Library Module)

• 1. The desk clerk needs speed, not romance
• 2. Availability is the first question
• 3. Due dates and fines are anxiety triggers
• 4. Staff override, student observes
• 5. Search fatigue
• 6. The overdue sweep is aspirational
• 7. Mistakes must be reversible or blocked
• 8. Numbers speak plainly
• 9. Identity comes from context
• 10. Concurrency realities (behavioural caution)

Observed/expected behaviour patterns and the design decisions they drive. References the personas in 02_User_Personas.md.

1. The desk clerk needs speed, not romance

• Librarians transact all day: issue → return → next. Every form must open in ≤ 2 taps and prefill aggressively (due date +14 d, student last-used (proposed)).
• Confirmation dialogs allowed only on destructive/irreversible actions (delete, fine pay); issue/return get a single confirm in-form button with spinner (06 S4/S6).
• Resulting rule: write paths are server-confirmed (00-shared/07 §9); the spinner is the confirmation.

2. Availability is the first question

• Students ask "is it in?" before "what is it?". Every catalog row shows AvailabilityBadge (07 §1); Book Detail's primary CTA is Issue, disabled when availableCopies == 0 (library.service.ts:109-111).
• When a copy's availability changes elsewhere (another return), the client re-fetches on focus — no stale "available" claims.

3. Due dates and fines are anxiety triggers

• Active loans show dueDate as the dominant field, with days remaining (S5); overdue gets the red OverdueTag + fine estimate.
• Fine estimates are explicitly labeled "estimate — server computes at return" because the server is authoritative (library.service.ts:211-217) and the client clock may differ.
• Never hide a fine: FineChip renders pending|paid|waived from borrow-record.schema.ts:14-18; absence of chip = on-time return.

4. Staff override, student observes

• fineAmount override (return-book.dto.ts:9-13) is staff-only UI; students/parents see the server value only.
• Pay action (fines.pay, permissions.constants.ts:61) appears only on fineStatus == pending — the server doesn't guard it (OQ-6), so the client does.

5. Search fatigue

• Server search is title/author/ISBN regex (book.repository.ts:26-30) — students type partial strings, so debounce 300 ms and never require exact matches.
• Category/status/availability filters are client-side (OQ-5); chips must not imply server filtering.

6. The overdue sweep is aspirational

• Librarians expect a "who's late" screen. Today that data is client-derived per student (OQ-2); the UI is honest about it with a persistent banner, and the server scan is (planned) (IMPLEMENTATION_PLAN.md:228).

7. Mistakes must be reversible or blocked

• Delete blocked while active loans exist (409, library.service.ts:97-102) — the dialog says why.
• Double-issue prevention: form buttons lock during submit; the server 409s when the cap is hit (library.service.ts:109-111,116-120) — see QA-2/QA-3.
• No undo for issue/return (state is transactional); corrections go through the record's lifecycle (return then re-issue).

8. Numbers speak plainly

• Fines are plain units (rate 5/day, library.service.ts:25); no currency symbol invented — render "20" with label "units" until a currency contract exists (OQ-1 in 01_Product_Overview.md).

9. Identity comes from context

• Borrows are keyed by studentId (borrow-record.schema.ts:25-26); there is no "my borrows" endpoint (OQ-9). The client binds the current student from the Students module state — the borrowed-by-me screens are therefore context-aware, not global.

10. Concurrency realities (behavioural caution)

• Issue/return are read-then-write (library.service.ts:108-139,153-178) — two desks issuing the last copy race. The client can't fix this; it must always re-read on 409 and never retry blindly. (QA-1/QA-3 in 14_QA_Checklist.md.)