Design operations guide

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 you think you’ve accomplished your principle with the prototype form, but participants stumbled over the order in which they should fill in the information fields. This indicates the need for a technical design refinement. The team could redesign the form to simplify the form’s input order for the participants, or concentrate on the system-facing side of the form and improve flexibility of the input order so the system accepts more information input in more combinations 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 you move closer and closer to an effective design.

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

As testing progresses, you may find that you’re getting different, contradictory feedback from participants. This is especially true in complicated designs, as the team is trying to create a product, service, or system that serves multiple groups.

An example of this is when software has both public- 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 participant needs. The final design can neither privilege the public participants to the point that the internal ones can’t get what they need from software, nor can it privilege the internal people to the point that the public participants struggle to use the software correctly.