Introduce a UX reference stage to ensure technical plans align with user experience goals. Adds a new template, a generation step in the specification workflow, and mandatory validation checks during planning to prevent technical compromises from degrading the defined user experience.
68 lines
2.3 KiB
Markdown
68 lines
2.3 KiB
Markdown
# UX Reference: [FEATURE NAME]
|
|
|
|
**Feature Branch**: `[###-feature-name]`
|
|
**Created**: [DATE]
|
|
**Status**: Draft
|
|
|
|
## 1. User Persona & Context
|
|
|
|
* **Who is the user?**: [e.g. Junior Developer, System Administrator, End User]
|
|
* **What is their goal?**: [e.g. Quickly deploy a hotfix, Visualize complex data]
|
|
* **Context**: [e.g. Running a command in a terminal on a remote server, Browsing the dashboard on a mobile device]
|
|
|
|
## 2. The "Happy Path" Narrative
|
|
|
|
[Write a short story (3-5 sentences) describing the perfect interaction from the user's perspective. Focus on how it *feels* - is it instant? Does it guide them?]
|
|
|
|
## 3. Interface Mockups
|
|
|
|
### CLI Interaction (if applicable)
|
|
|
|
```bash
|
|
# User runs this command:
|
|
$ command --flag value
|
|
|
|
# System responds immediately with:
|
|
[ spinner ] specific loading message...
|
|
|
|
# Success output:
|
|
✅ Operation completed successfully in 1.2s
|
|
- Created file: /path/to/file
|
|
- Updated config: /path/to/config
|
|
```
|
|
|
|
### UI Layout & Flow (if applicable)
|
|
|
|
**Screen/Component**: [Name]
|
|
|
|
* **Layout**: [Description of structure, e.g., "Two-column layout, left sidebar navigation..."]
|
|
* **Key Elements**:
|
|
* **[Button Name]**: Primary action. Color: Blue.
|
|
* **[Input Field]**: Placeholder text: "Enter your name...". Validation: Real-time.
|
|
* **States**:
|
|
* **Default**: Clean state, waiting for input.
|
|
* **Loading**: Skeleton loader replaces content area.
|
|
* **Success**: Toast notification appears top-right: "Saved!" (Green).
|
|
|
|
## 4. The "Error" Experience
|
|
|
|
**Philosophy**: Don't just report the error; guide the user to the fix.
|
|
|
|
### Scenario A: [Common Error, e.g. Invalid Input]
|
|
|
|
* **User Action**: Enters "123" in a text-only field.
|
|
* **System Response**:
|
|
* (UI) Input border turns Red. Message below input: "Please enter text only."
|
|
* (CLI) `❌ Error: Invalid input '123'. Expected text format.`
|
|
* **Recovery**: User can immediately re-type without refreshing/re-running.
|
|
|
|
### Scenario B: [System Failure, e.g. Network Timeout]
|
|
|
|
* **System Response**: "Unable to connect. Retrying in 3s... (Press C to cancel)"
|
|
* **Recovery**: Automatic retry or explicit "Retry Now" button.
|
|
|
|
## 5. Tone & Voice
|
|
|
|
* **Style**: [e.g. Concise, Technical, Friendly, Verbose]
|
|
* **Terminology**: [e.g. Use "Repository" not "Repo", "Directory" not "Folder"]
|