Microinteractions: Full Color Edition

Appendix A. Testing Microinteractions

There are many who would advise you not to bother testing microinteractions, saying they are the equivalent of asking “What color should the bike shed be?” That is: unimportant.^[44] Let’s assume if you’ve made it this far into the book, you feel microinteractions have value and can be improved by being validated, tested, and refined via user input.

Microinteractions can benefit from using a Lean UX–style methodology of Build > Measure > Learn: build the microinteraction to test it; measure the design with a variety of quantitative and qualitative methods; learn from an analysis of those findings. Then iterate.^[45]

Unlike a true Lean UX process, where you’re testing a “Minimum Viable Product” to see if the concepts (“hypotheses”) are valuable, with microinteractions we can mostly assume the overall concept is valuable—or at least necessary to the proper functioning of the app or device. You are more testing the flow and structure than testing the concept. Also dissimilar to Lean UX is the fidelity of the prototype. Rather than prototyping the least you can test (often a paper prototype), with microinteractions, because the structure of microinteractions is important, you need as high a fidelity prototype as you can develop in order to test them effectively. The links between trigger to rules to feedback to loop are tight and not easily separated.

Most microinteractions probably aren’t tested alone for desktop software. The effort and expense of ...