Connect with your exact customers
See, hear, and talk to your customers
Uncover insights about any experience
Share key insights across your organization
Internal stakeholders are not your users. You need unbiased feedback from your target market.Or even if they know something is not quite right, some internal users may simply not speak up for fear of offending their colleagues or embarrassing themselves. That’s the beauty of doing user testing. Your test participants aren’t obligated to spare your feelings. You get the feedback you need, whether you like it or not. Then you can change gears and build a better experience before you waste time on coding, testing, and release efforts.
If test participants encounter an issue, you can bet that your own customers will encounter it, too.The nice part about user testing solutions is that they allow you to choose parameters regarding your test participants. You can use filters and screeners that allow you to target the specific group of people you want feedback from. That way, you can test the product with users who are similar to your current customers while still getting a fresh perspective on the functionality you are about to release.Yet, sometimes, you deal with stakeholders who don’t think that’s enough. No matter how many conditions are listed in the screener, they remain convinced the user test is useless because those users are not their current users. They think the product you’re building is so unique that you absolutely need your current users to test it.However, with few exceptions, most apps and websites are, in fact, not unique. If you’re working on a retail app, you can certainly get value from tests with users who have made purchases from any number of retail apps similar to yours. Same goes with any other field.Regardless of whether a test participant is a current user of your app or website, user testing will reveal issues in the overall flow and user experience that will apply to your existing users as well. If you don’t uncover those issues before releasing, you’ll end up getting the exact same feedback from your actual users, after you wasted time and resources and released your feature to production.
There is always time for user research if you make it a priority.On a different note, you also don’t need to run a user test for every single feature you build. But you need to allocate time for user testing (and making changes based on the feedback) at the requirements phase. As it happens, this week I was reminded of the power of user testing and the need to allow a user experience architect to act on user testing feedback. Some time back, a stakeholder provided a specific requirement which, in theory, made a lot of sense. We developed the experience in Axure and ran a user test. It performed very poorly; 3 out of 5 test participants were unable to complete the task. We made changes based on the input from the first test, and then we ran it a second time. Unfortunately, even with the changes made, now 4 out of 5 participants either could not complete the task or were incredibly dissatisfied with how the experience was implemented. The team is back to the drawing board now, and I have informed the stakeholder that the original timeline will be pushed out. A responsible product manager should never release a suboptimal feature that will require rework anyway.
Get our best human insight resources delivered to your inbox every month. As a bonus, we'll send you our latest industry report, The rise of the Experience Economy!
About the author: Codrin Arsene is a technology writer and a senior product manager. His areas of expertise include digital marketing strategies, UX design, bottom-of-funnel conversion, and optimization. He is a Content Writer with Y Media Labs where he writes on mobile app strategy, analytics, marketing strategies and online business development.