Before you begin
Choose one user, one job, and one result. The first version should prove one complete workflow.
Use sample, synthetic, or de-identified information until you are ready to connect production data.
Build the first useful version
You have a working preview. Now make one change that proves the app is yours.
Choose something visible and specific
Add one required field to a form
Change the result from a paragraph to a table
Add a review step before an action is completed
Rename a screen using your team’s language
Change one rule in the workflow
Add one example that the current version handles incorrectly
A strong change request sounds like this
“On the results screen, show a table with columns for request, category, confidence, and reviewer
correction. Put low-confidence results at the top.”
Avoid “make it better” or “improve the design.” Describe what the user should see or what should
happen differently.
Once you can build, inspect, and change one workflow, you have the basic loop for developing the
rest of the product.
Common mistakes
Requesting “make it better” without naming the visible change.
Changing several systems at once.
Starting a new project instead of changing the working preview.
Frequently asked questions
Do I need to know how to code?
No. Describe the user, the job, the input, and the result. Technical users can add architecture details
later, but they are not required for the first workflow.
Should I connect real data immediately?
Not usually. Begin with representative sample, synthetic, or de-identified information, then connect
approved production sources after the workflow and controls are clear.