In part one of a two-part article, Geoff Meads looks at key lessons from an integrator who had to come into a “finished” job to fix the control solution.

Late last year, a good friend of mine contacted me with an interesting proposition. They’d gained a contract to fix a large and prestigious multi-dwelling unit (MDU) project in the heart of central London. The project had already been “completed” by the previous contractor, but the developer had received a stream of negative user feedback concerning the installed control system, starting almost as soon as the first buyers moved in.

The project is big, involving over 150 independent apartments of various sizes. They all feature a very similar control system and, as such, we reasonably expected to use a single master program with all the fixes (designed for the largest apartment) and delete the non-used parts of the program for the smaller apartments.

Having jumped into the project, what followed (it’s still going on as I write this) was a situation that highlighted several key lessons in both user experience (UX), programming and project management, some of which I’ll cover here. Others will have to wait for a further instalment!

Systems structure

First, let me describe the project hardware. The system is based on the highly popular KNX protocol. KNX is a logical choice for such projects as it is easily scalable, highly robust and is supported by a wide array of manufacturers. Many KNX products also offer a great user experience, if thoughtfully programmed.

Each apartment features a separate KNX system offering centralised control for lighting, heating and AC. The heating and AC are via fan coil units in all bedrooms and larger living spaces. There is also a central mechanical ventilation and heat recovery (MVHR) unit to manage fresh airflow and heat recovery. Such systems are commonly installed these days in UK city dwellings for ecological reasons.

Lights are controlled by wall-mounted, touch-sensitive keypads and there is a central full touch screen controller giving complete oversight of all lighting and heating fixtures, plus a door-entry and call system that connects to the building concierge.

Touch screen layout

One of the first things my friend noticed was that the touch screens had an inconsistent layout. The home screen has two columns of graphical blocks, each serving as a button linking to a menu screen for a chosen room. However, the list wasn’t consistent.

Depending on apartment size, the first column might have rooms like ‘Kitchen’, ‘Lounge’ and ‘Entrance’ but, also, sometimes a bedroom or two. The second column would have the buttons for whatever rooms were left (usually the remaining bedrooms). Now, you could argue that it doesn’t matter what order these buttons are in as the user will get used to where each button is over time. However, we must also consider the service staff who use these screens while cleaning and/or carrying out maintenance.

Having a universal layout will save a good amount of user time and reduce errors. Finally, from a project and programming point of view, it makes far more sense to have a consistent layout.

So, we changed the layout. Now all bedrooms are on the right of the screen (running one through four down the screen), with the remaining rooms in a consistent order on the left.

User reports

The first user complaints centred around how the touch screens control lights and heating. Users simply didn’t understand how to use the touch screen to get a desired light on, or temperature in a room.

On further investigation, the initial contractor had used a rather unintuitive set of controls. To set a temperature, the user must first turn on the system for the room they wish to control, then set a ‘mode’ for either heating or cooling. Finally, they’d need to select a desired temperature.

This approach gets the job done but leads to some dead-ends. For example, it was possible to have the room be at 20°C and set a desired temperature of 18°C, but mistakenly leave the system in heat mode. As a result, nothing would happen (except a build-up of user frustration).

To fix this, our new program uses just two controls and a piece of visual feedback. There is still a master on/off for heating and cooling in each room, as that’s essential for when the apartments are left for long periods. On a day-to-day basis, the user simply selects the temperature they want. The system decides the heating or cooling mode automatically and informs the user what it is doing by showing either a heating or cooling symbol.

Lighting keypads

To control lights in each room, a standard-sized, touch-sensitive lighting switch is installed in each area. These each have between two and six buttons and have LED indicators to show the status of each button. Each switch faceplate is custom-etched with both suitable icons and text. Buttons are either configured as simple on/off switches; set for one-button dimming; or as a dimming and on/off pair.

Issues for users started with the LED indicators. Feedback had been configured but wasn’t consistent. Various colours were used in different scenarios to display the system status or dimming level. While this could be considered clever, users simply didn’t understand what was going on. Light switches are supposed to be simple!

To fix this, we changed the keypad LED indicators to show just two things. For one-button operations, if the light circuit is on, then the button shines blue. If the light circuit is off, then the button LED goes off. For buttons in pairs, the relevant button turns blue when active, or off when inactive.

Having spoken to a few users after the reprogramming was done, they are already finding this new scheme far easier to understand and use.

Lighting via touch screen

The second issue users were having with lighting is when they tried to control it via the central keypad. Again, the original contractor had added additional steps to the control process that were both unnecessary and confusing.

For dimmable lighting circuits, the original screen showed two controls for each dimmable circuit, each with visual feedback. These were in the form of a small picture of a lamp (that glows a variable amount to reflect the current brightness level of the circuit) plus a graphical slider with a percentage display of the current dimming value and allows the dimming value to be set precisely.

The issue users had was that the circuit could only be turned on and off by pressing the lamp symbol and not by adjusting the slider. If the circuit was off, sliding up would not bring on the light. Similarly, turning the slider down to zero would not turn it off.

Again, simplifying was the answer. We gave all control of the light over to the slider and used the lamp symbol as an indicator only. Again, users immediately let us know how much easier they found this to use.

Conclusions

We now have an incredible array of possibilities when it comes to offering controls and feedback to our users. The systems within the project described here are not that complex, but the controls offered over-complicated things to a point where users became frustrated, even when they were doing something simple. Thankfully, with a little clear thinking, the solutions were just as simple.