Designed process

Design Process: 16) Test and Try to Break


As the build phase comes to a close, the team will review the development work and make note of what is and what isn’t correctly done.

Many developers don’t have the attention to detail that most designers do, so this is more of a double-checking that everything is as expected.

Testing should not be new to the team, as they should have been testing things throughout the entire time the developers have been working. 

The team should check what the site looks like in multiple different browsers on multiple different devices and platforms. They shouldn’t just test in Chrome and determine that the site “looks good”. They should try to break the site and then note any successful attempts to the person in charge of QA.

Sometimes, though, the development will go off the rails. It could be that something was missing (it shouldn’t be at this point), or there could have been miscommunication to the developer, or the developer just decided that their idea was better than the design.

Whatever the reason is, there needs to be a frank discussion regarding why the finished product doesn’t look like the design.

It’s at this point where problems can arise for a myriad of reasons. If the product doesn’t look the way it should, the Creators get angry, and they have every reason to be. After all, the design that they poured their soul out for and every pixel they agonized over should be correct. However, it’s important that everyone assumes positive intent in anything that is different.

Were they told by the Owner to do something and it wasn’t communicated to everyone?

Did the Builder discover something during the build phase that they needed to change for a certain reason and it didn’t get communicated back the the Creator?

Maybe the Builder didn’t understand how to do something and what you are seeing is the best they could do.

In any case, it’s best to approach that situation without hostility.

If after this conversation things still aren’t resolved, then escalate the problem to the Owner to force the issue. It is their job to ensure the product is what it was designed to be.

Possible Pitfalls

If you fail to do this, you will have a broken product with a ton of bugs, and your users will not be happy.