Project Retrospectives · Published June 27, 2026
Retrospective: The Cost of Vague Acceptance Criteria
The system was finished and the client said it was not what they wanted. Every argument returned to one line: it was never specified.
Development went smoothly and every listed feature was delivered. At acceptance the client said the workflow did not match their habits and asked for major changes. The dispute ran three weeks and ended in compromise, with the relationship damaged.
Where the dispute came from
The requirement document listed features but not flows, such as who clicks what in which state.
In prototype review the client looked at layout, not process.
Acceptance criteria had no usability clause, blurring the line between working and workable.
What we do now
Requirement sign-off includes flow diagrams and role descriptions, confirmed item by item.
Prototype review requires the client to click through the main flow, not look at screenshots.
Acceptance checklists include usability items, such as a maximum number of steps for a typical task.
Acceptance disputes are rarely bad faith; they are insufficient confirmation earlier. Confirming flows beats writing ten more pages.
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →