118 lines
12 KiB
Markdown
118 lines
12 KiB
Markdown
# MobilityOps current UX audit
|
||
|
||
Date: 2026-08-02
|
||
Audited revision: `dfabb41582e302f45a3de826f85f531bf23dfc8b`
|
||
Live URL: `http://192.168.10.150:1236`
|
||
Role used: Operations Manager, deterministic synthetic seed
|
||
|
||
## Executive finding
|
||
|
||
The current product is functionally complete and unusually honest for a proof of concept,
|
||
but its interface is a thin functional shell. It exposes the right workflows without yet
|
||
providing the information architecture, hierarchy, interaction safeguards, or responsive
|
||
behaviour expected of premium operational software. The redesign should preserve the
|
||
backend and every working route while replacing the horizontal demo navigation, repeated
|
||
card/table grammar, and developer-facing status language with a calm operational control
|
||
centre built around decisions, readiness, evidence, and traceable outcomes.
|
||
|
||
No critical functional blocker was found. The highest-priority design problems are the
|
||
mobile navigation model, loss of table context on small screens, weak decision hierarchy
|
||
on the dashboard, and insufficient guidance before consequential actions.
|
||
|
||
## Audit method and evidence
|
||
|
||
The deployed application was inspected in Chrome with explicit viewport overrides and a
|
||
fresh deterministic demo reset. DOM landmarks, interactive controls, horizontal overflow,
|
||
console output, and visible state were inspected alongside screenshots.
|
||
|
||
| Viewport | Coverage | Result |
|
||
|---|---|---|
|
||
| 1440 × 1000 | Login and every major route/detail/workflow | No page overflow; hierarchy and density issues documented below |
|
||
| 1280 × 800 | Dashboard, fleet, return, duplicate review | No page overflow; important sections regularly fall below the fold |
|
||
| 768 × 1024 | Dashboard, fleet, return, duplicate review | Header consumes excessive vertical space; tables lose desktop rhythm |
|
||
| 390 × 844 | Login, dashboard, fleet, return, duplicate review, knowledge | No document overflow, but navigation wraps into a dense block and table labels disappear |
|
||
|
||
Representative baseline captures:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
The full baseline screenshot set is in `artifacts/design-validation/current/`.
|
||
|
||
## Severity scale
|
||
|
||
- **P1 — major:** materially reduces operational comprehension, safety, accessibility, or
|
||
task efficiency; must be solved by the redesign.
|
||
- **P2 — moderate:** weakens polish, trust, consistency, or discoverability; should be
|
||
solved as part of the shared system or relevant screen.
|
||
- **P3 — minor:** local refinement that does not block task completion.
|
||
|
||
## Findings
|
||
|
||
| Severity | Affected screens | Finding | Recommended direction |
|
||
|---|---|---|---|
|
||
| P1 | Global shell, all mobile screens | Seven navigation links wrap into three rows, followed by the user identity and role action. It consumes most of the first viewport and provides no mobile wayfinding pattern. | Use a persistent desktop rail and an intentionally compact mobile top bar plus labelled bottom navigation or accessible menu. Keep high-value destinations visible. |
|
||
| P1 | Fleet, bookings, quality, automation, audit | Mobile CSS hides table headers and turns cells into unlabelled stacked values. The user loses field meaning, scan alignment, and row boundaries. | Create responsive row cards with explicit `data-label`/term-value semantics and prioritize the two or three fields required for the task. |
|
||
| P1 | Dashboard | Seven equal KPI tiles dominate the first screen while urgent work, today’s movements, and automation health are below the fold. All metrics have equal visual weight regardless of operational consequence. | Lead with a fleet-readiness band and a compact today/attention workspace. Treat counts as context for decisions, not the page’s main product. |
|
||
| P1 | Bookings | All 246 bookings render in one table (492 links) with only a status filter. Departures today, returns today, readiness, missing inspection, and blocked state are not visually prioritized. | Add business-state segments, search, compact readiness markers, and a scannable schedule/window column without changing the API contract. |
|
||
| P1 | Return workflow | A single form is fast but gives no progress model, no calculated outcome preview, and no explanation of suspicious odometer values until after submission. The irreversible business action is visually equivalent to a normal form submit. | Use a concise two-stage flow: inspect/record, then review calculated consequences before commit. Preserve one-page efficiency and existing endpoint/idempotency. |
|
||
| P1 | Duplicate review | Matching fields and conflicts are not visually distinguished. Survivor selection and field selection compete in one table; the outcome preview is a sentence. Confirmation is an inline `alertdialog` without true dialog focus management. | Align records, label matches/conflicts, show selected survivor and resulting record, then use an accessible confirmation dialog with explicit rewiring/tombstone consequences. |
|
||
| P1 | Automation and integrations | The page is only an outbox table. Raw event names, UUID fragments, attempt counts, and last errors are primary content. RAGcore and MCP Hub state are absent, so users cannot tell whether they are disabled, unavailable, or simply not represented. | Introduce honest integration-state summaries for n8n, RAGcore, and MCP Hub. Keep technical delivery data behind disclosure while preserving the working retry control. |
|
||
| P1 | Audit | Snake-case action names, actor types, correlation fragments, and entity types appear without human explanation or record links. Metadata and before/after context are inaccessible even though the API supplies metadata. | Present a timeline/table hybrid with readable action labels, actor/source badges, entity context, and expandable technical evidence. |
|
||
| P1 | Accessibility, vehicle tabs, merge confirmation | Vehicle tabs expose tab roles but do not implement arrow-key behaviour or panel relationships. The merge confirmation does not move/fence focus. There is no skip link. | Implement complete keyboard patterns, visible focus, labelled panels/dialogs, focus restoration, and a skip-to-content control. |
|
||
| P2 | Global visual system | Almost every section is a white rounded rectangle on a pale blue canvas. Repeated cards, pills, and borders flatten hierarchy and feel template-derived. | Establish a neutral surface hierarchy, stronger typographic rhythm, restrained radius/elevation, and operational separators instead of nested cards. |
|
||
| P2 | Login | The entry screen is legible but mostly empty space and two identical full-width buttons. It communicates neither how MobilityOps works nor a memorable product idea. | Pair immediate role entry with a lightweight fleet/event/control-centre SVG illustration and concise trust cues. |
|
||
| P2 | Fleet | Location filtering required by the original UX specification is absent. Attention is a text phrase with no indication of the underlying issue or next booking. | Add a local location filter from returned data, an issue marker, service distance, and direct row affordance. |
|
||
| P2 | Vehicle detail | Overview fields are six equal mini-cards; history is split across tabs with no persistent operational summary. Tabs are title-cased internal nouns rather than task-oriented context. | Keep a stable vehicle status/readiness header, consolidate facts, and use a timeline/detail workspace with clear empty states. |
|
||
| P2 | Booking detail | Customer, vehicle, dates, odometers, and readiness are equal-weight definition cards. Required action and current progress are not evident. | Create a booking journey header, readiness checklist, contextual entities, and a high-emphasis return action only when applicable. |
|
||
| P2 | Data Quality overview | Rule identifiers are mechanically converted from snake case. There is no category explanation, likely cause, suggested action, age, or confidence/evidence cue. | Use human category names, severity and age, evidence summaries, and a review queue optimized for triage. |
|
||
| P2 | Knowledge | Source citation is the strongest current pattern, but `Provider: demo`, tenant concepts, and indexed-count language feel administrative. Retrieval is visually indistinguishable from normal form submission. | Keep sources primary; show a compact question → procedures → answer retrieval model and translate provider state into trusted business language with optional technical detail. |
|
||
| P2 | Loading, empty, error states | Most routes render plain text paragraphs. Errors erase page context; lists offer generic empty copy; no skeletons or recovery actions exist. | Normalize skeleton, inline error, empty state, and retry patterns while retaining semantic live regions. |
|
||
| P2 | Status system | Statuses are lower-case API values. Several operationally distinct states share the same neutral treatment; meaning is often conveyed mainly by colour. | Map every status to a human label, semantic icon/marker, and accessible tone using one shared status taxonomy. |
|
||
| P2 | Performance | Large booking and vehicle result sets render eagerly; all routes ship in one bundle. There is no pagination API, but the UI can still reduce initial work and split route code. | Introduce route-level lazy loading and efficient presentational rendering; avoid animation dependencies and heavy imagery. |
|
||
| P3 | Language and formatting | Copy alternates between business language and implementation terminology (`vehicle.returned.v1`, `demo_login`, `tombstone`). Date formatting is correct but lacks relative context. | Provide human labels first, technical identifiers second, and consistent Brussels date/time helpers. |
|
||
|
||
## What already works and must be preserved
|
||
|
||
- Semantic headings, labelled form controls, real links, table headers, visible focus outline,
|
||
and non-colour badge text provide a sound accessibility baseline.
|
||
- Every visible metric and list row is backed by persisted API data.
|
||
- The synthetic-demo disclosure is persistent and clear.
|
||
- The return, duplicate merge, retry, filter, login, and knowledge interactions are real.
|
||
- Knowledge answers foreground real source title, version, section, and excerpt.
|
||
- RAGcore unavailability and n8n failure do not break core operations.
|
||
- The interface avoids horizontal page overflow down to 390 px, even though mobile
|
||
information structure needs substantial improvement.
|
||
|
||
## Selected design problem statement
|
||
|
||
MobilityOps needs to move from “working pages arranged around API resources” to “a calm
|
||
operational control centre arranged around readiness, attention, evidence, and next
|
||
actions.” The redesign should be distinctive through disciplined information design,
|
||
typography, a fleet-status visual language, and small operational illustrations—not
|
||
through decorative gradients, generic charts, or excessive motion.
|
||
|
||
## Direction for Stitch exploration
|
||
|
||
The three Stitch directions must each solve the same full product while deliberately
|
||
varying navigation, density, rhythm, and status representation:
|
||
|
||
1. **Control Rail:** compact persistent rail, high-density operational workspace,
|
||
readiness band and timeline.
|
||
2. **Dispatch Ledger:** editorial typography, ledger-like grouped lists, calmer top
|
||
navigation and strong temporal rhythm.
|
||
3. **Service Atelier:** calm editorial service workspace, narrative timelines,
|
||
humanized exceptions, and progressive disclosure.
|
||
|
||
The final choice must favour business credibility and workflow clarity over screenshot
|
||
novelty. No implementation begins until the Stitch comparison and decision are recorded.
|