This experience—this feeling of surprise and delight—is not about finding an error. It’s about learning how the product performs in the hands of users, so it can be improved. In a sense, GUI design is like a puzzle that must be assembled well in order for the user’s brain to see the intended picture. It’s rare that a team gets it exactly right on the first try. That’s why a good development process expects and plans for rapid iteration—and expects formative testing of either prototypes or early working versions to inform the next iteration.

Fling that thing! If it won’t fly, bend the wing!
Formative testing of Iteration 1 informs the design of Iteration 2.

For me, realising there’s a problem means we can iterate the product to address the problem. That’s exciting. But realising there’s a problem can also be disappointing or humbling. From time to time, I’ve said to myself:

“I thought this design was really good.”

“Why didn’t I see that problem coming? It’s SO obvious, in hindsight.”

This experience points to the problem with heuristic reviews done by an individual expert. (In contrast, experts who work in pairs come closer to finding all the problems in the set.) But either way, experts cannot predict all the usability and interaction problems in a software product. That’s why testing and a process that includes rapid iteration are necessary.

The insight and the subsequent exploration of the problem lead to the best parts of the experience: deciding how to present the test results most effectively (as a critique of the prototype, not as a criticism of the effort to date), and facilitating the process of designing the next iteration.