Turning field hardware, mobile commissioning, cloud management, and real-time data into one connected product experience.

Starting with the complete customer journey

The product crossed several environments and user groups. Field technicians installed and commissioned equipment. Engineers interpreted sensor data. Site managers monitored risk and system status. Administrators managed users, clients, locations, and access.

Rather than begin with a list of mobile or portal features, we examined the complete journey and the handoffs within it:

• How does a technician identify and connect the correct hardware?
• What information is needed to configure a gateway, data logger, or sensor?
• What must be verified before the technician leaves the site?
• How does the deployed system appear to an engineer or site manager?
• How can a user identify a failing connection or abnormal reading quickly?
• What information and controls are needed as deployments grow?

These questions helped us define the product as one system. Decisions made during commissioning had to create the device, location, and instrument relationships used later in the portal. Health information shown in the field needed to remain understandable when viewed remotely.

Making field commissioning faster and more dependable

The mobile application became the technician’s primary commissioning tool. It supported iOS and Android and connected directly to devices using Bluetooth Low Energy, allowing technicians to complete essential setup even when internet connectivity was unreliable.

The experience replaced manual procedures with a guided flow. QR code scanning helped identify equipment. Smart defaults reduced repetitive entry. Step-by-step configuration made dependencies clearer and reduced the opportunity for mistakes.

The most important design decision was to make system state visible throughout the process. Signal strength, battery level, temperature, connectivity, attached instruments, and configuration status were presented in language and visual states that technicians could act on.

Clear success, warning, and error feedback helped answer the question that mattered most in the field: is this system correctly commissioned and safe to leave operating?

The result was a provisioning process that fell from hours to under 15 minutes, with fewer support issues related to pairing and manual configuration.

Creating a shared operational view in the cloud

After commissioning, the web portal became the central environment for monitoring and management.

Users could view gateways, data loggers, sensors, sites, and the relationships between them. A high-level dashboard surfaced overall system health, while maps, tables, lists, and detailed views allowed users to investigate a specific location or device.

The portal brought several operational tasks into one place:

• Monitor device connectivity, communications quality, and current status
• Organize equipment by client, site, and location
• Inspect gateways, data loggers, attached instruments, and their relationships
• Add, update, move, or decommission equipment
• Plot sensor readings through time-based and X/Y visualizations
• Adjust data ranges and frequencies for analysis
• Configure alarms, notification lists, alert history, and scheduled reports
• Import, export, and share data for further analysis
• Manage users and access as customer deployments expanded

The objective was not to expose every technical detail at once. The information hierarchy was designed to help users begin with the health of the overall system, recognize where attention was needed, and then move into the relevant site, device, instrument, or data set.

Treating device relationships as part of the product model

One of the less visible but important product challenges was the relationship between physical equipment and the digital representation of the deployment.

A monitoring installation could include multiple sites, gateways, data loggers, and instruments. Devices could be moved, updated, disconnected, or decommissioned. The product needed a clear model for these relationships so users could understand both the physical setup and the flow of data.

We designed the mobile and web experiences around the same system model. The configuration created in the field became the structure users later navigated in the portal. This reduced duplicate work and helped preserve continuity from installation through ongoing operations.

That platform thinking made the experience easier to scale. New device types and monitoring capabilities could fit into a shared operating model instead of becoming isolated workflows.

Aligning specialized teams around one outcome

The program depended on several teams with different priorities and release cycles. A mobile flow could not succeed if firmware did not expose the right device state. A web dashboard could not provide timely health information if cloud services or hardware communications were incomplete. Hardware decisions could change what was possible in both applications.

I worked across mobile, web, cloud, firmware, hardware, quality assurance, and subject-matter experts to make these dependencies visible early. We used the customer journey and the intended operating outcomes as the common frame for prioritization.

This helped the teams make trade-offs as one product organization. Instead of optimizing each component independently, we focused on whether a technician could commission the system confidently and whether an engineer could monitor it remotely once it was operating.