Designing better connected devices

These devices can receive data, allowing commands to be sent facilitating remote control. Likewise, contextual information from the web (such as meteorological, calendar, and location data) can also be passed to the device. At the same time, data can also be passed in the other direction, from the device, covering aspects such as the need for service or consumables, along with details about its surrounding collected via sensors.

These connected devices often come packed with cheap and accurate sensors that allow the devices to collect data on the temperature of our homes, the heart rate of our children, and even how quickly they are eating their soup. Through an internet connection, users are able to have near-real time access to this information from the other side of the globe.

And sensing is just the start. Many connected devices also have the ability to work autonomously. Devices can analyse the sensory data that they collect, orientating it to the specific context in question, decide on the best course of action, and act – all without any human involvement. Likewise, these four aspects of a decision making cycle (sense, orientate, decide and act) can be divided up in different ways between a human and the device – allowing decision making and control to be shared in various ways. Thus, the possibilities for collecting data, analysing it, deciding what to do, and acting are almost unbounded. The real question then becomes: ‘just because we can connect things, should we?’

Connected devices are big news; early incarnations, such as the Nest learning thermostat proved to be incredibly successful – redefining a product category. As a result, many companies are adopting a ‘do or die’ philosophy racing to develop connected variants of their existing products based on a very real fear that their existing competitors, or completely new entrants to the market, will redefine user expectations.

One school of thought is that simply having a connected device is enough and that we should put these connected objects out into the world and see what emergent behaviours develop. Manufacturers can often develop a ‘minimum viable product’ by simply connecting an existing product and exploring how users respond to the new proposition. This almost Darwinian approach to product design is quite simply a survival of the fittest. The products that add value to users’ lives will prevail, while those that don’t are destined for failure. The risk with this kind of strategy is that products will be developed that fail to offer users any real advantage over their non-connected donors – resulting in reputational damage for those releasing them.

So what’s the alternative to this ‘suck it and see’ approach to design? As obvious as it may sound, perhaps the best answer is to start by explicitly considering, and defining, the product need. This involves describing exactly what the product is required to do and how it may help shape the world. A series of questions can then be used to drill into the detail of the product definition:

1. Where is the value?
2. What should it do?
3. How should it communicate?

1. Where is the value?

In the vast majority of cases, a connected device will take the place of a non-connected device in an existing system. As such, it’s important to understand how the connected device could change things. It can be tempting to become bogged down in the technical details and specification of the device, but often the best place to start is with the broader proposition. One useful way of considering this is to start by establishing the purpose and the performance of the system that the device inhabits. This then forms a baseline benchmark to assess the proposed changes against.

The metrics used to assess the performance of the system will change depending on the application; however, they will normally include descriptions such as effectiveness, efficiency, safety, inclusiveness, satisfaction, and flexibility. If the introduction of a connected device is not expected to impact these performance metrics, then the value of the product can be quickly called into question. It’s also important to track them all in parallel to ensure the optimisation of some doesn’t negatively impact others.

2. What should it do?

The question of ‘what should the device do?’ should be informed by the understanding of the broader system and the metrics that should be prioritised. Stepping down a level of detail, as we have already shown, decision making is quite a sensible place to start when defining exactly what the device should do.

In the first instance, it’s advantageous to think about the decision making process (sense, orientate, decide, act) independently of who will be doing the task (a human or a connected device) and to define what needs to take place. This starts by exploring and defining the type of information that may allow better decisions to be made. This might include information that can be sensed directly (such as sounds, temperatures, speeds etc) or data that can be collected from information feeds on the internet (such as traffic jams in the local area, weather forecasts and pollen counts). Likewise, an understanding of the way this information could be analysed and how decisions could be made both shape the function of the device. Finally, the options available for action and the way in which these actions can take place have their role to play.

Once the decision making process is understood, the next step is to start to define who in the system should take responsibility for each part. In some cases greater convenience will be gained by the device taking complete control of the decision making process. In other situations, this may be unpalatable and some form of human-in-the-loop involvement will be necessary or desirable.

3. How should it communicate?

Once the responsibilities and function of the connected device have been defined, the next stage is to explore how it should communicate. The vast majority of devices are now connected wirelessly, but there are a number of frequencies and protocols that that they can use to communicate. Most consumers will have heard of WiFi and Bluetooth, but there are other alternatives that have their individual merits in terms of cost, performance, compatibility and ease of integration.

The form factor and the ability to provide power will both influence these decisions. In some cases products will be expected to communicate in an incredibly power efficient way, and this may dictate the communication method adopted.

Again a system level view is also very important. It is critical to think beyond the device and consider the whole ecosystem it will work in.

The ‘layer cake’ diagram below has been developed within DCA to clarify the options for connected devices.  We have found it a powerful tool in establishing and validating the specification of a new connected device proposition before diving into the development work.

Each layer of the diagram can be considered as analogous to a step in the process of verbal communication. The choices made in each layer of the diagram will be driven primarily by the device’s functionality and the environment in which it will operate.  These decisions will determine the device’s complexity and hence its size, cost, power consumption and development timescale.

At the top of the ‘layer cake’ there is the Application layer. Here the high level decision on what you want to say must be made – what information should the device transmit, maybe temperatures, sensor data or location. In some cases, it will be acceptable and desirable to use existing Apps to send, receive and process the data. In others, bespoke applications will be favoured.

In the next layer (the Interoperability layer), the decision to make is which communication language to speak – English, French, WeMo or SmartThings – or which ecosystem to buy into. There are many existing languages to choose from, each with their own characteristics and strengths, including those created and supported by technology giants such as Apple (HomeKit), Samsung (SmartThings) and Google (Weave). There is also an opportunity to develop bespoke languages, as Honeywell have done with their EvoHome system.

Moving further down our ‘layer cake’, in the Data transfer layer a protocol must be decided upon (akin to deciding what words to use and which sounds to make). Bluetooth and Wi-Fi are the most widely known, but other alternatives, such as Z-wave or ZigBee, offer an interesting alternative if bandwidth requirements are low as the cost of such systems may be much lower (although additional infrastructure, such as a hub, may be required).

Finally, at the base of our diagram (the Physical layer), the way of making sounds – for instance with a mouth or a loudspeaker – is analogous to the decision between wired and radio communication. For simplicity, the diagram shown here focuses on radio communication, as this typically offers the greatest convenience for installation, but there may be cases where a wired connection is preferred (e.g. due to concerns over stability, security or interference).

Conclusions

Connected devices stand the greatest chance of success if their value, over and above the non-connected products they are due to replace, is explicit. While an understanding of user needs and of market value forms a solid starting point, an in-depth technical understanding is required to identify and deliver the appropriate options at each level of the particular connected device’s ‘layer cake’. As an example, the specific route through from the Application to the Physical layer for a Belkin WEMO device is highlighted in the diagram below.

Given the diversity of these skill sets, multidisciplinary teams are required to define and develop meaningful and commercially successful connected devices.  In particular, experts in user focused product development need to work closely alongside electronics and software specialists.