Feature prototype

# Feature prototype

Use once a feature has enough definition to visualize, to test the concept and gather feedback before development starts.

## Definitions

Use these meanings consistently in every step.

- **Feature:** The feature record being prototyped, or the feature whose record link the user pasted into the chat
- **Fidelity:** How finished the prototype looks. Low shows structure and flow only. Medium adds real labels and states. High applies visual design.
- **Scope:** The specific screens and states the prototype covers. Everything outside that set is out of scope.
- **State:** A condition a screen can be in, such as default, empty, loading, error, or a permission-restricted view

## Workflow

1. Read the feature, its description, its requirements, and its linked ideas. The requirements define what the prototype has to demonstrate.
2. Confirm fidelity and scope with the user. Default to medium fidelity and the primary workflow only.
3. Identify the workflow to show, from entry point to completion. One complete path beats fragments of several.
4. Generate realistic sample data drawn from the feature and the workspace. Use plausible names, dates, and values.
5. Build the prototype. Cover the primary path first, then the empty state and one error state.
6. Note which requirements the prototype demonstrates and which it does not, so reviewers know what they are looking at
7. List what the prototype deliberately leaves out, so a gap is not read as a design decision
8. Suggest what to validate and with whom, drawing on the organizations behind any linked ideas

## Rules

- If the feature has no requirements, say so and prototype the primary path only, marking the assumptions made
- Match the visual conventions of Aha! software unless the user supplies a different design reference
- When the user uploads an image as a design reference, follow its layout and styling
- Sample data is realistic and internally consistent. Never leave lorem ipsum in a prototype.
- Reference the feature and its requirements by reference number and name
- Do not update the feature. Present the prototype and let the user decide.
- Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
## What this prototype shows  
<the workflow it covers, in two to three sentences>  
  
## Screens  
| Screen | Purpose | States covered |  
  
## Requirements demonstrated  
| Requirement | Shown |  
  
## Out of scope  
- <what was deliberately left out>  
  
## Assumptions made  
- <where the record was silent and a choice was made>  
  
## What to validate  
- <question, and who to ask>
```

Save the prototype as an artifact and share the link so the team reviews the same version.

## Quality checks

- The prototype covers one complete path rather than several partial ones
- Every requirement is marked as shown or not shown
- Sample data is plausible and consistent across screens
- Assumptions are listed rather than embedded silently in the design