ahmido
90f35b971e
Refactored the customer-review workspace to emphasize the Operator Summary, tightening the hierarchy. Readiness flow and acknowledgment details were adjusted, and supporting proof panels moved to secondary visual weight. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #416
51 lines
2.6 KiB
Markdown
51 lines
2.6 KiB
Markdown
# UI-006 Customer Review Workspace
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| Route | `/admin/reviews/workspace` |
|
|
| Source | `CustomerReviewWorkspace` |
|
|
| Area / scope | Customer review / workspace |
|
|
| Archetype | Customer Workspace |
|
|
| Design depth | Strategic Surface |
|
|
| Repo truth | repo-verified |
|
|
| Screenshot | `../screenshots/desktop/ui-006-customer-review-workspace.png` |
|
|
| Browser status | Reached through local workspace route. |
|
|
|
|
## First Five Seconds
|
|
|
|
This is the most important customer-safe productization candidate. The page should answer what the customer can trust, what changed, what risks are accepted, which evidence supports the state, and what should happen next.
|
|
|
|
Spec 344 tightens the hierarchy so the Operator Summary (decision + acknowledgement + findings signal) comes first, while the review consumption flow and proof panels remain available as supporting details.
|
|
|
|
## Productization Review
|
|
|
|
- Decision-first: improved by explicit Operator Summary-first hierarchy.
|
|
- Evidence-first: must anchor all claims to review/evidence artifacts.
|
|
- Context: workspace-level customer view.
|
|
- Customer/auditor safety: primary concern.
|
|
- Diagnostics: raw/internal details must stay hidden by default.
|
|
|
|
## Information Inventory
|
|
|
|
Default content should include review readiness, review acknowledgement (attestation) state + action, evidence basis, accepted risk summary, decision summary, review-pack download, and a management-readable next action.
|
|
|
|
## Dangerous Actions
|
|
|
|
Customer-facing surface should be read-first. Export/download and publish/review actions need clear scope, audit, and language. The acknowledgement action is a write/mutation action and must remain confirmation-gated, capability-gated, and auditable, without legal/e-signature semantics.
|
|
|
|
## Scores
|
|
|
|
| IA | Density | User Clarity | Sellability | Disclosure | Hierarchy | DS Fit | A11y | Responsive | Components | UX Writing | Perf |
|
|
| ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
|
|
| 3 | 4 | 4 | 5 | 3 | 4 | 4 | 3 | 3 | 4 | 3 | 4 |
|
|
|
|
## Top Issues
|
|
|
|
1. Acknowledgement copy must remain customer-safe and explicitly non-legal (no compliance certification semantics).
|
|
2. Evidence and accepted-risk meaning should be visible without raw diagnostics.
|
|
3. Sidebar proof panels can still compete visually with the main decision flow; keep them secondary and avoid duplicating “ready/available” signals at equal weight.
|
|
|
|
## Target Direction
|
|
|
|
Spec 344 implements the first density/hierarchy polish wave. If the surface still feels too dense after real operator use, follow up with a targeted mockup and a second, narrower polish pass rather than adding new workflow surfaces.
|