Working with users during the design process will untie project knots and boost team productivity and focus. But there always seems to be an excuse for not testing. Here are 4 ways to counter the excuses and make usability testing happen.

Testing a paper prototype
Excuse 1: “It’ll slow us down”
Finding users, building prototypes and working through hours of research takes time. Why not spend that effort on writing more code?
Counter argument. You say: “Our business objective is to reach profitability as quickly as possible. To do that, we need to understand what our customers really need and make sure we’re all agreed on the direction. A usability test might take some time in the short term, but it will help us reach our overall business goal quicker.“
Usability testing, like many UCD tactics, is an investment. You put in time and money, but you get back a product that sells better and costs less to support. But usability testing is also beneficial during the design process…

The managing director observes a usability test via a video link
1. Design the thing better, quicker: Trying to design a product for target users, without ever meeting any, is like pulling teeth. But if you just watch a few users using a prototype, a competitor product or their current system, they’ll tell you what you really need to know quickly, effectively and (comparatively) effortlessly.
2. Manage the politics more easily: Successful designs come from teams all pulling in the same direction. Usability testing results will reduce squabbles, give confidence to management and get people to focus on improvements rather than feature creep. Even the most sceptical team members can’t ignore videos of 5 or 10 real people battling with their software.
3. Get a team energy boost: Seeing ideas succeed makes the team feel positive. Seeing them fail motivates people to sort things out.
Excuse 2: “Our product is already perfect”
You and your team will become so deeply familiar with the product you’ve designed that you will think it is perfect.
Counter argument. You say: “We believe the product is perfectly easy and useful. But can we prove it? How many problems exist that we’re not aware of? What impact might they have? Developers may think their code has no bugs, but we still hire testers to prove it. What evidence do we have that our design is perfect first time?”
This behaviour is often referred to as “drinking your own Koolaid“. It means you’re doubly ignorant…
Continue reading 4 ways to combat usability testing avoidance →