UX Sitemap & Flows

The information architecture, sitemap, role-scoped navigation, key user journeys, and wireframe briefs for every screen of the Sindh IT Portal — Facilitation Desk (SITP). Covers public site, authenticated workspaces per role, mobile-first/PWA behaviour, RTL/multilingual, and accessibility.

1. Overview & Scope

This document defines what users see, where they go, and how they move through SITP. It is the UX counterpart to the role model in /specs/en/04-roles-permissions/ and the ticket lifecycle in /specs/en/06-ticket-workflow/. It contains:

• UX principles that govern every screen.
• A full sitemap (public site + authenticated areas).
• A page inventory mapping each page to its role(s) and purpose.
• Role-based navigation and landing pages for every role.
• Eight key user journeys rendered as Mermaid flowcharts with written descriptions.
• Nine wireframe briefs (textual layout descriptions, not images) for the key screens.
• Design-system, responsive, and state references.
• A "simple enough" happy-paths recap.

The visual identity (Ajrak palette, typography, components) lives in /specs/en/16-branding-design-system/; this document references it but does not duplicate it.

2. UX Principles

These principles are binding on every screen. They are derived from the locked decisions in _context.md §2, §7 and the usability targets in /specs/en/03-non-functional-reqs/.

2.1 Progressive disclosure

Show only what the current task needs; reveal advanced options on demand. The file-ticket wizard exposes conditional fields one category at a time; the ticket-detail page hides internal notes, audit logs, and oversight actions behind expandable panels unless the role is entitled. Configuration screens reveal secondary controls only after a primary choice is made. This keeps the default view scannable while preserving full power for expert users.

2.2 Three-click rule for the company journey

The primary company journey — from the public home page to a submitted ticket with a tracking ID — must complete in three clicks or fewer for a returning, logged-in rep:

1. Click 1: "File a ticket" (home hero or top utility bar).
2. Click 2: "Submit" in the file-ticket wizard (category, details, attach).
3. Click 3: "View ticket" from the confirmation screen.

First-time registration is a separate, longer flow (§6.1), but the filing step itself stays within three clicks once authenticated. Track ID lookup from the home page is a single action (one click + one paste). Navigation depth anywhere in the authenticated area must not exceed three levels before the user reaches a working surface (dashboard, ticket, or form).

2.3 Role-scoped landing and navigation

Every account lands on a dashboard scoped to its role and sees only the navigation its capabilities permit (see /specs/en/04-roles-permissions/ §16). A Filer never sees staff-management screens; a Viewer never sees configuration; an Officer never sees Officials CMS. Navigation is generated declaratively from the capabilities the user actually holds after per-user overrides and ABAC gates, so a granted override surfaces its nav entry immediately and a revoked capability disappears.

2.4 Mobile-first and PWA

SITP is built mobile-first as a Progressive Web App (PWA): installable, offline-capable for drafts and read-only ticket views, and the primary channel for many company reps and field officers. Touch targets are at least 44×44 px. Layouts are designed for the smallest active viewport first and progressively enhance at larger breakpoints (§9). The future React Native (Expo) mobile app reuses the same API contract and navigation model.

2.5 Accessibility — WCAG 2.1 AA

All screens meet WCAG 2.1 AA across English, Urdu, and Sindhi (see _context.md §2 and /specs/en/09-i18n-localization/). Concretely: semantic landmarks, skip-to-content links, full keyboard operability with visible focus, colour-contrast ratios at AA minimums, no colour-only meaning, ARIA where native semantics are insufficient, accessible names on all interactive elements, and a data-table alternative for every chart. Motion respects prefers-reduced-motion. A user-selectable high-contrast mode and font-size control are exposed in the top utility bar.

2.6 Right-to-left (RTL) and multilingual

Urdu and Sindhi render right-to-left. Direction is driven by the Docusaurus/Next.js locale; no inline direction hacks. Layouts are mirror-symmetric: side rails swap sides, icon arrows reverse, the AI chatbot launcher moves to the bottom-left in RTL. All copy uses the approved glossary terms (_glossary.md). A language switcher is always visible in the top utility bar and persists per user.

2.7 Dual calendar

Every date displayed to a user shows both Gregorian and Islamic (Hijri) forms (gov convention; _context.md §2). Date pickers default to Gregorian input with a Hijri companion; SLA chips show business-day counts.

2.8 Trust, transparency, and the "single window" promise

The interface constantly reinforces that SITP is the single window owned by S&ITD: the operator line ("Operated by MAAHIR · Powered by Server4Sale") appears in the footer; the public transparency dashboard is one click from the home page; tracking IDs are meaningful (SITP-YYYY-<DEPT>-<NNNNNN>); and resolution proof is visible to the filer. Empty and error states are honest and recoverable (§10).

3. Information Architecture (Sitemap)

3.1 Public site (module A — PUB)

The public site is the marketing, onboarding, and self-service layer. It is fully indexable (SEO, hreflang for EN/UR/SD) and requires no login except where noted.

3.2 Authenticated areas (modules B, C, I, M, Q)

After login, the user is routed to a role-scoped landing dashboard. Shared elements: top utility bar (language, notifications, preferences, profile, 2FA status), in-app messaging (module F), notification centre (module G), and a global ticket/rep search.

3.3 Sitemap diagram

Written description. The sitemap has two top-level branches under the portal root: the public site (no login) and the authenticated area. The public site hosts informational pages (Home, About, Departments, Services, How it works), the main entry points (Register/Login, File a complaint, Track a ticket), the self-service content (Knowledge Base, News, Officials, Transparency Dashboard, RTI info, Contact), and the special whistleblower intake. Register/Login and File a complaint both lead into the authenticated area, which fans out into per-role workspaces: Company, S&ITD facilitation, Officer, Department admin, Oversight dashboards, Audit explorer, Platform admin console, and Citizen. The whistleblower intake bypasses login and routes to a token-based anonymous status viewer. The AI chatbot overlay is reachable from both the public site and the authenticated area.

4. Page Inventory

Each page mapped to the role(s) that can reach it and its purpose. Role codes follow /specs/en/04-roles-permissions/ §8 (SA = Super Admin, DA = Department Admin, OF = Officer, DG = DG, SEC = Secretary, MIN = Minister, FO = S&ITD Facilitation Officer, PR = Primary Rep, AR = Admin Rep, FI = Filer, VI = Viewer, CT = Citizen, AN = Anonymous, AU = Read-only Auditor). Public = no login.

4.1 Public pages

4.2 Authenticated pages

5. Role-Based Navigation and Landing

The role determines the landing dashboard and the primary navigation. The summary below extends /specs/en/04-roles-permissions/ §16 with concrete nav items. Navigation is generated from the user's effective capabilities (after overrides and ABAC), so the lists below are the defaults for each template.

Supplementary roles (not in the nine required above but present in the system):

6. Key User Journeys

Eight journeys are rendered as Mermaid flowcharts, each followed by a written description. They map directly to the workflow rules in /specs/en/06-ticket-workflow/ and the roles in /specs/en/04-roles-permissions/.

6.1 Journey 1 — Company registers and files first ticket

Written description. A company visitor lands on the public home page and chooses to register. The registration form is dynamic: the chosen entity type (SECP company, sole proprietor, freelancer, foreign branch, or early startup) drives which fields and verification sources appear. Naming a Primary Authorized Representative (with CNIC and domain email) is mandatory and cannot be skipped. On submission the account is created instantly in a Provisional state — this is the file-first model — and background verification runs in parallel against SECP, FBR, SRB, PSEB, and NADRA. After verifying 2FA/email, the rep lands in the company workspace and opens the file-ticket wizard. The wizard's first step offers an AI-suggested category, destination department, and similar-ticket deflection; selecting a category dynamically renders the conditional fields for that category (e.g. unpaid-dues fields differ from SECP name-conflict fields). After attachments are AV-scanned and encrypted, the rep reviews the entry (with an option to save a draft), submits, and a tracking ID is atomically allocated in the SITP-YYYY-<DEPT>-<NNNNNN> format. The ticket enters New, a multilingual confirmation is sent, and the parallel background checks eventually grant a Verified badge (or hold the account for appeal if they fail).

6.2 Journey 2 — Officer triages and resolves with AI assist + proof gate

Written description. A newly filed ticket lands in the S&ITD triage inbox, where the facilitator is supported by AI: an auto-summary, a category confirmation, an urgency/sentiment hint, and a draft routing suggestion. The facilitator confirms or overrides category, priority, SLA, destination department/section, and the sensitivity/VIP flag, moving the ticket to Triaged and into the destination department's section queue. A section head or the AI auto-router assigns an officer, pushing the ticket to Assigned. In the officer workspace, AI again assists — drafting a reply, suggesting a relevant KB article, and redacting PII from free text. The officer sends the first substantive response, satisfying FRT and flipping the ticket to In Progress. Work alternates between In Progress and Awaiting Parties as the company supplies information (each pause/resume stops and starts the SLA clock). When the officer marks the ticket ready to resolve, the proof gate checks for at least one evidence attachment and a resolution note; if missing, the action is blocked and the ticket returns to the work cycle. For sensitive or VIP tickets the resolution package additionally routes to the Chair/DG approval queue. With the gate cleared, the ticket becomes Resolved and the CSAT window opens for company accept, reopen, or auto-close.

6.3 Journey 3 — Escalation to DG / Secretary

Written description. When a ticket's resolution SLA breaches, the SLA engine flips the ticket to Escalated while preserving the underlying working state (so officer context is never lost). At Tier 1 (two unresolved business days after breach), the department's DG/Director is notified and added as a watcher; if the department has configured DG action powers, the DG may reassign, override the SLA, force-resolve, or issue a directive. If the ticket remains unresolved for five more business days, Tier 2 pulls in the Department Secretary — with the same optional action powers, plus WhatsApp-channel notifications. After ten more unresolved business days, Tier 3 notifies the SACM (S&IT) and the S&ITD Secretary, accompanied by a formal directive letter; the Minister's directive power is on by default at this tier. Any directive or action from an empowered oversight tier de-escalates the ticket back to In Progress, where the officer resumes and ultimately resolves it through the proof gate. All escalation events, overrides, and directives are audit-logged. The 2/5/10-day ladder is configurable per department and category (see /specs/en/06-ticket-workflow/ §6).

6.4 Journey 4 — TRI meeting + MoM upload and share

Written description. When a ticket stalls or sits at escalation tier 2 or higher without movement, any of the company, the officer, the facilitator, or the auto-trigger can request a TRI (Tripartite Review) meeting. The request parks the ticket in On Hold (pausing the SLA clock) and the AI auto-drafts an agenda from the ticket's full history and uploads, which the facilitator reviews and edits. The modality — physical, virtual (Zoom/Meet/Teams), or hybrid — is chosen per meeting, multilingual invites go out, and recording consent is captured. After the three-party meeting, the facilitator records the outcome. For a resolved or partial outcome, the responsible officer uploads the MoM in the department's own format; the file is ClamAV-scanned, encrypted, and stored. Scanned documents run through the pluggable multilingual OCR engine (English, Urdu/Nastaliq, Sindhi/Naskh), and the AI extracts a summary, structured action items with owners and due dates, decisions, and attendees, plus machine translations. The officer reviews the extraction side-by-side with the original and confirms; confirmed action items become sub-tasks on the ticket. For normal tickets the officer publishes directly; for sensitive or VIP tickets the MoM must first pass Chair/DG approval. On publish, the MoM is versioned and permanently attached, auto-shared to all participants across email, in-app, and SMS/WhatsApp per their preferences (with acknowledgments tracked and reminded), and cross-posted to NITB e-Office where enabled. If the meeting cannot resolve the issue, the ticket escalates to the next tier with the meeting record attached.

6.5 Journey 5 — Company appeals

Written description. From a Resolved or Closed ticket, the company has the CPGRAMS-style appeal path inside its window (default 30 calendar days from closure). A poor CSAT rating (at or below the configured threshold) automatically enables and pre-fills the appeal form and extends the window by a grace period (default +15 days); the company can also file a manual appeal. The appeal routes to the next oversight tier above the one that closed the ticket — a ticket closed at working level goes to the DG; one closed under DG purview goes to the Secretary; one closed under Secretary purview goes to the SACM and S&ITD Secretary. The reviewing authority may uphold (the ticket returns to In Progress with a directive to the section), partially uphold (specific action items become sub-tasks and the ticket returns to In Progress for those items only), re-route (the ticket moves to Triaged for a different section or department), or reject (closure becomes final and a QR-verified rejection letter is generated and sent). Every decision is audited with actor, tier, reasoning, and resulting action.

6.6 Journey 6 — Secretary oversight dashboard

Written description. A Department Secretary (or DG, or Minister) logs in and lands on the oversight dashboard scoped to their department (cross-department for the SACM). The dashboard surfaces department KPIs (open, breached, near-breach, escalated counts), an escalation-tier view separating the DG, Secretary, and Minister queues, a GIS/district heatmap of resolution performance, and a repeat-offender list flagging officers or sections with recurring escalations. The Secretary drills from any KPI, tier, or offender into the underlying ticket detail. Whether the Secretary can then act depends on the department's configured oversight powers: with action powers ON, the Secretary may send a directive, override the SLA, force-resolve, reassign, or approve sensitive/VIP closure; in notify-only mode the Secretary is limited to commenting, watching, and receiving alerts. Every action requires a reason and writes an immutable audit event.

6.7 Journey 7 — Anonymous / whistleblower intake

Written description. A whistleblower reaches the anonymous intake channel from the public site without logging in. They pick a topic (corruption, harassment, safety, other), provide details, and may optionally include an encrypted contact method. CAPTCHA, rate-limiting, and an abuse filter protect the channel. On submission a one-way token is generated and the reporter's identity is not stored in cleartext; the resulting ticket is restricted-visibility, visible only to the designated S&ITD whistleblower-handling role and, optionally, the S&ITD Secretary. The reporter uses their token to check status read-only, with no login. Standard SLA and escalation apply, but all oversight notifications omit filer-identifying information. If the reporter opted in to the encrypted contact, it is used only for follow-up. Retention follows the whistleblower policy in /specs/en/24-trust-safety/.

6.8 Journey 8 — Admin configures department / SLA / AI

Written description. A Super Admin (or Department Admin, within their scope) opens the admin console and completes step-up authentication for configuration actions. From there they branch into the configuration surface they need. Department configuration creates or edits departments and freely nestable sub-departments. SLA configuration edits the sla_definitions rows binding FRT and resolution targets per department/category/priority. Escalation configuration edits the escalation_ladders tiers and triggers and the oversight_powers matrix that toggles each oversight role between notify-only and action. AI engines configuration selects the pluggable LLM (cloud vs self-hosted) and the OCR engine, with a test-connection control. Feature flags toggle any capability per department or environment, with two-person approval required for sensitive global flags (such as disabling the proof gate). Every configuration change is audit-logged with the old value, new value, actor, and a mandatory change-reason, and the change propagates immediately to navigation, dashboards, generated letters, the Officials CMS, and live ticket behaviour.

7. Wireframe Briefs (Key Screens)

Nine textual layout briefs — region-by-region descriptions, not images. They describe the default desktop layout; mobile adaptations are noted where material and follow §9. Visual treatment (colours, type, components) is defined in /specs/en/16-branding-design-system/.

7.1 Home / public landing

• Top utility bar (sticky). Language switcher (EN/UR/SD), Login, Register, "File a complaint" primary CTA, accessibility controls (font size, high contrast), dual-calendar indicator.
• Header. Government of Sindh seal + S&ITD logo (co-primary marks), site wordmark, primary nav (Home, Departments, Services, How it works, Knowledge Base, Transparency, Contact); collapses to a hamburger below the md breakpoint.
• Hero. Tagline (English master), primary CTA "Register your company", secondary CTA "File without registering (Citizen)", and a single-field tracking-ID lookup. Ajrak-motif background respecting prefers-reduced-motion.
• Quick-actions row. Four cards: File a ticket, Track a ticket, RTI request, Whistleblower.
• Live transparency strip. Counters from the public dashboard: tickets resolved, average resolution time, departments onboarded.
• Featured officials. Minister/Secretary/DG cards from the Officials CMS (module P) with photos, names, and effective dates.
• News / announcements carousel. Latest circulars and announcements (module N).
• AI chatbot launcher. Floating, bottom-right (bottom-left in RTL); collapses to a button.
• Footer. "Operated by MAAHIR · Powered by Server4Sale", dual-calendar note, links (RTI, Privacy, Terms, Accessibility statement, Contact), language repeat.

7.2 File-ticket wizard (dynamic conditional fields)

A five-step wizard with a sticky stepper header and a contextual AI rail.

• Stepper header (sticky). 1 Category → 2 Details → 3 Attach → 4 Review → 5 Submit, with a progress bar. On mobile it collapses to "Step X of 5".
• Right rail — AI assist (collapsible). Suggested category and destination department, similar-ticket deflection card ("SITP-2026-LBR-000098 may already answer this"), urgency/sentiment hint. Becomes a bottom drawer on mobile.
• Step 1 — Category. Searchable category selector; AI suggestion auto-fills; destination department preview; "File as RTI?" toggle (adds a statutory-SLA note).
• Step 2 — Details (dynamic). Conditional fields driven by intake_form_schema for the chosen category. Example: Labour — Unpaid dues shows last salary date, amount, employee count, employer NTN; SECP — Name reservation conflict shows proposed name, reservation number, rejection letter. Mandatory indicators, inline validation, RTL-aware, character counters.
• Step 3 — Attach. Drag-and-drop multi-file; allowed types per evidence_schema; per-file AV-scan status; encryption badge; PII-redaction notice on free text.
• Step 4 — Review. Full summary of entered data and attachments, editable inline; "Save draft" (save-later, 30-day retention); preview of the tracking-ID format.
• Step 5 — Submit. Confirmation with the allocated tracking ID prominent (copy/share), next-steps, language-specific confirmation message, and a "View ticket" deep link.

7.3 Ticket detail

• Header band. Tracking ID (large, monospaced), colour-coded status badge, priority, category, routed department/section, SLA countdown chips (FRT + resolution, with paused indicator), sensitivity/VIP flags, dual-calendar timestamps.
• Main column (≈70%).
  • Conversation timeline. Public thread: company messages, officer responses, and status transitions with dual-calendar timestamps. Internal notes are visually distinct (locked icon) and visible only to government roles.
  • Composer. Rich text, attachments, "AI draft reply", internal-note toggle, pause-SLA toggle, "Request TRI".
  • Sub-tasks (expandable), linked/related tickets, MoM attachments (version + ack status), TRI meetings list.
• Right rail (≈30%).
  • Ticket meta card. Assignee, watchers/CC (add/remove), created, last update, intake channel.
  • SLA card. FRT and resolution elapsed/target, pause history, business-hours note.
  • AI card. Summary, urgency, suggested KB article, similar tickets.
  • Actions card (role-scoped). Resolve (triggers proof gate), Reopen, Withdraw, Appeal, Force-resolve (oversight), Approve (Chair/DG), Send directive, Generate letter, e-Sign.
  • Audit/timeline summary (expandable to full history).
• Proof-gate modal. When Resolve is clicked without evidence + note, the modal explains the blockers. For sensitive/VIP it routes the package to the Chair/DG approval queue.

7.4 Officer workspace

• Top bar. Officer name, department/section, certification badge (per /specs/en/20-training-certification/), online/shift status.
• Left nav (role-scoped). My Queue, Sub-tasks, Drafts, TRI, MoM Upload, KB, Analytics, Messages.
• Main — My Queue. Filterable/sortable table (ID, subject, priority, SLA chip, status, last update); bulk-select bar; saved filters; near-breach rows highlighted. Toggle to Kanban view (columns by status: Assigned, In Progress, Awaiting Parties, Escalated, Resolved).
• AI assist dock. Collapsible right drawer: summarization, draft replies, similar-ticket suggestions.
• Inline actions. Open ticket detail (slide-over or full page), quick-respond, pause SLA.

7.5 Oversight dashboard (DG / Secretary / Minister)

• Top KPI row. Open, Breached, Near-breach, Escalated (tier-badged), Average resolution, CSAT.
• Escalation tier columns. Tier 1 (DG), Tier 2 (Secretary), Tier 3 (Minister) — ticket counts with drill-down lists.
• SLA breach heatmap (GIS/district) and department-comparison bars.
• Repeat-offender list. Officers/sections with recurring escalations.
• Directives log (sent by this oversight role) and a "Send directive" composer (step-up auth required).
• Action rail. If action powers are ON for the department: reassign, override SLA, force-resolve, approve sensitive/VIP closure. If notify-only: read + comment.
• Filters and export. Time period, department; export to PDF/Excel/CSV.
• Mobile. Cards stack; KPIs in a scrollable row; tier columns become tabs.

7.6 TRI meeting page

• Header. Parent-ticket link, meeting status (scheduled / in-progress / complete), modality badge (Physical / Virtual / Hybrid), date/time in dual calendar.
• Three-party panel. Company reps, S&ITD facilitator (chair), Department officer/section head — each a card listing attendees, RSVP, and (for virtual) the Zoom/Meet/Teams join link.
• Agenda section. AI-drafted and editable; discussion items, decision points, ordering.
• Recording consent capture (per participant) before start.
• During meeting (virtual). Embedded video iframe plus side chat.
• Outcome selector. Resolved / Action items / Escalate.
• MoM upload zone. Drag-and-drop (PDF/Word/images); AV-scan status; "Upload" triggers the MoM flow (§6.4).
• Post-meeting. Action-items table (owner, due date, priority) → "Confirm → create sub-tasks".

7.7 MoM viewer

• Header. MoM title, parent-ticket link, version selector, language switch (EN/UR/SD), published date (dual calendar), approval badge (for sensitive tickets).
• Split view. Left = original document preview (PDF/image with an OCR-text-layer toggle); right = AI-extracted structured data (summary, action-items table, decisions, attendees).
• Action-items table. Editable rows (owner, due date, priority) → "Confirm as sub-tasks".
• Acknowledgment panel. Per-participant ack status (opened / downloaded / acked) with a "Send reminder" action after the grace period.
• Controls. Secure-download link, share buttons, version history, audit trail.
• e-Office indicator. Cross-post status to NITB e-Office where enabled.

7.8 Analytics

• Filter bar. Date range (dual calendar), department, category, priority, district.
• KPI cards row. Total filed, resolved, average FRT, average resolution, CSAT, deflection rate.
• Charts. Trend lines (filed vs resolved), SLA-breach trend, category distribution, department-performance bars, GIS district heatmap, escalation-tier distribution. Metabase-embedded panels (configurable) plus custom ECharts/Recharts.
• Export bar. PDF/Excel/CSV; subscribe to a scheduled digest.
• Accessibility. Every chart has a data-table alternative and ARIA labels; colour-blind-safe palette; full keyboard navigation. Role scoping follows /specs/en/17-analytics-kpis/.

7.9 Admin feature-flags

• Step-up-auth banner on entry (config actions require fresh 2FA).
• Left nav. Departments, Officials CMS, Integrations, AI Engines, Feature Flags, Comms (SMTP/SMS/WhatsApp), Holiday Calendar, Audit Logs.
• Feature-flags table. Capability (grouped by module A–Q), status toggle (on/off), scope (global / per-department / per-env), last-changed-by, audit link; search and filter; two-person-approval indicator for sensitive flags.
• Change drawer. Old value, new value, mandatory change-reason field, effective date; "Save" writes an audit event.
• Department tree editor. Nestable nodes (drag-and-drop), SLA row per node, escalation-ladder editor, oversight-powers matrix per tier.
• AI-engines panel. Cloud vs self-hosted toggle, OCR-engine select, test-connection button.

8. Design-System Reference

All visual treatment — palette, typography, iconography, components — is defined in /specs/en/16-branding-design-system/. This document consumes it; the key touchpoints are:

• Palette. Ajrak-inspired indigo / maroon / black with Ajrak-motif accents; Sindhi-cap iconography. Status colours are consistent (e.g. green = resolved, amber = near-breach, red = breached) and never carry meaning by colour alone.
• Typography. English: Inter/Poppins; Urdu: Noto Nastaliq Urdu; Sindhi: Noto Naskh Arabic. Line-height and metrics tuned per script for RTL.
• Components. shadcn/ui primitives (buttons, dialogs, tables, tabs, toasts) themed to the palette; custom components for SLA chips, tracking-ID display, and dual-calendar dates.
• Ticket ID display. Meaningful SITP-YYYY-<DEPT>-<NNNNNN> rendered in a monospaced badge, copyable.
• Branding marks. Government of Sindh seal + S&ITD logo as co-primary marks; "Operated by MAAHIR · Powered by Server4Sale" in every footer.
• Accessibility. AA contrast, visible focus, reduced-motion support, high-contrast mode toggle.

9. Responsive Breakpoints

SITP is built mobile-first. Breakpoints follow the Tailwind defaults used across the stack (see /specs/en/15-tech-architecture/):

PWA behaviour. Installable to home screen; offline support for read-only ticket views and draft composition (queued submission on reconnect); push notifications via the web where supported. Touch targets are at least 44×44 px. The future React Native app reuses the same navigation model and API contract.

10. Empty / Loading / Error States

Every list, dashboard, and form defines all three states explicitly. States are honest, recoverable, and on-brand.

10.1 Empty states

• Illustration + guidance + primary CTA. Example: an officer's empty My Queue shows "No tickets assigned yet" with a link to the department queue and KB.
• Onboarding nudges for first-time users (company workspace with no tickets → "File your first ticket"; oversight dashboard with no escalations → "All clear").
• No-results states for search/filter distinguish "nothing matches your filter" from "no data exists yet".

10.2 Loading states

• Skeleton screens that match the final layout (not generic spinners) for tables, cards, and dashboards.
• Optimistic UI where safe (e.g. comment posting); rollback on failure with a clear message.
• SLA chips show "calculating…" on first render; partial data renders progressively rather than blocking the whole page.
• Inline progress for long operations (file upload with AV scan, OCR, AI extraction) with a determinate bar where possible.

10.3 Error states

• Friendly message + error/reference ID for support, plus a retry action.
• Graceful degradation: if analytics is down, the rest of the workspace works; if a video provider fails, the TRI page offers the alternative provider; the AI chatbot degrades to a search-only fallback.
• Branded error pages for 401/403/404/500, all RTL-aware and WCAG-compliant, with a path back to home or to support.
• Network/offline banner in the PWA with a queued-actions indicator and a reconnect trigger.

11. "Simple Enough" Happy Paths Recap

The eight journeys above are rich, but each role's happy path — the path the system optimises for — is deliberately short. These are the experiences the 3-click rule (§2.2) protects.

The rule of thumb: if the happy path needs a help article, the design is not simple enough yet.

12. Cross-References

• Roles, permissions, and the role→UI mapping summary: /specs/en/04-roles-permissions/ §16.
• Ticket lifecycle, SLA, escalation, proof gate, TRI, MoM, appeal: /specs/en/06-ticket-workflow/.
• Visual identity, palette, typography, components: /specs/en/16-branding-design-system/.
• Analytics dashboards, KPI families, public transparency dashboard: /specs/en/17-analytics-kpis/.
• MoM upload-first and TRI detail: /specs/en/21-mom-meetings/.
• Trilingual, RTL, WCAG 2.1 AA, dual calendar: /specs/en/09-i18n-localization/.
• Functional and non-functional requirements: /specs/en/02-functional-reqs/, /specs/en/03-non-functional-reqs/.
• Multi-channel intake (email/SMS/WhatsApp/IVR/walk-in): /specs/en/19-multichannel-intake/.
• Trust & safety, whistleblower policy: /specs/en/24-trust-safety/.

End of document.