Idea user flow

# Idea user flow

Use when an idea is under review and you need to see the end-to-end workflow a user would follow before committing to a solution.

## Definitions

Use these meanings consistently in every step.

- **Idea:** The idea record under review, or the idea whose record link the user pasted into the chat
- **User flow:** The ordered sequence of steps a person takes to complete the job the idea describes, from entry point to completion
- **Persona:** A persona record in the workspace, used to describe who is taking each step
- **Decision point:** A step where the flow branches based on a choice the user makes or a condition in the product

## Workflow

1. Read the idea, its description, its linked ideas, and the comments and votes on it. The comments usually carry the workflow detail the description leaves out.
2. Identify the persona taking the flow. Use a linked persona record when one exists. When none exists, describe the role in one line and mark it as an assumption.
3. Name the entry point. State where in Aha! software the person is and what prompted them to start.
4. Write the flow as numbered steps. Each step states what the person does and what the product does in response.
5. Mark every decision point and describe each branch. Keep branches shallow. When a branch is large enough to need its own flow, say so rather than nesting it.
6. Name the end state. State how the person knows they are done and what changed as a result.
7. List the edge cases and error states the flow has to handle, including permissions, empty states, and partial data.
8. Note what the idea does not answer. These become the open questions for design.

## Rules

- If the idea is missing or too thin to support a flow, ask short follow-up questions before drafting
- Write the flow in second person. "You select the release" rather than "the user selects the release."
- Describe behavior, not implementation. No API names, no field types, no component names.
- Anything not supported by the idea or its linked records is labeled **Assumption**
- Reference records by reference number and name
- Do not update the idea or promote it. Present the flow and let the user apply it.
- Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
## Persona  
<who takes this flow>  
  
## Entry point  
<where they start and what prompted it>  
  
## Flow  
1. <what you do, and what the product does in response>  
  
## Decision points  
| Step | Condition | Branch |  
  
## Edge cases  
- <case and expected behavior>  
  
## Open questions  
- <what the idea does not answer>
```

## Quality checks

- Every step names an actor and an outcome, not just a screen
- The flow reaches a stated end state rather than trailing off
- Every decision point has all of its branches described
- Assumptions are labeled rather than blended into the flow