What a prototype should help your team decide

A prototype is most useful when everyone understands why it was made. One sample may explore shape and handling. Another may demonstrate an interaction or investigate how components fit together. Neither should be assumed to represent every aspect of the finished product.

Before a review, write down the decisions the sample is meant to support. That short step makes feedback more focused and gives the next iteration a clear purpose.

Define the review scope

Ask the development team to explain which features are representative and which are temporary. Note differences in materials, finish, assembly or software behaviour where they affect the review.

Create a short list of questions. Can the intended user reach the controls? Does the proposed layout support the required functions? Is the visual direction ready for approval? Keep unresolved engineering questions visible instead of assuming that a convincing appearance means they have been answered.

Review against the brief

Bring the latest agreed requirements to the review. For each relevant item, record an observation and a decision: accepted for this stage, needs revision, or requires further investigation.

Be specific about feedback. “The control was difficult to find while holding the sample” describes a useful observation. “Improve the design” leaves the team guessing about the problem and the expected result.

Keep preference and evidence separate

Some feedback concerns brand direction. Other feedback comes from a task, measurement or inspection. Both can matter, but they should be recorded differently.

• Note who reviewed the sample and which tasks they performed.
• Photograph the issue or mark it on the relevant drawing where helpful.
• Record the conditions of an observation so it can be repeated.
• Distinguish a requested design change from an unanswered question.
• Assign an owner to each follow-up decision.

A consolidated feedback document helps avoid contradictory comments arriving through separate conversations.

Agree what happens after a change

A revision can affect more than the visible part of a product. If the team changes a housing, control or component arrangement, ask which other items need another review. Update the brief and the sample record together.

Define what the next version should demonstrate and which earlier decisions remain valid. Keep version names consistent across drawings, samples and feedback so that an approval cannot be mistaken for approval of a different revision.

Close the review with a decision record

At the end of the review, summarise accepted items, requested changes and open questions. Agree the next deliverable and who will approve it. A sample can be useful even when it reveals that an idea needs reworking; the value lies in making the next decision better informed.

When discussing a prototype project with BaiChang, share the current brief and explain what you need to learn from the first sample. That helps shape a review process around your project's actual uncertainties.