Describe an app clearly · Learning Azure

What you’ll be able to do

Name the user and the one task your app improves.
Write observable acceptance criteria.
Separate first-release requirements from later ideas.

Before you beginA fictional app idea and access to an AI assistant. No Azure account or deployment is needed.

Get the idea

Give the assistant a job it can finish

“Build a helpdesk” can imply accounts, databases, notifications, reporting, and permissions. “Let an operator add and resolve fictional requests in one browser session” is a bounded task. State the limits explicitly.

Define success before generating code

Acceptance criteria describe what a person can observe: an empty title is rejected, the request appears in the list, and the status can be changed using the keyboard. These criteria become your review checklist.

Learn the next platform concept when it matters

Prototype the interface first. Add hosting when you need a URL, storage when you need durable records, and identity when you need user-specific access. Each step introduces an Azure decision for a concrete reason.

Try it yourself

Choose one small app: a request tracker, inventory list, or meeting-action organizer. Identify one primary user and task.
Use the prompt below to produce a one-page brief. Review every assumption and remove invented requirements.
Select three acceptance criteria and one explicit limitation. For example, “refresh clears data” is acceptable for a prototype if it is clearly stated.
Ask the assistant for a build sequence of three independently testable changes. Keep persistence and authentication out of the first prototype.
Read the brief aloud. If the assistant could reasonably build two very different products from it, make the behavior more specific.

Example · commands or prompt

Help me scope a small IT request tracker prototype.
Ask about the primary user and task before proposing features.
Produce: purpose, fields, actions, three acceptance criteria,
explicit limitations, and a three-step build sequence.
Keep the first version in one HTML file with fictional data.
Separate confirmed requirements from your assumptions.

Check your resultYou have a brief with a named user, one main task, observable checks, and a bounded first release.

Finish the lab

Keep the brief as a versioned project document. Do not include real employee details or credentials in prompts.

Quick knowledge check

Why are acceptance criteria more useful than “make it polished”?

Reveal the explanation

They make correctness observable. You can check whether the generated app performs the required behavior rather than judging only its appearance.

Take this with you

A clear brief is the first reusable tool in an accelerated app-building workflow.

Go deeper

Azure hosting example for the next stage

AI-assisted lesson · Reference links checked October 3, 2026. Exercises are teaching examples; they have not been executed against your Azure subscription.