Testing Evaluation
The number of testing and iteration rounds are highly specific to the nature of your project. An easy way to think about this is to compare the test results to your principles and use cases.
At the end of each round of making and testing, reflect back on this combination of goals and use cases to evaluate what to do next. For example, maybe principle seems to be accomplished by the prototype form, but participants stumbled over what order to fill in the information fields. This indicates the need for a techincal design refinement. Either the team redesigns with a focus on simplifying the form’s input order on the participant-facing side of the form, or the team could concentrate on the system-facing side of the form and make the input order more flexible so the system accepts more combinations of information input order than before. After making those changes, the team retests.
Alternatively, maybe the solution doesn't really seem to answer any of the design principles, after all; it's not really solving the problem, even though you thought it would. This is an indication to go back to the ideation stage and rethink the overall concept. It's important to keep in mind that this doesn't mean that the prototyping test was a failure - understanding why this concept or use case didn't work will greatly inform the next version. If everything works, it's time to move to a higher fidelity. The more you make and test, the fewer problems there will be as we move closer and closer to an effective design.
Use the testing evaluation framework to see how your design or designs worked in testing. Make additional notes or analysis on additional sheets or on blank sheets of paper.
Test Until There Are No Surprises, Then Iterate
By the time you can move to another full iteration, participants should give you no feedback that surprises you and encounter no hesitations or hiccups that derail them from moving through the process. This means that none of the participant questions pertain to the design itself, but only to the process they’re using the design for.
If your design is a form, participants should move through the form fluidly and quickly, then look up at you and ask a question not about the form, but about the next steps in the process. Once your participants are confident they’ve filled out the form properly to the point that they have no surprises as they move through your design, you know that you can proceed to the next phase of iteration.
Balancing Participant Needs
Click to enlarge the above image
As testing progresses, you may find that you're getting different, contradictory feedback from partcipants. This is especially true in complicated designs, as the team is tryign to create a product, service, or system that serves multiple groups.
An example of this is when a software has both public-facing participants as well as internal-facing participants. Both groups have needs that overlap, but they also might have needs that are diverse from or conflict with each other. In this case, the design team must work to balance the participant needs. The final design can neither privledge the public participants to the point that the internal ones can't get what they need from software, nor can it privledge the internal people to the point that the public participants struggle to use the software correctly.