IoT sensor monitoring · Dexen · 2016

Every sensor,
one surface.

Service teams monitor refrigerators, air conditioners and other equipment across multiple sites. I designed a Dexen prototype that brings warnings, current readings and equipment context into one monitoring workspace. The desktop experience supports office monitoring and service planning.

Lead Designer·Remote stakeholder research, information architecture, interaction design, prototyping

Context

Different readings.
The same need to locate a problem.

The equipment varies by site. Temperature, humidity, airflow and electrical readings each describe a different part of its condition. A warning needs context: the device it comes from, where that device is and the information available about it.

I used remote stakeholder interviews to understand the service roles and their information needs. That informed the prototype. The desktop screens here focus on the monitoring workspace; technicians' work in the field continued through other channels or screens.

Roles

Monitoring sits inside
a wider service operation.

Administrator

Keeps the equipment record current.

Registers devices and sensors, manages access and updates records when equipment changes. Monitoring depends on that setup.

Service Technician

Needs equipment context in the field.

Checks warnings, diagnoses the device and uses its records and site contacts. Mobile access mattered to this role.

Technician Manager

Reviews the service operation.

Tracks team performance, repeat repairs and equipment reliability. Repair costs matter alongside device status.

Structure

The hierarchy follows the equipment.

The information model separates the service provider's work from the equipment it maintains. Work orders and technician availability belong to the provider. Sites contain devices, and each device contains its sensors.

That hierarchy also shapes the monitoring view. A reading stays attached to a device and a location. The person reviewing a warning can find the equipment record from the same structure.

Dexen

Service provider

Work orders

Technician availability

Equipment

Sites

Devices

Sensors

The product model connects service work with a site, device and sensor hierarchy. The desktop screens below show the monitoring part of that model.

Simplified reconstruction of the original information model.

Interface

Warnings lead.
Device context follows.

The inventory opens with recent warnings. Equipment cards underneath show current readings, grouped by site. Opening a device brings its sensor detail and equipment record together.

Dexen prototype inventory with recent warnings above current readings grouped by site — Inventory
A warning names the reading, device and site. Grouping equipment by location keeps that context visible while the office team reviews the inventory.

Dexen prototype device detail with sensor families beside equipment documents, contacts and a map — Device detail
Sensor families share a consistent layout, with the current value leading each card. Equipment documents, contacts and location sit beside the readings for further investigation and service planning.

Dexen prototype rule editor with a sensor formula, warning message and alert frequency — Rule editor
The editor defines a warning condition using sensor values and a formula, then sets its message and alert frequency. Rules are configured in the context of the device they monitor.

Outcome

The prototype made the product
concrete for investors.

My deliverable was the design and interactive prototype. The team used it to demonstrate the proposed service platform to investors, then told me they had secured funding for the next phase.

The design's organising principle was to keep each reading tied to its device, location and service context. That gave the monitoring workspace a consistent structure across different kinds of equipment.

Every sensor, one surface.

Different readings. The same need to locate a problem.

Monitoring sits inside a wider service operation.