Write acceptance criteria people can demonstrate

“The dashboard should be easy to use” expresses a goal. It does not tell a project team what to demonstrate at delivery or help a business owner decide whether the work meets the requirement.

Acceptance criteria turn an intention into observable outcomes. They work best when the people building and using the software agree on them before implementation.

Start with the person's goal

Name the person, the task, and why it matters. An illustrative requirement might be: “A warehouse coordinator needs to find orders awaiting assignment so that each order can be given to an available team.”

The Government Digital Service's user-story guidance describes stories in terms of the user, need, and goal. It describes acceptance criteria as outcomes used to check whether that need has been met.

Use that structure if it helps the discussion. The format is less important than making the intended result understandable.

Replace adjectives with evidence

Translate words such as simple, fast, flexible, and secure into specific expectations that the relevant team can evaluate.

Do not invent a numeric target just to make a sentence look measurable. Agree a target that reflects the task and can be tested under defined conditions.

Keep broader qualities such as accessibility and security in their own evaluation plans as well. A few feature-level criteria do not replace those reviews.

Write a complete example

For the illustrative assignment task, the team might agree:

• Given an unassigned order in the coordinator's location, it appears in that location's unassigned list.
• When the coordinator assigns an eligible team, the order shows that team and leaves the unassigned list.
• If the order has already been assigned by someone else, the coordinator sees the current state instead of silently overwriting it.
• A coordinator without access to another location cannot assign its orders.
• The assignment records who made the change and when.

These are example requirements, not claims about an existing product. Each should lead to a demonstration or test with representative records.

Include the next person's view if the task depends on a handoff. An assignment is incomplete as a business workflow if the receiving team has no way to find it.

Agree how evidence will be reviewed

Name the person who can accept the work. Set aside suitable sample data and define where the demonstration will happen.

Record the result against each criterion. If an outcome differs from the agreement, distinguish a defect from a newly requested behavior. Discuss the difference rather than silently changing the acceptance condition to match the implementation.

Update the criteria when the business deliberately changes a rule. Preserve the decision so later reviewers understand why the expected behavior changed.

Keep criteria useful after delivery

The same scenarios can support regression checks when the software changes. They also help a new maintainer understand why a behavior exists.

Attach important criteria and their evidence to the handover. For a first release, keep the list focused on the complete task you chose to support, including the exceptions that make it workable in daily use.