Over the last twelve years, Untitled Kingdom has helped dozens of companies design and develop apps for IoT devices. We’ve seen successes, mistakes, and everything in between. If you’re creating an IoT device, keep these 4 tips in mind:
Your choice of communications protocol should derive directly from your necessary functionality and customer pain points. Technology is just a tool, so choose the one that fits best.
Bluetooth Low Energy (BLE) is not optimized for transferring large amounts of data, yet we’ve seen it over-selected time and time again. Last month, for example, a customer approached us with plans to incorporate both BLE and Wi-Fi in their device. After analyzing their requirements, we came to the conclusion that a single communication protocol was sufficient and would lower their costs of both their hardware and software development. To avoid these and similar pitfalls, follow these steps:
In creating medical devices, we’ve learned many strategies for ensuring their security quality. While threat modeling is a legal necessity for these medical devices, we’ve found it also worth the cost for folks creating consumer goods.
We were recently brought on to help a client who hadn’t aligned their engineering and product teams. Their device required many commands, each command taking hundreds of milliseconds. The engineers had made everything work… but hadn’t factored in the user experience. From the product perspective, we reapproached the problem, asking, “What is the outcome we want?” not “What are the commands we should use?” We re-optimized the hardware’s interface, resulting in a single command call instead of dozens, a huge improvement in the user experience by saving multiple seconds for each interaction. Other teams can have similar blindspots, so increasing cross-discipline communication helps ensure the final device is a success.
Documentation, similarly, is typically nonexistent or out-of-date. Organizations want to take their product to market as soon as possible so they sometimes skimp on documentation. It is, however, crucial for the product (especially for regulated products like medical devices) and two simple habits can make it more tolerable:
Developer modes allow engineers and QA team to test individual pieces of an app without waiting for a connection. In one implementation, we skipped the device’s connection verification, saving an enormous amount of time over hundreds of tests.
Simulation modes show mock data that permit you to test specific states quickly and hustle free. These can also benefit for automated UI tests or screenshots generation in different languages or a demo mode for users without the real device.
Simulators use sliders and buttons to imitate specific device states on demand. Through a simulator, we can test activities that would otherwise be cumbersome, like the app’s behavior at low battery without waiting for it to discharge. These simulators also permit us to perform a two-point check between the client’s documentation and its hardware. We build our simulator based on the client’s specifications, so any errors in those documentation specs will become glaringly obvious if there is a problem when we incorporate the software with the real hardware. This strategy permits us to find any mistakes and pinpoint who should fix it, saving time and creating a win-win-win!
If you’re testing a device, these three optimizations can save you countless hours, allowing your engineers to spend their time on value-creation instead of testing, bringing the costs of development down.
Are you creating a connected device? Contact Untitled Kingdom to see how they can help.
1. Choose the correct communication protocol or pay for it later
Your communication protocol is the core of your connectivity, which is itself the core of your connected product. A small mistake here can cost multiples down the road.Your choice of communications protocol should derive directly from your necessary functionality and customer pain points. Technology is just a tool, so choose the one that fits best.
Bluetooth Low Energy (BLE) is not optimized for transferring large amounts of data, yet we’ve seen it over-selected time and time again. Last month, for example, a customer approached us with plans to incorporate both BLE and Wi-Fi in their device. After analyzing their requirements, we came to the conclusion that a single communication protocol was sufficient and would lower their costs of both their hardware and software development. To avoid these and similar pitfalls, follow these steps:
- Don’t build until you’ve selected a protocol Many device designers are excited to get building. If they have a technical background, this can cause them to create pieces of the product using their existing expertise. This may be effective for a proof-of-concept, but is important to rethink when building the real deal. If you have expert knowledge, be sure to verify your choices to ensure you’re not forcing it.
- Consult a connectivity expert as early as possible Thanks to IoT’s popularity, you can find many specialized resources to help design your product. Start by consulting charts online that explain protocol pros and cons. Then, ask an expert. They may have earned wisdom suggesting an individual choice would be a terrible mistake. This expertise is typically highly accessible. At Untitled Kingdom, for instance, we run intensive workshops to analyze pain points and design products, including a focus on this very topic.
- Ignore technical advice from laypeople Investors, non-technical teammates, and the media often make technical suggestions. These can lead to poor choices, like the many companies inappropriately incorporating blockchain in their business.
- If you’ve selected an unpopular protocol, reconsider In connectivity, the standard protocols are the standard for a reason. Most devices are best served by using one of these common choices. If you do select an unpopular protocol, you’ll find fewer specialist engineers and less overall support. These unpopular protocols force their device designers to figure out more on their own, although engineers like challenges.
- Pay for top-quality connectivity engineers and parts In some areas, cost-cutting is financially feasible. In connectivity, these costs generally come back to bite you.
- When you make the right choices, it will click In communication and connectivity, small mistakes can cause big problems. Within two weeks of working with a recent client, we accelerated their bluetooth connection time from 18 seconds to 3 seconds.
Choosing the wrong connectivity protocol is like building a house on an uneven foundation. You might be able to make it stay up, but it will eventually require an exorbitant amount of support and workarounds.
Before you build, be sure your protocol suits your needs. Choosing the right technology today saves you from employing many expensive engineers to prop up this mistake.
We’ve seen companies choose an inappropriate protocol based on its popularity (like BLE when they need high data transfer). Technology fads come and go. Don’t build your business based on a buzzword.
Engineering mistakes are exorbitantly costly to fix after they’re committed, and unstable parts can sink a product. When running a business, it can be tempting to cut costs. Top engineers and known brands, however, can be the difference between a functional product and a forced redesign.
Technology is just a tool, so choose the one that fits best.
If your device depends on connectivity, your business is based on choosing and implementing the right protocol. Don’t leave it up to chance.
2. Security threat modeling is worth your time
Every device should consider security. Simple threat modeling procedures can identify loopholes and possible entry points inexpensively and effectively. When you’ve identified the dangers, you can consider countermeasures based on the cost and probabilities of each type of breach. This process provides high value for very little time.In creating medical devices, we’ve learned many strategies for ensuring their security quality. While threat modeling is a legal necessity for these medical devices, we’ve found it also worth the cost for folks creating consumer goods.
3. Internal communication is key
To create a profitable product, your product team must effectively interface with engineering. If you start with this pair working hand-in-hand, you’ll avoid dangers down the line. If you instead wait until the device is ready for production, you may need significant changes that send you back to the drawing board.We were recently brought on to help a client who hadn’t aligned their engineering and product teams. Their device required many commands, each command taking hundreds of milliseconds. The engineers had made everything work… but hadn’t factored in the user experience. From the product perspective, we reapproached the problem, asking, “What is the outcome we want?” not “What are the commands we should use?” We re-optimized the hardware’s interface, resulting in a single command call instead of dozens, a huge improvement in the user experience by saving multiple seconds for each interaction. Other teams can have similar blindspots, so increasing cross-discipline communication helps ensure the final device is a success.
Documentation, similarly, is typically nonexistent or out-of-date. Organizations want to take their product to market as soon as possible so they sometimes skimp on documentation. It is, however, crucial for the product (especially for regulated products like medical devices) and two simple habits can make it more tolerable:
- Document in precise and dense language. It might seem like a good idea to write many sentences describing the feature, but someone will later need to read your documentation, and multiple pages to understand a single feature is too cumbersome to consume.
- Whenever you introduce a change, update the documentation. It can be tempting to plan to “document later.” This can cause documentation to pile up, creating overwhelm when you ultimately get around to it.
- Have your product team create the first draft of your documentation.
- As your development team builds, they edit and add to the documentation.
- When performing quality assurance, your QA team verifies every piece acts according to its documentation.
- If everything Is accurate, you’re good to go. If not, each team along the way can update the documentation.
4. Expedite your testing through developer modes, simulations, and simulators
Testing the app with your device can be cumbersome, time-consuming, and expensive (or impossible when the device is not yet completed!). Imagine waiting for a device to boot up each time you want to test it. For testing purposes, these repetitive elements should all be optimized.Developer modes allow engineers and QA team to test individual pieces of an app without waiting for a connection. In one implementation, we skipped the device’s connection verification, saving an enormous amount of time over hundreds of tests.
Simulation modes show mock data that permit you to test specific states quickly and hustle free. These can also benefit for automated UI tests or screenshots generation in different languages or a demo mode for users without the real device.
Simulators use sliders and buttons to imitate specific device states on demand. Through a simulator, we can test activities that would otherwise be cumbersome, like the app’s behavior at low battery without waiting for it to discharge. These simulators also permit us to perform a two-point check between the client’s documentation and its hardware. We build our simulator based on the client’s specifications, so any errors in those documentation specs will become glaringly obvious if there is a problem when we incorporate the software with the real hardware. This strategy permits us to find any mistakes and pinpoint who should fix it, saving time and creating a win-win-win!
If you’re testing a device, these three optimizations can save you countless hours, allowing your engineers to spend their time on value-creation instead of testing, bringing the costs of development down.
Conclusions
From wearables to small businesses, IoT is a large and growing industry. While many pitfalls exist, the risks are often worth the reward. Experts’ earned wisdom--like those on Ioterra--can be the difference between taking an idea to market or redesigning again and again. Watch out for these challenges and ask for help.Are you creating a connected device? Contact Untitled Kingdom to see how they can help.
