Add design and product documentation
This commit is contained in:
13
DESIGN.md
Normal file
13
DESIGN.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# Design — FreightOps Control
|
||||
|
||||
## Direction
|
||||
|
||||
Dense utilitarian operations UI: stable sidebar, compact tables, status hierarchy, restrained charts, and low-noise surfaces.
|
||||
|
||||
## System
|
||||
|
||||
- Use semantic status tokens and tabular numerals; never encode state by color alone.
|
||||
- Prefer tables and aligned detail panels over decorative card mosaics.
|
||||
- Keep loading, empty, stale, partial, and error states explicit.
|
||||
- Motion is limited to state transitions and attention routing; reduced motion must preserve all information.
|
||||
- Mobile uses task-focused views rather than shrinking the desktop dashboard.
|
||||
22
PRODUCT.md
Normal file
22
PRODUCT.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# Product — FreightOps Control
|
||||
|
||||
Status: approved baseline.
|
||||
|
||||
## Audience and job
|
||||
|
||||
Dispatchers and operations leads need to detect exceptions, understand shipment state, coordinate routes and returns, and act with an auditable operational picture.
|
||||
|
||||
## Primary journeys
|
||||
|
||||
1. Scan fleet and shipment health, alerts, and service-level risk.
|
||||
2. Filter and inspect shipments, routes, returns, and responsible operators.
|
||||
3. Resolve or escalate an exception and verify the resulting state.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- No marketing landing-page patterns inside operations screens.
|
||||
- No charts or statuses without definitions, timestamps, and empty/error states.
|
||||
|
||||
## Success criteria
|
||||
|
||||
Critical exceptions are visible quickly, tables remain usable at realistic density, and every action has feedback and audit context.
|
||||
Reference in New Issue
Block a user