How to Define Acceptance Criteria for a Hardware Prototype
A practical way to decide what an early hardware build must prove, how to check it, and when the team has enough evidence to move forward.
Best for
Founders and product teams commissioning a prototype or reviewing a completed build
Give the prototype a specific job
Acceptance criteria are the conditions that let a team say a build is useful enough for its intended next step. They are not a wish list for the eventual product. They answer a narrower question: what must this particular set of units demonstrate before more time or money is committed?
Start with the decision the prototype is meant to unlock. A feasibility unit may need to prove that a sensor can trigger a response through the intended enclosure. An investor-demo unit may need to repeat one interaction reliably. A pilot sample may need to show that assembly and testing can be performed by someone other than the designer. The job determines the checks.
Write observable conditions, not encouraging adjectives
Words such as intuitive, compact, responsive, and premium can guide a product conversation, but they are hard to inspect at a workbench. Turn them into observable statements. Instead of “the device has good battery life,” write “after the defined test day, the unit retains at least 20 percent charge.” Instead of “voice interaction works,” write the expected wake, input, response, and visible state for a named test scenario.
Each criterion should identify the unit or configuration being tested, the action or condition, the expected result, and any important test setup. This makes a result repeatable when a different engineer, supplier, or founder runs the check. It also prevents a smooth demo under unusual conditions from being mistaken for product evidence.
Cover the failures that would change the next decision
Early builds do not need every possible qualification test, but they should address the risks that could invalidate the current plan. For a connected AI device, that may include boot behavior, charging, a core sensor signal, network loss, response latency, a low-battery state, and a clear indication of what the product is doing. For a mechanical product, it may include fit, repeated motion, load, noise, or a likely handling mistake.
Choose a small number of pass-fail checks and a few measurements that provide context. A criterion can allow a known limitation when it is explicit: for example, the cloud response may be slower than the long-term target, while the prototype still proves that people understand the physical interaction. Honest boundaries keep the team from treating every imperfection as either a disaster or something to ignore.
Agree on the evidence before the build arrives
Decide how results will be recorded while the requirements are still fresh. A simple shared table can list the criterion, test method, expected result, actual result, evidence link, owner, and follow-up. Photos, short videos, power logs, firmware versions, and notes on test conditions are often enough for a prototype stage.
This record is particularly valuable when development crosses time zones or moves between a Shenzhen supplier and an overseas product team. It replaces vague updates such as “mostly working” with a visible view of what was checked, what passed, and what still needs a decision. The aim is not to create paperwork; it is to preserve the learning paid for by the build.
Review results as choices, not a scorecard
When the prototype is complete, review the criteria alongside the original build goal. Separate issues that block the next step from issues that can be improved later. A rough enclosure finish may be acceptable for a user-interaction study, while an intermittent power reset is not. The same observation can matter differently depending on the evidence the team needs next.
End the review with a short decision: proceed, revise, or run a focused experiment. For every failed or uncertain criterion, assign the next action and state what new evidence would close it. This creates a clean bridge into the next brief, engineering revision, or pilot plan. The prototype then becomes more than an object—it becomes a dependable basis for the next build decision.