How to use the User Story Generator.
A user story should express a capability and why it matters. Avoid disguising a technical task as a user benefit.
Make the workflow fit your task.
Name the user, capability and reason it matters, then add acceptance conditions that make the result observable. Keep the story focused enough that its completion can be reviewed against a concrete scenario.
- What you provide
- User problem and desired capability.
- What you get
- User-centered stories with scope boundaries.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Catalog manager needs to identify changed supplier prices.
Completed example
As a catalog manager, I want to review changed prices so I can approve updates before importing them.
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Should technical maintenance work be forced into a user-story sentence?
Explain its real purpose and constraints. A technical task can be documented honestly without inventing a user action to fit the format.
Why does the story seem complete but remain difficult to test?
Add the expected behavior and relevant boundaries. The benefit explains why the work matters; acceptance conditions explain what completion means.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑