After a prototype review, the team should turn feedback into clear decisions.
The review should answer a simple question: did the prototype help prove the idea, or did it show that something needs to change? Feedback can lead to a revised prototype, a clearer requirement, a later-phase idea, or a decision not to build that part at all.
What Should the Team Look For During the Review?
- What worked? Which parts made sense and supported the intended process?
- What confused people? Where did users hesitate or misunderstand what to do?
- What was missing? Did an important step, field, rule, or connection not appear?
- What assumption was wrong? Did the prototype show that the team misunderstood how the real process works?
- What new questions appeared? Did testing show that another idea needs to be checked before building?
Salesforce recommends going back to the original question after prototype testing and asking whether the team now has a clear answer.
How Should Feedback Be Sorted?
| Feedback Type | What It Means | Possible Next Step |
|---|---|---|
| Clear problem | The idea does not support the intended process. | Revise the idea and test again. |
| Missing requirement | An important need was not understood earlier. | Clarify the requirement and review its effect on scope. |
| Nice improvement | The idea would help but is not required for the first result. | Save it for a later phase. |
| Wrong assumption | The team learned that the original idea was based on bad information. | Go back, research the problem again, and change direction if needed. |
Does Every Piece of Feedback Become a Change?
No. Prototype reviews can produce many opinions. The team should look for patterns, real problems, and feedback that helps answer the original question.
Salesforce recommends deciding which feedback to act on, which feedback should wait, and why. This prevents the latest comment from changing the whole direction without enough reason.
Feedback is input, not automatic scope
A useful idea can still be moved to a later phase if the first version can work without it.
When Should the Prototype Be Tested Again?
Test again when an important question is still open or a major change needs to be checked with users.
The prototype does not need endless rounds. The point is to learn enough to make the next decision with more confidence.
When Is the Team Ready to Move Forward?
The team is ready when the prototype has answered the important question well enough to make a build or scope decision.
- The main workflow makes sense.
- Important user problems have been addressed.
- Required features and nice-to-have ideas are separated.
- Open questions are small enough to handle during later design or implementation.
- Any change to project scope has been reviewed.
For the earlier distinction between the two evaluation tools, see Demo vs. Prototype.
Sources and Further Reading
- Salesforce Trailhead: Create a Prototyping Plan — explains how teams collect feedback, look for patterns, decide what to act on, and test again when needed.
- Salesforce Trailhead: Present Prototype Findings — explains how prototype findings can separate launch requirements from nice-to-have ideas and help the team move into the build stage.
- Salesforce Trailhead: Create UX Artifacts — explains how user feedback should shape repeated design changes and prototypes.
Sources support the general prototype-review process. The exact Booking Ninjas next step depends on the question being tested and the agreed project scope.