Part 2 of 3 (Engineering): How to score a touchdown in IoT home product and experience design

November 02, 2015

In part one of this series, I shared strategy tips for winning with smart home products in a cluttered, competitive field.

Below are a few nuggets on how to make engineering calls that will help your project team reach the goal line with technology that scores points with users.


Validate key technical assumptions early on

In engineering terms, this is usually done by building low-fidelity prototypes, and proof-of-principle models. The former will tell you if all the pieces of the puzzle will work together (i.e. do the electrical and mechanical features work in synch or is there unwanted interference?). The latter will help you verify whether a specific piece will do what it’s supposed to do (i.e. will the sensor function at various temperature ranges or will it fail once it gets below zero?). This may seem fairly obvious, but it’s not always practiced. Don’t shortcut the process you want to eliminate major risks as rapidly as possible before throwing more money into your alpha or beta products.

Don’t over-engineer a device without getting market feedback

Conversely, teams can get carried away building complex products when a simpler solution would suffice. Take a page from the Lean StartUp movement and answer the following: “What is the minimum I must build in order to answer my riskiest assumption?” I’ve seen an engineering team spend weeks, if not months, ensuring their gadgets can connect to so many protocols and devices when a less expensive, bare-bones solution would’ve gotten them more market share faster. You can always add more features, and increase price, once you have customer traction.

Teams can get carried away building complex products when a simpler solution would suffice. You can add features and increase price once you have customer traction.

Don’t over-engineer the app

I’ve also seen apps that have so many features and ‘rules’ that they border on remote-control-button-overload syndrome. Keep the “if-then” statements simple. As a rule of thumb, if it takes more than three steps to program a device to do something based on another action, you better simplify the logic. Here’s an example:

Step 1: select the device and rule (i.e. if motion sensor is triggered)
Step 2: select another device and action (i.e. then turn on living room lamp)
Step 3: refine the action (i.e. but only between 6 p.m. and 10 p.m. daily).

Never stop testing — even after you’ve launched

If you’ve fiddled around with any “smart” home technology, then I’m certain you’ve experienced the frustrating delay from when a sensor is triggered to when an action or notification should occur. In fairness, this has less to do with engineering and more to do with the speed of the signal going from your smartphone to the cloud and back to your device, but customers shouldn’t have to suffer from this latency. This reminds me of a home alarm I tested using a geo-fence feature (that’s a fancy word for connectivity radius from a hotspot). Every time I pulled into my driveway at night, got out of my car and opened the door, the house alarm would briefly sound, earning me a few disapproving looks from my next-door neighbors. I ended up removing the alarm after the third incident.

Last but not least in testing, eliminate any false positives or your customers will start to lose faith in your technology. I had a friend get a kitchen smoke notification while she was at work, only to verify with her mom who was visiting that there was no issue whatsoever. I asked her “What if your mom had not been there to verify?” She said, “Then I would’ve had to call a neighbor or drive 30 minutes just to find out nothing had happened.” Let this not be the outcome of your IoT products.

Look out for the final part of this smart home trilogy — scoring a touchdown with design!