Standards Testing is Not Enough, Build a Quality Checklist Specific to Your Product
A ‘product-specific quality checklist’ is a set of functional, repetitive, use-and-abuse test criteria built around what your product needs to survive, in addition to any mandated or voluntary safety certification. It matters because a generic checklist, even a fully certified one, was never designed to catch the failure points unique to your product.
A Certificate Is Not the Same as "Safe"
There is a common assumption in product development that getting a product tested to government-mandated or industry standards, and getting the certificate to prove it, means the product is safe. That it has been tested to everything it needs to be tested to. It has not.
Safety standards, especially for toys, are clearly mapped out, but they are also generic by design. They cover a broad category of risk, not the specific risk profile of your product. Take a "step on" risk as an example. If your product is likely to sit on the floor pointing upward, the force involved in someone stepping on it is much higher than what current toy standards test for.
Safety testing is only a fraction of what a proper quality checklist should include. Functional requirements, repetitive use tests, and abuse tests (developed in the design and development stages) belong in the inspection criteria used at both in-line and final inspection, alongside whatever mandated safety testing applies. Making a product and getting a test does not show the product is fit for purpose or robust. And that can cost you much more in the end.
Functional Testing Starts in Development, Not at Inspection
Functional testing should confirm a product works as intended, and that process starts in development, not inspection. We worked on a can holder where the original design brief showed cans in a bag with no dimensions specified. What the customer did not know was that international can sizes are smaller than Australian ones, and the factory's original quote, before we got involved, was based on the smaller size.
That problem was fixable. But fixing it once is not the same as making sure it stays fixed. Every change made during development needs to be recorded and carried all the way through to inspection, which is why sample cans need to physically be on hand at in-line and final inspection to confirm fit, not just noted as resolved on a spec sheet somewhere.
Brainstorming Abuse Tests Catches What Approval Cannot
A model can be fully approved and still fail in ways nobody anticipated, because approval usually tests intended use, not real-world abuse. On a custom money box project, the customer had already approved the model. After the first shot came off the tooling, we brainstormed use and abuse tests for it anyway. Filling it with coins and shaking it, the way a child actually would, caused the coin access latch to come off entirely. Improving the tooling at that stage avoided a genuine safety issue, coins flying loose, that the original approval process would never have caught.
We ran a similar test on a backpack, filling it with bricks and spinning it three hundred times to simulate a year of a child carrying books to school. That test found a weak point in the stitching, which we improved. The same test was performed again at final inspection which caught a faulty clasp that was completely invisible on a visual check. Every clasp was replaced before the product shipped.
Setting the Test and the Benchmark Together
Ikea famously displays a chair stress tester in its stores, a machine that simulates someone sitting down on the chair repeatedly. That is a good model for how functional testing should work: define the test, then define the benchmark. How much weight, how fast the motion should be and how many repetitions… one hundred cycles, five hundred cycles, whatever is appropriate for that product's real use case.
Our approach is to work with the client to set both halves of that equation together, the physical test and the number that counts as a pass, so everyone agrees in advance what "durable enough" means for that product. This provides very clear expectations for the factory at the start and avoids the divide in quality definitions that often occur after the product has been produced. Expert Insight
"The best packaging decisions we make happen early in the development process," notes the Tincat design team. "By the time a product is finished and someone asks us to 'just sort out the box,' we have already lost the chance to build genuine value, security, or unboxing delight into the design itself. Packaging deserves a seat at the table from day one, not a slot at the end of the timeline."
Sometimes You Just Have to Use the Product Yourself
Not every failure point needs a machine to find it. While developing a tent, we assembled it in the Chinese hotel’s outdoor grass area! We did not have a hammer on hand for the pegs, so we used rocks instead. We quickly discovered that hitting the peg anywhere other than dead centre on its head caused it to bend and become useless. That led us to recommend a stronger peg in the final specification. The cost difference was negligible. The improvement to actual customer experience (and the reduction in potential returns) was significant. One amusing morning (many years ago) I remember being shocked coming into the office to see two senior managers roughhousing in the boardroom. They had hold of each other’s tops and were trying to throw each other around the room with them. It was then I found out that the new sports tops had arrived, and they were ensuring that they would not rip on TV when a professional team started wearing them!
“Functional testing starts with using the product yourself.”
Expert Insight
"Third-party testing is genuinely useful, and we are not suggesting anyone skip it," says the Tincat team. "But a certificate tells you a product meets a general standard. It does not tell you whether your product is robust enough to deal with what your customer will do with/to it. Determine what the product is supposed to do, build a test that simulates it, then brainstorm the ways a customer will vary from that intended use. Clear, measurable functional requirements give the factory a real target, give inspectors something concrete to check, and it will cut down returns and defects more effectively than a generic checklist ever will."
What This Means for Your Product
Do not treat certification as the finish line for quality. Build functional tests around what your product specifically needs to survive, record every development change and carry it through to inspection, and brainstorm abuse scenarios even after a model has already been approved. The small, sometimes low-cost fixes this uncovers, a stronger peg, a redesigned latch, are almost always cheaper than the returns and safety issues they prevent.
Get a quality checklist built around what your product actually needs to survive, not a generic template. Contact Tincat
Frequently Asked Questions
-
A: Certification confirms a product meets a general industry or government standard, which is necessary but not sufficient. Standards are written broadly across a product category and often miss risks specific to an individual product's shape, use case, or intended environment, which is exactly what a product-specific checklist is designed to catch.
-
A: As early as development itself, and again at in-line and final inspection. Waiting until final inspection alone misses the chance to catch problems while they are still cheap to fix, and skipping abuse testing after a model has already been approved leaves real-world failure points completely untested.
Written by the Tincat Team