# 05 — UI/UX Standards Template-agnostic. Whatever admin template is adopted, these rules govern how it is used so the product reads as one coherent, professional system rather than a patchwork of template demo pages. ## 1. First step for any new template: build the template map Before any feature work, inventory the template's real components into `docs/05a-TEMPLATE-MAP.md`: buttons (primary/secondary/danger/ghost), cards, tables (with sort/filter/pagination), form controls (text, select2, date picker, rich text, file upload), modals, badges/pills, tabs, toasts, charts library available, empty-state pattern, avatar/initials component. **Build only with these primitives.** If something is missing, add it once as a Blade component in `resources/views/components/`, not inline per-page. ## 2. Information architecture - **Two shells**: Staff App (dense, data-first) and Client Portal (calmer, fewer actions, reassuring). Each has its own layout — never reuse the admin shell for the portal. - **Staff sidebar groups** (in this order): Dashboard · Matters · Litigation (Hearings/Roster/Deadlines) · Tasks · Billing & Finance · Documents · Contacts & Clients · Communication · Reports · People (staff/HR) · Settings. - **Global search** in the top bar (matters, clients, documents) — available from every staff page. - **Breadcrumbs** on every page beyond the first sidebar level. ## 3. Page patterns (apply consistently — don't reinvent per module) ### List page ``` [Page title] [+ Primary action] [KPI strip: 3–5 stat cards] [Filter bar: search + 2–4 key filters + date range] [Export ▾] [Data table: sortable columns, row actions menu, pagination, empty state] ``` ### Detail page ``` [Breadcrumb] [Header: entity name/number + status badge + primary actions] [Tabs: Overview | (module-specific) | Documents | Tasks | Billing | Timeline | Comments] [Tab content, each in its own card/section] ``` ### Form (create/edit) ``` [Title] [Cancel] [Save] [Sectioned card groups — not one giant flat form] [Inline validation under each field; old input preserved on error] [Sticky save bar on long forms] ``` ### Modals Used only for: quick confirm (destructive actions), quick-create (e.g. add a client from within a matter form), single-field quick edits. Never a full multi-tab form inside a modal — that's a page. ## 4. Status & feedback conventions - **Badge colors** (consistent everywhere): success/green = Won/Paid/Active/ Attended; warning/amber = OnHold/Pending/Adjourned/Due-soon; danger/red = Overdue/Missed/Rejected/Lost; info/blue = Draft/Scheduled/InReview; neutral/grey = Closed/Archived. - **Toasts** for every create/update/delete (success) and every recoverable error; **inline banners** for page-level warnings (e.g. "3 deadlines overdue on this matter"); **never a raw browser alert()**. - **Empty states** always have: an icon/illustration, one sentence explaining why it's empty, and a primary action if applicable ("No hearings yet — Add the first hearing"). - **Loading states**: skeleton rows for tables, spinner + disabled button with "Saving…" label for form submits — never a frozen UI with no feedback. - **Confirmation** required (modal, typed confirmation for the most destructive: e.g. "type DELETE") for: deleting a matter, deleting a document version, reversing a posted financial entry, disabling a user. ## 5. Data-heavy screen standards - Tables: sticky header on scroll, column sort, saved filter state per user (session), row-level action menu (kebab), bulk-select for eligible bulk actions (e.g. bulk-approve fee claims), CSV/Excel export button matching the current filter. - Dashboards: cards above the fold answer "what needs my attention today," not just vanity totals — every dashboard leads with an **attention/action panel** (overdue, pending approval, missed) before decorative charts. - Calendars: month/week/day toggle, color-coded by type (hearing/deadline/task), click-through to the source record. ## 6. Forms & validation UX - Required fields marked once via label convention (not a sea of red asterisks when everything's required — mark only true optional fields as "(optional)"). - Server validation errors always map to the specific field; a top-of-form summary banner ONLY when there are 4+ errors. - Money fields: right-aligned, thousands separator, ₦ prefix, never raw floats shown to users. - Dates: firm-wide consistent format (`DD Mon YYYY`, e.g. `05 Jul 2026`); relative time on lists ("in 3 days", "2 days overdue") with the absolute date on hover/tooltip. ## 7. Accessibility & responsiveness - WCAG 2.1 AA target: color contrast checked (not color-only status — badges carry text, not just color), all interactive elements keyboard-reachable, form fields properly labelled (`