For the sake of aesthetics, integrators often blend different product control systems into one easy-to-read solution. Geoff Meads finds out how the user experience is impacted when all these solutions have their own control systems.

The exact definition of User Experience (UX) isn’t defined. Wikipedia suggests the subject of UX describes “how a user interacts and experiences a product, system or service”. The truth is perhaps larger than that. The term UX has also found itself also being attached to a particular design aesthetic. Although that’s a more difficult thing to describe it is usually applied to interface designs that have very clear, easy-to-understand controls.

Sometimes though, a good or bad user experience with a particular system can occur even when you’re not aware you’re dealing with a particular system at all. For example, in the modern online world, it might feel like we’re completing a purchase on a vendor website or app but actually dealing with a banking system.

System designers feel it is often preferable to ‘hide’ the actual system in use in favour of keeping the graphical design of the experience consistent for the user right through the purchase. This approach can make the user feel more secure in their transaction as they don’t think they have jumped from one system to the other and back again which might cause some anxiety.

We can see this situation in the home automation world too. Often systems like HVAC or security have control systems all their own. However, to make things simpler for the user, we hide these behind an overarching control system so that the interface remains consistent for the user.

UX and network segmentation

Some issues ago, I wrote an opinion piece discussing the pros and cons of network segmentation in the form of virtual Local Area Networks (vLANs). One thing I didn’t discuss in that piece was its effect on the UX of a network for network users and network administrators. In my initial article I came down mainly against vLANs for two reasons: complexity of setup and the reduced need for them nowadays where more advanced technologies offer fewer bandwidth problems.

Recently, the need for vLANs has reared its head again but not for bandwidth reasons. vLANs are starting to be specified to combat security concerns thanks to the rise in attacks on (what we might call) Internet of Things (IoT) devices.

IoT devices typically rely on communication with the cloud to operate meaning a lot of LAN to WAN and WAN to LAN traffic. This means that the network ports of these devices are in constant contact with Internet-based servers and, unless they are completely secure, updated regularly and use strong passwords, represent a high network intrusion risk.

Devices that fall under this banner include video doorbells, voice assistants, security cameras with offsite recording, smart thermostats and smart locks.

One approach to limiting the risk of such systems is by placing them on a separate IoT vLAN and/or wireless network. This moves them out of a network that might contain sensitive data and into a network environment all their own. As most of the data that displays their status and controls their function is routed to and from the cloud and onward to a control device (typically a smartphone), it doesn’t matter if your phone is physically right next to the device, communication between the two goes via the cloud. This is useful as the two devices do not need to be on the same LAN and, as such, the IoT device can be on a vLAN for security reasons and still work as expected.

Plain sailing? nope

This is all well and good for day-to-day use. However, there’s a problem and it’s a mighty frustrating one when it occurs. Setup of these devices, whether it’s out of the box setup or integration with other IoT devices, often requires the controlling device (a smartphone) to be on the same LAN as the IoT device. Now when you, the network-savvy installer, are setting these things up then you know this. Right? But what about the day-to-day user?

Let’s imagine a typical scenario. You set up a smart lighting system using IoT devices for a customer. They can now control the lights from their phone, set macros via an app to turn lights on and off when they are away or when the sun sets etc. and they are very happy.

Then, come Saturday afternoon, they pick up a well-known voice control assistant while they are out shopping. Or maybe they were given one as a ‘thank you’ for signing up to a new insurance policy or some such thing. They take it home, run through the quick start guide (using the IoT network you set up for such things because they listened to you…) and soon have it working. They start asking it things and get a fun reply. They are still happy.

But now, wait, what’s this…? They spot a menu item in the app for the voice assistant that allows you to add other IoT devices to be controlled by the voice assistant. There, in the list of systems, is the lighting control that they have. Great!

The next steps should be easy; if all devices were on the same network, it would be. However, what often follows is a minefield of frustration. Yes, they have two compatible devices and yes, they are on the same IoT vLAN. However, to run the setup between the two systems the two devices AND the smartphone running the setup need to be on the same vLAN. The two IoT devices are on the same vLAN (because they did as you said and put them both on the IoT network) but the phone is on the vLAN for general family use.

I know this to be true, it happened to me!

While this is just one example (and different devices use different systems for setup) the lesson is this, when setting up networks we not only have to think about access, bandwidth, and security we also need to think about usability. There is a phrase used in medical circles that applies nicely here. It goes something like this ‘while you must do good you must also do no harm’. Or, to put it another way, while delivering an ‘improvement’ to one aspect of a system we must make sure we don’t break the stuff that already works.