Calectro controller
Brief
“Allow HVAC field technicians quick access to the correct information to configure a controller or identify the settings on a current install"
Client: Bright Skills work for Calectro
Role: Information Architecture, UX research & design, UI & copy
Deliverables: Flowcharts, Figma prototype
Note: Product hasn’t launched yet so some details have been blurred out.
Core challenge
Identify the hierarchy of decisions a HVAC technician goes through when configuring a controller and present the different paths in an unambiguous fashion.
Bonus challenge
The product isn’t out on market until 2025 and some technical aspects as well as documentation is work in progress, so I’ve had to come up with an adaptable solution rather than a fixed one to parry any future revisions.
Outcomes
Multiple IA flowcharts have been created to help the client decide on a hierarchy, and I handed over a Figma prototype to the dev for a first low-code version.
The controller functions
The controller contains sensors for multiple parameters such as humidity, temperature, etc, and this data can either control heating/cooling directly, or feed into a master control system. For example, when the relative humidity hits 80% you might want to increase the air flow into a room until you’re down to 70%, but at the same time you want to keep the temp at a cozy 22°C. HVAC sensors and control systems are the ones responsible for maintaining these climates.
Any modern office or apartment building will have such sensors spread throughout, and since different buildings and rooms might have different requirements, this controller allows a field technician to change the settings depending on the requirements.
This controller is made small so as to be unobtrusive, which means that the interface for controlling the setting are tiny, in this case using SPST DIP switches. There’s not enough space to show the settings in a meaningful way on the controller itself, so traditionally technicians have to refer to printed manuals or PDF tech sheets.
While my proposed application doesn’t make away with the need of a proper manual altogether, it’s intended to replace it in one of the most common tasks in the field – setting or analysing the settings of a controller.
IA & Flowcharts
After discussions with the client about scope, we decided that the primary problem they’d like to solve was to allow a technician to identify how to set the DIP switches in order to meet a site requirement. Since the controller has 15 different applications – each with four parallel outputs – I began by going through the documentation and clustered the applications.
There was a lot of overlap between the different applications and I had to make some assumptions about their hierarchy and the order-of-operations for a field tech, but it was good enough to allow me to draft a first flowchart of interactions.
The clustering allowed me to present a flowchart which illustrated the order-of-operations that I suggested, as well as an interactive wireframe which I presented to the devs & PO to get their go-ahead. The client provided me with much needed domain knowledge and we could reach agreement quickly.
The flowcharts are great for discussing the user flow while respecting the engineering approach to information architecture, and with that in hand I could quickly swap out the flows based on feedback from the client.
A flowchart doesn’t allow you to handwave the problem away – there is no “maybe” or “we’ll fix it in code”. Flowcharts will highlight your blind spots without mercy, and forced both me and the client to make decisions which allowed for rapid development.
Prescriptive vs open
With no access to users or user data I suggested a prescriptive approach to the solution: Together with the client I’d prioritize the different application features (temp, humidity, CO2) and allow a user to step-by-step make selections based on the priority we decided.
A user would never have to choose between more than three options, and arrive at no more than two final application suggestions that both solve for their problem. As long as the order of operations matched the expectations of the users, this would give a result quickly and be easily repeatable in other situations - and importantly, it’s would be easy to test such a prescriptive solution with actual HVAC field technicians.
With limited time for design and development – and with no users to actually evaluate this much more tricky proposition – I opted for a prescriptive solution, and focused on making the affordances as obvious and consistent as possible.
An alternative approach is be to design a multi-select filter which would allow the user to set all the parameters of the “ideal” application, and then present the matching applications. I decided against this approach since this would require a design that would fail gracefully in thousand of cases where the selected features were mutually exclusive.
The benefit of such an “open” solution is that it could be designed to accomodate changes in the applications themselves without having to reevaluate a flowchart priority, and it would accomodate differences between use cases (for example, in a school CO2 might be most important, in a kitchen relative humidity).
App design
The first version of the app allows a field technician to do three things:
1) Use an interactive guide to identify the current setting of a controller – for example when troubleshooting an existing install, or if on-site documentation is missing.
2) List all the possible settings on one page, as well as marking some as “favourite” for faster recall.
3) Use an install wizard to go through a decision tree based on the most important features of the controller. Is temperature control more important than humidity, etc.
The wireframe informed the interactive prototype on the right which is the first version being developed. The main difference has been in the actual flow and hierarchy, but since the mental model has remained the same I’ve been able to keep working on the design while we ironed out the flowchart.
The final proposed app was designed in Swedish, and some of the graphical assets will to be updated since the controller design isn’t finalised, but the current version keeps to the clients brand guidelines as far as colour and typography is concerned.
I made the design sparse both so that a stressed field technician easily would be able to distinguish between information and affordance, but also in order to more easily accomodate later brand integration with other client products.
And one more flowchart for the devs
Even though the developers have no trouble navigating Figma prototypes, there are diminishing returns in using the prototype as a single source of truth – it’s just too easy to make mistakes and miss important information – so team lead asked for a better presentation of all the user-facing information in the wizard. I resorted to yet another flowchart, but this time edited for clarity and reusing some of the graphical elements in order to better slot into their mentan model of the app.
As the app is still in development – as is the finished product – a next step would be to actually do user tests in the field to evaluate both the IA assumptions made by me and the client, as well as the affordances of the design itself. This could be a first step towards a design pattern that could be reused in hundreds of the products in Calectros catalogue, and I enjoy being part of the process!