Design for connected systems, not connected products
Reading time: 7 min
The more a product is to become part of a connected system, the more attention product designers must dedicate to the system idea. Connected products should give the user the feeling of interacting with a holistic system across device boundaries, not a bunch of separate devices. See also interoperability and interusability as two of the key challenges in developing networked HVAC products.
Product developers must therefore be willing to compromise and subordinate design decisions for product A in favour of their interaction with products B or C. Only in this way will the whole become greater than the sum of its parts.
We speak of product systems, for example, when an HVAC product is to be positioned as part of a smart home system, integration into building management systems plays an important role, or in order to offer a modular, harmonised product portfolio as a manufacturer. While the former cases dictate many design decisions to the manufacturer in order to comply with the existing standard, he has a free hand within his own portfolio.
In any case, three important aspects should be considered when developing connectable products so that they contribute to a well-designed system: composition, consistency and continuity .
The composition of connected systems: Which device offers which functionality?
In a connected system, it is necessary to carefully plan which device should provide which functionalities and how they should interact with each other. Examples:
- What operations are performed on a room thermostat or the associated heating controller?
- Which data should be stored directly in the electronic memory of a boiler control, an SD card, or on a cloud server?
- Which path does the data take through the system, for example from device A via device B to device C, or directly from A to C?
- Which devices should get their own user interface, and how will devices without an own interface be operated? (see also Smartphones as operating devices for heating systems)
Apart from the technical effects, composition is also crucial for the perception of usability. Indeed, an important determinant of usability is the match between composition and the user’s mental model – that is, their understanding of which device they expect a particular functionality to be in and how it relates to the other devices.
The better the system behaviour matches the user’s mental model, the higher the usability. On the other hand, the more the user has to readapt his or her mental model due to a deviating system behaviour, the more he or she pays a lesson.
Consistency: the common thread through multiple user interfaces
Connected systems often contain several devices with their own user interface. If these are to work together across manufacturers, such as in smart home systems or the patchwork of a gradually retrofitted boiler room, this usually results in completely different user interfaces. Since each component manufacturer pursues its own philosophy, this is difficult to resolve.
Within a complementary product range developed by the same manufacturer (or a manageable cooperation network), the conditions for a consistent operating concept are much better, but are also expected all the more by the user.
The aspect of consistency refers to uniform terminology, symbolism and interaction architecture across multiple devices. It should be intuitively clear to the user how different words, situations or actions relate to each other. What is called “Automatic” in the heating controller, is abbreviated with an A symbol on the room thermostat and is called “On” in an app may technically mean the same function, but requires the user to have a deeper understanding of how each part of the system works in order to deduce it with certainty.
In practice, conflicts often arise between different forms of consistency. When designing an app, for instance, it makes sense to adopt the conventions of the operating system for the design of buttons and input fields.
For example, depicting an analogue switch on a smartphone would look extremely clunky. Replacing it with an Android- or iOS-typical button, however, would sacrifice consistency between the device and the associated app, i.e. within the portfolio of our example manufacturer.
A good compromise could be to take into account the platform conventions of iOS or Android, but to reflect characteristic core elements such as a certain colour scheme or the circular shape of an analogue rotary wheel.
Continuity for smooth handovers from one device to the next
When exchanging data, there are always latency times, occasional losses of data packets or temporary inaccessibility of individual components (see also The 8 challenges for developing connected HVAC systems). Whenever this results in short interruptions, a continuity problem is present.
While continuity is one of the biggest challenges in many parts of the Internet of Things, most heating technology applications are fortunately quite tolerant in this respect.
This is partly because the system’s functionality is usually not significantly affected by short interruptions of a few seconds or even minutes. On the other hand, because human interaction with a heating system is rather sporadic. In comparison, with many connected consumer electronics, such as listening to music via Bluetooth or streaming Netflix via Smart TV, even the shortest system interruptions can massively disrupt the user experience.
Due to the high technical effort, higher unit costs and interactions with other product features, it is neither possible nor desirable to exclude any possible malfunction. These are inevitable part of a connected system.
Nevertheless, it is the responsibility of product development to prevent disturbances as good as possible in the first instance and to intelligently design the user experience for the remaining continuity problems in the second instance. In detail:
Product developers must make their systems and their components sufficiently robust to ensure operational safety and the fundamental functionality of the system at all times. From the countless design decisions that have an influence on this, here is a selection of possible levers:
- Include retries to automatically restore lost connections
- Detection of lost data packets, automatic resends and/or redundant data transmission to compensate for individual packet losses.
- In applications with a rather low tolerance for latency, the system composition can be influenced in favour of short transmission paths. Rule of thumb: the more locally the functionality is available, the shorter the latency. It is therefore shortest if the requested functionality is located locally on the device itself. Slightly longer if it is transmitted within a local network. Longest if it has to be requested via external networks such as the cloud. Product developers should therefore define the maximum tolerable latency times and incorporate these into the system design.
- Choosing the right communication technologies. For example, since the LIN bus is optimised for short transmission distances and small amounts of data, CAN bus or Modbus would be the better choice for longer lines or larger amounts of data. Wired communication generally has higher transmission security than wireless (see also Hardwired or wireless?), and so on. Since each communication technology has its pros and cons, it must above all fit the application in order to provide the best possible operational reliability.
- Appropriate choice of network structure.
Star topologies can compensate for the failure of certain devices better than ring or tree topologies – as long as the central node is not affected. Mesh networks offer the highest functional reliability.
- Good selection of electronic components. Memory components whose read and write cycles are quickly exhausted in the context of a given application can lead to premature failures, for example, due to a greatly shortened service life. Capacitors designed for the industrial rather than the consumer sector are more expensive, but meet higher temperature classes and thus offer better functional reliability and longevity. And so on.
- Electronic layout to reduce external interferences and own interference emissions at least according to the European EMC Directive.
- High-performance software. Inadequately programmed multithreading, i.e. the parallel processing of several execution threads, increases the risk of overloading the processor or main memory and losing data packets.
- Provide safe fallback scenarios.
Shape the user experience
Whenever continuity issues occur, users should be largely shielded from the effects of short, non-critical dropouts. Possible levers:
- Allow the system longer waiting times or a higher number of connection attempts before suggesting a failure to the user with an error message.
- Include pragmatic fallback scenarios
- Gradual problem handling depending on system response time. Rule of thumb: A reaction time of 0.1 seconds should be achieved to preserve the impression of immediate effect. Reaction times between 0.1 and 1 second can already seem awkward. Above 1 second, one should think about intermediate feedback, by which the user recognises that his interaction has been registered. For example, in the form of a loading screen, or by visually adopting his button press, even if the system is still busy executing it in the background.
A product system that combines composition, consistency and continuity fulfils some important prerequisites for satisfied users.
The article on the user experience of connected heating and cooling systems explains which other criteria contribute to the positive user experience of connected HVAC systems. The aspects that need to be added to the user interface of connected products and how it can still be kept clear are discussed separately in the chapter on usability of connected systems.
Why the integration of heating technology into connected systems is so essential in the first place can be read in How connectivity shapes the future of HVAC.
 https://www.oreilly.com/library/view/designing-for-the/9781491971468/ch05.html. Retrieved on December 30th, 2021