In North America, the adoption of IoT (internet of things) projects had risen to an impressive 27.5% last year – nearly double of the corresponding figure in 2013. The growing popularity of IoT is evident in the UK too, with adoption rates expected to surge towards the 45% mark by 2020 (in 2015, the IoT adoption here was ~30%). While there are no doubts over the spiralling demands for enterprise IoT applications and smart tools for big data analytics – speculations, however, remain over the usability of the tools currently available. Retention levels are, on average, on the lower side – and in many cases, poorly conceptualized/overcomplicated product designs lie at the core of the problem. To put things in perspective, the overall retention of mobile apps hover in the 11%-13% range after the first week. We will, over here, highlight a few common mistakes that have to be avoided, to ensure that your smart products deliver greater value to end-users:

1. Not adopting an ‘object-first’ strategy

   Designing for IoT is different, and often, rather more complicated that general app design projects. While creating an optimized, user-friendly mobile application (for controlling/monitoring the device, sensor(s)) is obviously vital – you need to focus on the design of the IoT hardware device first. Determine the data capabilities and functionalities required in the device, and develop the ‘smart object’ accordingly. Only when you have a rough idea of how the device will be made and the way sensors will be equipped/embedded/connected to it – should you move on to conceptualizing the app. Making the app first and trying to ‘fit’ an IoT object to it will not be a good idea.

Note: Make sure that there are no ‘points of disconnect’ between the app and the IoT object under question. There should be proper alignment in the actions required to perform the same task on the app and the device (for instance, moving a slider to adjust the volume). Gaps between the physical product (hardware) and the digital product (app) can cause problems for customers.

     2.Making a ‘smart thing’ just for the heck of it

Here’s a rule of thumb: if you are not sure about how a particular component (say, a sensor) will be useful in an IoT product – you are better off not adding it just because you can. Prior to the actual ‘instrumentation stage’, have a clear idea about the reason(s) for which you wish to make an IoT device, the nature and extent of data it will have to collect, and what existing problems it is going to solve. This clear focus will help you in finalizing the ‘intelligent components’ that are necessary for the final product. If you do not do this homework, you’ll end up incorporating too many complicated parts and sensors and processors – and the product’s overall functionality, as a result, will become erratic and restricted. What’s more, indiscriminately adding smart components to the object without analyzing their needs can also open up security vulnerabilities.

Note: Keep in mind that you are creating an IoT product to deliver value to final users. It should never become a platform for you to showcase your advanced tech skills.

3. Not paying attention to scalability

   In 2011, the size of the big data market worldwide was less than $8 billion. Come 2025, that figure will swell to an astonishing $88.5 billion. Apart from the exponential rate of increase in the volume of data handled by IoT – the underlying technologies in this field are constantly evolving too. In such a scenario, if the product you design is not scalable – it is more than likely to become stagnant and useless in a few years’ time (at best). The tool and its operations should be customizable and expandable, to keep it in sync with the changes in technology, capacities, and proliferation of the global smart sector. In other words, the usability of your IoT product should not be adversely affected by technological refinements.

Note: In this context, we should also underline the importance of being aware of the ‘refresh cycle’ of the IoT setups (gateways, nodes, workstations, etc.). This knowledge makes it easy for developers to arrange for timely machine replacements – instead of carrying on with inefficient, outdated systems for long.

4. Allowing users to be distracted

   As you chalk out your IoT UI/UX design plans, identify and mark out the factors that might cause end-users to be distracted (thereby hampering the immersive nature of your product). For example, if a user is prompted to open his/her email to retrieve a one-time password generated by the IoT system – that can be treated as a source of distraction, since the user is being forced to move away from the actual system. Many first-time IoT developers make the folly of being over-concerned with the external competition (i.e., about similar devices being launched by other developers) – and neglect such ‘internal competition’. Remember, if you allow users to navigate away from your product, you are giving them an opportunity to abandon it altogether.

Note: A smart IoT product should, ideally, be not targeted towards a niche audience. While it takes advanced technical expertise and quite a bit of relevant experience to come up with a proper, useful IoT solution – it should be usable by nearly everyone.

5. Not understanding the precise functions

   The speed, battery performance, and overall longevity of an IoT object will critically depend on the nature of functions it will perform. You need to carefully examine whether your system would only collect real-time data from sensors, and pass it on to an external gateway/server for processing – or whether some of the processing will take place in the device itself. For the latter, including automated control functions (with controllers) is essential – and that, understandably, has an effect on battery life. In general, the degree of processing required to be done by the device has to be factored in – to devise the correct design and development plans. If your research on the components to be added on the system is half-baked, the final product will also have glitches.

Note: Developers can either go with a gateway-based IoT network (as in the LoRa star-of-stars network) or a multi-SIM network.

6. Glossing over the IoT security requirements

   From Gmail and Deloitte, to Hyatt Hotels and Equifax – the biggest of players fell prey to serious data breaches last year. As the volume of private, confidential data shared/stored on the cloud is increasing – concerns about hack attacks and unauthorized data access is mounting too. In such a scenario, if the design of your IoT tool has glaring security loopholes, no one will take the risk of investing on it. For a standard IoT tool – you need to pay attention to two things – firstly, the data-level security, and secondly, the device-level security. For the first, strong encryption of all the collected and stored data is important, along with provisioning each smart sensor with external locking systems. On the other hand, device-level security involves using only EPID (Enhanced Privacy Identity) assurance (which significantly reduces hack threats). Avoid trying to cut down expenses by using components with suspect security standards. Every component of your IoT object should be of the best quality.

Note: Specialist app testers and tech device quality analysts are required to make sure that security glitches of any type do not go unnoticed.

7. Considering endpoints to be the only things that matter

   This, unfortunately, is done by many IoT developers – and the backend systems are receded to a secondary role. However, the fact is that on-field sensors and endpoints, data communications & transfer, processing tasks and overall backend capabilities play equally important roles in shaping the quality of an IoT system – and determining whether the final product is indeed reliable or not. The focus has to be on designing an end-to-end IoT solution – one in which no component or segment is given preferential treatment, and the others treated as ‘less important’. At the time of conceptualizing the object, think of how you can create a ‘complete system’ – and NOT a particular hardware component per se. A holistic IoT system works – something drawn up in a piecemeal manner never does.

Note: Due care has to be taken while checking all the features of the app as well. Even seemingly minor oversights can affect the adoption figures of your product and the app.

8. Not keeping things simple and not creating value propositions

   If the learning curve of your IoT tool is too steep, expect many prospective users to drop off and start looking for an alternative. Hardly anyone – however tech savvy and enthusiastic they might be – will be willing to go through elaborate instruction manuals to ‘learn’ about your product. This, in turn, brings to light the importance of implementing a simple, intuitive design scheme (for the device AND the app) – one that the majority of users will find it easy to understand and play around with. Relevance, portability and compatibility are the three pillars that an optimized IoT design plan should be based on.

The other factor that needs to be highlighted here is the need to make people understand the benefits of the product. Do not make the mistake of simply rattling off the technical features of your device – and concentrate on sharing its value propositions instead (i.e., the requirements/problems that it will solve). This will: a) get the target users interested, and b) help you establish a relationship with your customers. Over time, you can keep them informed about the biggest USPs of your IoT device, and clarify their queries. Use the mobile app to publicise the value propositions of your IoT tool. The first-time user experience (FTUE) is critical – and if your product does not ace it, it is most likely to fail.

Note: When you create an IoT-powered system (a ‘connected system’), your objective should be to make the lives of the end-users smarter, simpler and more convenient. The overall UX needs to be top-notch – and all the operations should be user-focused.

9. Not being aware of how data communications will take place

   Seamless communications with the internet lies at the core of every IoT system. As the developer, the onus is on you to know from beforehand whether cellular data (SIM-based), or wifi (if yes, the generation), or LAN (with USB) will be used to establish and maintain the communications. Determining the network connection(s) is vital for designers in a multitude of ways – right from determining the control and/or processing powers required at the endpoints, to the volume of data that is to be transferred from one point to another (say, from the device to the central server). In addition, the reliability of connections in rural/semi-urban locations also have to be taken into account. Gather thorough information about the available technologies at any place, and the likely behaviour-flow of users on your IoT device and app. Based on this, you will be able to determine the most suitable method(s) of communication.

Note: In a business environment, IoT systems have to handle huge volumes of data. The chances of your product’s success crucially hinges on how well it can transform such data into structured, insightful, actionable information.

    10. Not paying attention to the unique requirements of users

Designing an IoT solution is far from being a ‘build once, use everywhere’ task. Data can come in from multiple sources – and you need to find out what type of information a certain group of users (say, crop-growers using an IoT-powered agritech device for the first time) would require. You can then make the object customized, so that it supplies precisely the type of service that would deliver value for any user. Ready availability of relevant, personalized and accurate data is the thing that makes a ‘connected device’ deliver greater value (than traditional devices). The needs of a farmer are radically different from someone looking for a smart home automation tool, or those of smart city planners. You need to be able to mark out the specific needs of each type of user, and customize the operations of your IoT product accordingly.

Note: Data staging and intermediate data processing are also things you need to consider, if the collected data has to be moved to a centralized server or gateway for processing. That will enable stronger security standards, better control parameters, and will also reduce the volume of data to be transferred.

     11. Confusing quality control with testing

If you start paying attention to the quality of your IoT product only AFTER the testers have found a couple of serious faults in it, your approach is seriously wrong. Make it a point to use only such standards and processes and frameworks that come with verifiable certifications – and check whether their performances are affected under any circumstances. Instead of relying upon the testing phase to find out your design mistakes, treat it as an opportunity to confirm the ‘correctness’ of your IoT tool.

Speaking about testing, things here are not exactly the same as that for standalone mobile apps. For starters, there is no scope of treating the first set of customers as the ‘beta testers’ (if the negative word-of-mouth reviews spread, that can spell the end of your device). Also, for sensors and gateways placed on-field (maybe at remote locations), it is next to impossible to update them frequently. Test your IoT product during every stage of design and development. Only well-tested, uniformly efficient connected devices can deliver incremental value to users in the long-run.

Note: For selecting processors, network protocols, radios and other key components of the system, creating a mesh network generally proves to be handy.

     12. Making subscription/sign-in mandatory from the very outset

The IoT product you have created might be of great value. It might offer real benefits, be qualitatively excellent, and have a series of high-utility features. All the good work can, however, be undone – if you do not offer the people the opportunity to check out some of the important features of your product, without having to sign in. A potential user would, understandably, like to play around with a new IoT system for some time – before actually deciding to purchase it/subscribe to it. Never take it for granted that everyone would like to be a ‘captive customer’. Give people the chance to preview your product for free – be impressed by what they see, and THEN sign up or subscribe.

Note: An interactive tutorial can go a long way towards familiarizing new users with your IoT solution.

Avoid giving too many alternative options in the app or the device, which might confuse users. Make sure that there is a seamless integration between the online functionalities and the regular, offline experiences (IoT-based RFID in retail stores, for example). You might also consider the option of using ready-to-use platforms like Xively and Ubidots for IoT development. Such platforms have many useful built-in features (like analytics) – and they make the task of creating a powerful, well-rounded IoT tool that much easier.

Although the average cost of IoT sensors is steadily falling (estimated to be around $0.44 by the end of 2018) – it still requires considerable investment to make an end-to-end IoT system. User-retention is extremely important – with recent researches showing that the cost of acquiring new users can be up to 5X more than that of retaining existing users. Designing for IoT can be tricky – and you need to stay away from the above mistakes to give your product a chance of success.

P.S.: Did you know that we recently launched the first prototype of our breakthrough IoT agritech device, powered by LoRaWAN? For the entire news, head over to https://prwire.com.au/pr/75515/teksmobile-releases-first-prototype-for-agritech-iot-tool-1.