Start with the outcome, not the solution
A project brief may say, “Create a page for workshop sign-ups.” That describes the work, but it leaves important questions open. What information must visitors see? What happens after they submit the form? Who decides whether the page is ready? Acceptance criteria answer these questions before the team commits to a design or starts building.
Begin by naming the intended outcome and the people involved. For the workshop page, the outcome might be that a visitor can understand the workshop and submit a registration request, while an organizer can receive enough information to follow up. This gives everyone a reason for each requirement. It also helps separate essentials from ideas that might be useful later.
Write criteria that someone can check
A useful acceptance criterion states what must be true when a piece of work is complete. It should be specific enough that a reviewer can check it without guessing at the writer’s intent. “The page looks professional” is difficult to verify. “The page shows the workshop topic, location, schedule, price, and registration deadline” gives a reviewer a clear list to inspect.
Describe observable behavior for interactive work. For example: “If a visitor submits the form without an email address, the form identifies the missing field and does not send the request.” Another criterion might state: “After a successful submission, the visitor sees a confirmation message explaining what happens next.” These statements define the expected result without prescribing every design or technical decision.
Keep each criterion focused on one checkable outcome. If a sentence combines layout, form behavior, email delivery, and content approval, split it into separate items. A short list is easier for a freelancer to estimate, for a student team to divide into tasks, and for a client to review.
Cover the complete experience
The most obvious criteria often describe the main task, but a complete definition of done also considers content, errors, and handoff. For a sign-up page, ask where approved workshop details will come from, what visitors see if they make a mistake, and what the organizer needs after launch. For a design-only assignment, specify which screens or states will be delivered and whether the files need annotations for a developer.
Consider the ways people may use the result. A criterion might require that form fields have clear labels, that the page can be used with a keyboard, or that key information remains readable on a narrow screen. State the expected check rather than relying on broad terms such as “accessible” or “mobile-friendly” alone. The appropriate checks will depend on the project, so agree on them with the people responsible for review.
Review the criteria before work begins
Acceptance criteria are most useful when the people requesting and doing the work review them together. Read each item and ask: Can we tell whether it has passed? Do we have the content, access, or decisions needed to complete it? Does it fit the agreed scope? If two people interpret a criterion differently, rewrite it before that difference becomes a late-stage revision.
Record who can approve the finished work and how feedback will be collected. A small team might keep the criteria beside its project tasks; a freelancer might include them in the agreed brief. For each item, leave room to note its status and any evidence a reviewer needs, such as a link to a preview or a description of a test. The goal is a shared reference, not a complicated document.
New information may change the plan. When that happens, update the criteria deliberately: note what changed, who agreed to it, and whether it affects effort or delivery. Avoid quietly adding requests to the original list. A visible change keeps expectations clear for everyone.
Use the same criteria at delivery
Before presenting the finished work, go through the criteria one by one. Check the ordinary path and relevant error states, confirm that required content is present, and identify anything that remains unresolved. If an item cannot be verified yet—for example, because the final workshop details have not been supplied—mark it as pending rather than calling the entire project complete.
Share the reviewed list with the deliverable. It gives the approver a practical way to respond: accept an item, point to a specific gap, or request a change outside the original scope. It also makes a stronger record of the project than a vague statement that the work is “done.” For a portfolio case study, you can later describe the agreed goal and how the final work met it without exposing private project details.
