Direct Design, Data and the Future

When my kids were younger, they liked to play the game of Telephone with their friends. If you’re not familiar with the game, it begins with one person telling something to someone else, then that person repeating it to someone else and so on until the information has gone through the group and back to the person who originally provided the information. After going through so many people, the information would invariably be some giggle-inducing, garbled version of the original.

It’s not just kids who have a tough time communicating what they’ve heard. We played the same game in a college journalism class to underscore the importance of first-hand information and not relying on a single source when reporting a story. No matter how hard we tried to accurately relay what we heard from one student to the next, the information would always come back differently than what was originally conveyed.

For reporters, the phenomenon can lead to some embarrassing headlines. For design engineers, it can mean the difference between producing a product your company’s customers will love and something that they won’t buy. It might mean producing something that is over-engineered for how it’s really being used, or something that fails when used in actual field conditions.

Real-Time, Real-World Data

Simulation, prototyping and testing catch most of these issues before a product design makes it to the factory floor. Engineering teams make extraordinary efforts to ensure the products they’re designing are safe, reliable and marketable—investing considerable time and expense in the product development process. But what if design decisions could be based on more real-time, real-world data? Instead of getting product use information filtered through a Telephone-like game of sales figures, maintenance records, focus groups, test data and more, a direct data route would not only help ensure the integrity of the information, but could also save product development time and expense.

That’s one of the exciting promises of the Internet of Things (IoT). Predictions for the future include products “phoning home” when they are about to fail, or to provide a stream of actual usage data that can become the basis of improving the next generation of products. It sounds a lot like what happens when a software application crashes and a window pops up asking you to send a report back to the vendor. But what happens to that data once it’s submitted? How is it collated and acted upon?

Not So Fast

We can assume that such real-world data would be worth the time and expense involved to make some products “smart” with various sensors to detect issues and the technologies needed to communicate those issues. Let’s also assume that the security concerns threatening the IoT will eventually be mitigated. Even after those two high hurdles are cleared, there is still the issue of making sense of all that data.

There is already an over-abundance of data, much of it not being effectively harnessed to improve product design. Why? Because collecting, filtering, disseminating and analyzing massive amounts of data is still a huge challenge. It requires a workflow, IT infrastructure and advanced algorithms that don’t yet exist in most organizations. Adding more data to the mix without an efficient system in place to handle it would only exacerbate the issue.

Many of the titans of technology are focused on growing the IoT and bringing the benefits of Big Data to more and more organizations. Depending on your industry, the use of real-time, real-world data may only be a matter of time. However, especially in these early days, design engineers should consider the source of the outside data coming in. The filters applied to the data that are intended to make it useful should also be thoroughly vetted. Just like in the early days of simulation solvers, you shouldn’t trust the algorithms to be perfect right out of the gate. An automated process of relaying Big Data may not be plagued by the same issues humans are when playing a game of Telephone, but the old computer programming adage “garbage in, garbage out” still applies.