Early user testing will save you time, headaches, and money. Testing your user interfaces and information layout early will allow you to identify points of friction or confusion and address them both quickly and inexpensively. The common industry metric is that it’s roughly 100 times more expensive to deal with a bug or flaw in the product once it has been coded, as compared to the design stage (1).
it’s roughly 100 times more expensive to deal with a bug or flaw one it has been coded
(1)
Finding issues late in the build phase or after a product is in production both limits the degree to which you can respond and costs significantly more. If you find a core flaw in the flow of information or intuitiveness of design when you are at the paper prototyping phase, you can simply pick up your pencil and rethink your approach. Once you have a coded product, the cost of changing that code (or the cost of scrapping it) may limit your ability to fully restructure your approach in an ideal way, because you are likely too far committed both monetarily and in timeline to overhaul a product that is already partly or completely built. So, what’s the best way to approach this testing?
We like to focus our user interviews and testing around the underlying information architecture with low-fidelity designs for several reasons. First, they allow you to quickly and cost-effectively iterate on the feedback you receive. For the same time and effort it would take to create one high fidelity wireframe, you could easily test or 3 or more different low fidelity options.
Second, you are less likely to take feedback personally or talk a user into a specific design if you haven’t invested your heart and soul into making it pixel perfect yet.
Third, when you are conducting usability tests, aesthetic design can be distracting. I’m going to elaborate on this a little further because it’s probably not immediately apparent why having a high fidelity wireframe could detract from your testing of the structural user experience.
If you are trying to get feedback on the information architecture, meaning the fundamental layout of data on the screens, and if the navigation options and available actions make sense throughout your applications, the color of the button or styling of the data tables doesn’t really impact whether the interface makes intuitive, structural sense to a user. However, color and high fidelity design work could distract them from giving you feedback on the structural layout.
For example: If you are buying a house, the floorplan and quality of the layout, etc. is what matters as far as the real livability of the structure. But people viewing houses often have trouble seeing past ugly paint or poorly decorated interiors—this is why a whole industry exists staging houses for sale.
The same concept applies to your user interface. If the interface is empty of flashy colors or aesthetic design elements, your testers are forced to focus on the layout and structure of proposed interface and information. Once you are confident you have worked out the best options for that, then you can worry about dressing it up with color and design aesthetics. Changing colors and aesthetic design elements is also much less costly to adjust after you are in production than overhauling the underlying structure of your screens and information.
We like to conduct user testing with 3-5 users per iteration. Five is the ideal number of test users before you reach a diminishing return, but you can still identify over 60% of the friction points in your user interfaces with only 3 test users (2). It is best if you can find test users who are in the same demographic as the target users of your system, but any test user is better than no test users. Even if someone doesn’t fit your target demographic, they will still be able to help identify major points of confusion, so you can eliminate them.
In today’s world there are lots of tools for conducting remote user testing on existing (already built) products. But it can be challenging to conduct this sort of low-fidelity user testing or “paper prototyping” in the remote work settings that have become very common, especially since 2020. We like to create wireframe sketches using a paper tablet. Ours allow us to meet remotely with test users via video chat and live stream the content directly from our tablet as we review proposed screens so we can iterate on the spot, with a user, to incorporate their feedback and ideas as we go through different exercises. If you have a different way of conducting these sorts of low-fidelity user testing and feedback sessions in our remote reality, we would love to hear about it!
Sources:
- World Leaders in Research-Based User Experience. “Paper Prototyping: Getting User Data before You Code.” Nielsen Norman Group, https://www.nngroup.com/articles/paper-prototyping/.
- World Leaders in Research-Based User Experience. “Why You Only Need to Test with 5 Users.” Nielsen Norman Group, https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/.
