Now for the part where we break the design
Design makes stuff. Design is also about breaking the stuff. Or should I say, breaking stuff is an essential part of design.
Designs have a specifications part in it which guide the developers how to navigate through the designs and build it exactly the way it was conceptualised. Once a software product gets designed and developed, it goes through QA or testing to make sure that the product was built the way it was intended. In software industry there are separate teams who carry out this part but I, being a designer, have had the opportunity to be a part of this process and witness the wreckage of product and its design myself. Testing is important so that the faulty parts of the product can be fixed before our users can reach there. Being accomplice to breaking my own designs and testing the product has given me insights to creating better designs.
It’s easy to think of testing done by designers in areas such as industrial design. Watching Deep Dive — a classic workmanship of building a product by IDEO, you see how these guys first build a product then also test it by using it the way a user would. For softwares, one team designs it, another builds it and yet another tests it, ofcourse with a great collaboration and synchronisation. Testing done by designers returns feedback back to step 1 of building the product.
Without testing…
I can’t say if I could have written elaborate, in-depth specifications which made sure that all the cases got prepared and tested at the design stage itself — to avoid room for any faulty parts at all after development. Designs are generally the ideal versions of products which cannot be used by anyone, only speculated with. And hence testing it isn’t a very simple process without prior experience. Otherwise design itself should be a working model that can be used at the time of conception.
As I continue to test the products, I get that much more prepared with the cases where design can break for the users. This way the cases can be taken into account during development and not lead to faulty parts.
Example:
A lot of times things break because of the process or handing information from design to development (or even idea to design for that matter )— whenever thoughts exchange heads. That’s why we have specifications in going from design to development to signify that the design has done its experimentations and now it is ready for building in the exact specs. Since I am able to see why and where things break through my testing, I am also able to write better specifications. Just by seeing where my designs can break after it gets built, I can take measures while designing, to create specifications that allow an enhanced craftsmanship in building it.
I believe all designers should be a part of this process in some part of their design journey and if not, they should get access to failed test cases and feedback for review so that their own design insights can be generated from it.
