Seek & Destroy: How breaking builds stronger products

Whether it’s a mobile game for young children, enterprise inventory software or fish and chips from your favorite restaurant: we all want the best product possible. Tons of time and effort goes into the creation of products and services each day, but an integral part in delivering excellence is often under-represented: someone actually checking to see if the product is excellent or not.

A product can have well-written code behind the scenes, amazing artwork, and impeccable sound mastery, but if those systems don’t work well together your product will never be as good as the sum of its parts. So get someone to tear into what you’re making and break your heart: you and the product will be better because of it.

Broken, made better

Kintsugi is the Japanese art of repairing broken pottery with precious metals such as gold or silver, transforming an object’s wear and tear (in this situation, testing - breaking and putting back together) into value in the overall product, that its repair is a part of its history rather than something to obscure.

A similar approach should be taken with what you want to produce: test it and see where it falls apart so you can put it back together only this time, it is better than what it was before. Without testing there was no way to know that maybe the user flow of logging into the product was a hassle, but now having scrutinized and repaired we have created a better solution for our users.

Most QA testers realize how difficult it can be to hand over to someone who will do their best to break, or provide constructive criticism on, something you all put your blood, sweat, and tears into. But this can provide valuable insight from a different perspective, often leading to vast improvements to your product, not to mention the level of confidence you'll have in your work when it gains the tester's seal of approval. A team or team member may sometimes need to be reminded that this process is to create the best possible product, and is by no means a personal attack.

Handling with (too much) care

I understand that what we create can be our baby, and we’d never let anyone speak poorly of or mistreat all that hard work! But that’s not the best way to creating a better experience for your users. Testing, especially objective and unbiased testing, can get the results users crave.

There’s an unconscious approach that’s taken when we work with something we’ve built to be careful with it, you know to click the mouse only once or that the username textbox only takes up to thirty-two characters, which is why handing it off to someone who has never seen it or worked on it can be a real boon in terms of testing. Someone who doesn’t have the history with the product will more than likely test its boundaries by doing things they “shouldn’t” (from the creator’s perspective) and end up finding breakpoints which can be addressed.

Giving a player a video game without any education or prior knowledge on it can give you a good indication on what works and what doesn’t. Maybe the turret section in the fifth level is boring and should be changed but they loved the Moon base aesthetics of the second level, this kind of feedback can be invaluable in having been found and fixed before the end user gets ahold of it.

Nothing personal

This one’s tough. It can be hard to take criticism on thing you work on and create, people are attacking what you and your team have poured hours into and they are saying it wasn’t worth it, right? Not exactly. Feedback can be hard to take, but people testing your product aren’t just out to hurt feelings, they want to help create something even better.

In particular, communication through emails, instant messaging and ticketing systems can seem misleadingly cruel by way of unemotional text. Reading feedback in just plain text can seem more hurtful than its intention; a text document can’t mimic the subtle tone changes, gestures, inflections and other in-person communicative methods which can “soften” what’s being said.

No matter how nice the feedback is phrased it can be a hard pill to swallow when it comes to changing something you were in charge of creating and that’s fine, going through that is just a step in the process that gets easier through repetition. Occasionally you can get lucky after revisions to have things set back the way they were, but rolling with the punches can yield a better product and process in the end.

Of babies and bathwater

Being able to cut the apron strings on features within a product is hard, harder still if you made that feature or spent a lot of time with it. Being able to trim the unneeded or non-essential parts of a product can save a team a ton of time and open them up to regroup on other important work and issues.

Maybe you’re proud that the app can be accessed via a touch-gesture on mobile, but that same process is error-prone or your end user doesn’t use it: it may be better to remove that feature (with its bugs) and focus on another task that is needed. This applies not only to implemented functionality but how that functionality is implemented, the functions and calls made to the server could end up causing a lot of slowdown for the product and may have to be reworked to allow a faster user experience.

The take-away

All of this is in pursuit of one thing: the better product. It’s why you went and started work to create it, after all. Any testing or user feedback isn’t done out of malice, just the want for a better experience and product. Remember: let breaks create a better experience, don’t take the feedback to heart, take the product from the potentially overprotective arms of their creator and know when to let go of problem areas.

Prep your product, and get ready to seek and destroy.