Should you have a design test?

One of the greatest debates product designers take on is that of the design test - yes or no? It’s a nerve-wracking idea to send your product into the wild before you may have tested every last feature, and once you feel like you have tinkered it into perfection, you’re ready to just be done and let the public loose on it, confident that you’ve addressed every possible issue. There are many more arguments for a test than not - as far as we can see, the only reason you wouldn’t want to do one is because you’re just over the product and want to be done, and that isn’t the right attitude to have a successful launch or a sticky product in the long run.

First, if you’re running design tests, you can release in a beta market with some flaws still in the product. That’s the point of user testing. You can test the product to death but unless you have it in the hands of the user, you’ll never know exactly how they’ll use it and what you might have missed. This will cut down on development time and therefore reduce your budget as you aren’t paying designers to play over and over with the same features, potentially missing the biggest bugs users will find immediately.

Studies show that companies who do design testing have a 228% higher return on investment than average, and conversion increases faster than traffic. With user testing, you’ll quickly learn what parts of your design are loved, which aren’t, where they get lost or where they get hooked, and what makes them or keeps them from converting. Design tests are also great ways to build customer loyalty - first looks make users feel good, and they’ll be talking about your product before even they’re completely satisfied - you just have to make sure you listen to and quickly implement their feedback.

Another great reason to implement design testing is reduction in costs - increase in ROI, reduction in cost - what is there to discuss? Did you know that fixing an error in post-development is 100 times more expensive than doing it before? And engineers spend half their time fixing preventable errors. QA testing won’t tell you what navigational features are confusing - they make sense to the creator. It won’t tell you what behavioral assumptions are wrong, and it won’t tell you what features you love that no one else cares about.

You’ll reduce customer service costs too - errors fixed are errors people aren’t messaging and calling about. Every UX dollar brings in at least double and sometimes up to $100 in return.

Where do customers get stuck? You’ll know if you have a design test. They’ll let you know if they can’t get past log-ins, if buttons and features don’t work, if the navigation is wrong or confusing, and so on. Customers are going to use the product differently than you do in the office. They won’t give it their full attention, analyzing every detail. You need every area working flawlessly without patches. So it isn’t just about catching your own errors - you need it to be user-friendly so the users don’t get frustrated because it’s hard for them to use correctly.

User testing also gets you an unbiased perspective. What do you think of the product? Well you - you, personally - love it because it’s your baby. The user was functioning fine without it yesterday and you have to sell them on it. Their perspective is what will matter ultimately and get them to use the product and tell others.

So in the end, do you want a design test? Absolutely, you do! Customers know good design, they expect it, and they’ll pay for it. You’ll lose a client over poor UX and you might not get them back after an initial bad impression - your competition is a click away and they can’t be better than you. One way or the other you’ll get feedback - do you want it after you’ve tested it to death on your own, are a little weary of it, and ready to move on? Or do you want it in the beginning when you can figure out how to fix things the user uncovers, while you’re still fresh on the project? The second way is the best way to ensure you have the best launch possible.