Redesigning environmental monitoringplatform for speed and clarity

TL;DR

• DicksonOne monitors critical environments like hospital refrigerators, pharmaceutical cold chains, warehouses, and aerospace facilities.
• After seven years without a designer, the product had grown around its hardware and built up significant design debt.
• The original experience forced users to navigate locations, sub-locations, devices, and numbered channels before they could identify what was alerting.
• I led a redesign that shifted the platform from device-first to channel-first.
• The redesign introduced named channels, channel-level views, real-time dashboard updates, warnings, and a companion mobile experience.
• The result was a more actionable monitoring experience built around the user's urgent question: what needs attention, where is it happening, and what should I do next?

How Environmental Monitoring Works

Industries from healthcare to aerospace are legally required to track when their products drift outside safe conditions. A pharmacy storing vaccines must prove those vaccines never exceeded a temperature threshold. A manufacturer must document exactly how long and how severely a cold room failed. This isn't just quality control. It's compliance, and non-compliance can mean regulatory action, product loss, or patient harm.

DicksonOne's hardware handles the monitoring. Each physical Device connects to one or more Channels, individual sensors that can measure a wide range of environmental conditions: temperature, humidity, CO2 levels, pressure differentials, dew point, and more. The specific variables being tracked depend on the industry and its use cases. A pharmaceutical cold chain cares about temperature above all else, while a manufacturing facility might monitor pressure and humidity simultaneously.

The Device

Sample Sensor Types

The Device/Channel relationship: one device, multiple sensors, each monitoring a separate asset.

When a channel crosses a threshold, it triggers an Alarm, which notifies the right people via call, text, email, or the web dashboard. If an alarm activates, it becomes an Excursion, and that excursion requires documentation. The stakes are real. So is the urgency when something goes wrong.

Context

DicksonOne's software had been running for seven years. The experience was built around the technical structure of the hardware that made sense when the system launched: you had devices, and devices lived in locations. That structure worked when a single location had a handful of devices. It broke down as clients scaled.

Their typical customer isn't a single pharmacy with two fridges. It's a hospital network with hundreds of locations, each with dozens of monitored assets. An administrator might be responsible for thousands of channels across a national footprint, and legally required to account for every excursion across all of them.

When I joined the engagement, DicksonOne had never worked with a product designer. Features had been added over the years without design involvement, resulting in significant design debt and a system that reflected the architecture of the hardware more than the needs of the people using it. They were open to a ground-up rethink, not just a cosmetic refresh, but a genuine reconsideration of how the platform organized and presented information.

My role: I led all research and design, including discovery, user interviews, heuristic analysis, synthesis, ideation, prototyping, and usability testing. I worked closely with a project manager and a developer who was deeply familiar with the system's existing architecture. The client's product owner participated in interviews and workshops throughout. This was also his first time working with a designer or researcher, so part of my role was helping him understand and trust the process as we went.

"It used to be that our customers had to drive literally location to location to manage the devices, but now they log into a screen somewhere and have access to their data."

Matt McNamara, VP of Product, Dickson

Research

I approached this engagement in phases: first understand the system and its users as they exist today, then identify where the real problems are, then validate that proposed solutions actually address them.

Learning the system

Before talking to any users, I needed to understand what I was working with. I conducted a thorough heuristic analysis of the existing DicksonOne site, evaluating it against established usability principles and flagging issues across navigation, information architecture, terminology, and task flows. I also went through the firmware setup process end-to-end so I understood the full product experience, not just the web interface.

1. The primary location. Finding a channel feels like digging through folders.
2. Companies add sub-locations, and sub-locations inside those, which makes devices and channels hard to find.
3. Sub-locations don't always contain devices, and there's no way to know without opening them.

1. This is one device. The only route to detail on its channels is the device title.
2. Readings show for two channels, but is either alerting? Nothing says whether this is the device to investigate.
3. These column titles look clickable but are only hover states.
4. The trend graphs have no X or Y labels, and there's little logic to their colors.

The original interface, annotated: the locations view (1 to 3) and the device view (4 to 7).

Understanding the users

DicksonOne's users aren't a monolith. Through early discovery I identified two meaningfully different user types, each with distinct needs and mental models:

These two profiles shaped nearly every design decision that followed.

Interviews & contextual inquiry

I conducted user interviews via Zoom with both user types, focusing on how they actually used the system day-to-day, not how it was designed to be used. I invited the client's product owner to observe sessions, which served two purposes: it helped him build empathy for his own users, and it made the eventual design recommendations much easier to align on because he'd heard the problems directly.

Where possible, I supplemented interviews with contextual inquiry, observing users in their actual environment rather than asking them to describe it. Watching a frontline worker navigate the system to respond to a simulated alert made the wire-tracing problem viscerally clear in a way that no interview transcript could.

What I found

Several themes emerged consistently across users and methods:

• Finding an alerting channel was a multi-step scavenger hunt. Users had to navigate location → sub-location → device before they could even see which channel was alerting.
• Channels had no names, so nobody knew which physical asset was involved. A device with six channels gave you "Channel 1" through "Channel 6." When one alarmed, the only way to identify the right fridge was to physically trace the wire or consult a handwritten key.
• The alarm threshold was also the paperwork trigger. Users got no warning before the threshold was crossed. By the time they were notified, it was already too late to avoid compliance documentation.
• "Alarms" meant two different things in the same product. A nav item called "Alarms" showed triggered alarm history but couldn't be used to create or manage alarms. Users looking to configure alarms went there first and found a log instead.

Synthesis

After completing interviews I synthesized findings into a prioritized set of problems to address, which I presented to the product owner and client team. This became the shared foundation for everything that followed: not a list of features to build, but a map of real underlying issues ordered by impact.

The central insight was the paradigm shift: the system was organized around devices, but users cared about channels. Everything else laddered up from there.

Problem

The system worked, but it was clunky and inelegant.

Too many steps to act

When a DicksonOne alarm fired, a real person would get a call, text, or email saying something was wrong. Their next step was logging into DicksonOne.com, and that's where the process broke down.

The system organized everything by location. To find what was alerting, a user would navigate:

In practice, that looked like this:

1. Receive an alert that a device at "St. Louis Hospital" is alarming
2. Log in and navigate through the location tree to find St. Louis Hospital
3. Find the correct device (say, "Fridges, 1st Floor Supply Room")
4. Open the device and see that Channel 1 is alerting
5. Walk to the supply room and physically trace the wire from port "Channel 1" to figure out which fridge it's connected to

For something requiring immediate attention, this was an agonizingly slow process. Some users built handwritten maps. Others memorized which port connected to which asset. Neither was scalable.

Channels had no names

Because the system was device-centric, individual channels had no identity of their own. A device might have six channels, six sensors going to six different fridges, but the system only showed "Channel 1" through "Channel 6." When one alarmed, there was no way of knowing which fridge was involved without physically tracing the wire.

DicksonOne was also preparing to launch a new wireless sensor format that would allow hundreds of channels to connect to a single device. The existing mental model wasn't just inconvenient. It was architecturally incompatible with where the product was heading.

Alarms were causing the paperwork problem they were meant to solve

When an Excursion occurred, compliance rules required documentation: what happened, how long it lasted, what was done. This was non-negotiable for most clients.

But alarms were binary: either a threshold was crossed, or it wasn't. There was no early warning. By the time someone was notified, the excursion had already started and the paperwork clock was already running. Users described the Catch-22 clearly: the whole point of the system was to catch problems early, but the system only told you once it was already too late to avoid documentation.

Design debt compounded everything

• The "Alarms" navigation item showed a log of triggered alarms but couldn't be used to create alarms. Users regularly went there looking for alarm setup and found a list instead.
• Every alarm had to be created from scratch, even if a client had dozens of devices with identical use cases.
• Devices could be buried in deep location hierarchies with no way to surface just the ones that needed attention.

Solution

A channel-first paradigm

The central design shift was moving the platform's organizing logic from devices to channels. Rather than requiring users to navigate through locations and devices to find what was alerting, I designed a unified Channel View: a single list of all channels across the entire account, sortable and filterable, with alerting channels surfaced to the top.

For the first time, a user responsible for thousands of sensors across hundreds of locations could open DicksonOne and immediately see: here's what needs attention, right now, in order of urgency.

The redesigned Channels view. Alerting channels surface to the top; named channels give frontline workers immediate context about which physical asset needs attention.

Naming channels

I worked with the team to introduce named channels. A sensor was no longer "Channel 1 on Device: Fridges, 1st Floor Supply Room." It was "Vaccine Fridge A, Supply Room 1." This reduced the need for frontline workers to rely on wire-tracing, handwritten maps, or memory, and enabled meaningful organization at scale that the device-centric model couldn't provide.

This came directly from what frontline workers described in interviews: they needed to know what was alerting, not which numbered port it connected to.

The dashboard

For Overseers, director-level users responsible for multiple locations, I designed an overview dashboard that provided a real-time snapshot of everything happening across the account. Alerting channels were immediately visible without any navigation required.

The Overview dashboard: active excursions and warnings, calibrations due, and firmware updates at a glance.

The dashboard was built for the "always on" use case. Overseers don't want to check in periodically. They want ambient awareness. The design supported that: a tab you keep open in the background that tells you, at a glance, whether anything needs attention.

One head of compliance at a major aviation company told the team he keeps the dashboard open all day because he likes seeing status change in real time.

Warnings: preventing excursions before they happen

This feature came directly from the research. Users didn't ask for it. They complained about excursions and paperwork. But underneath that complaint was a clear unmet need: some advance notice before the threshold was crossed.

I proposed warnings: a secondary threshold set below the alarm threshold. When a channel's reading approaches the alarm level but hasn't crossed it yet, a warning fires. It's a signal that something needs attention now, while there's still time to act without triggering a compliance event.

For clients who acted on warnings, problems could be addressed before they became excursions, which meant no paperwork. This reframed the system from a reactive documentation tool to a proactive monitoring platform.

Real-time updates

Previously, the dashboard was a snapshot frozen in time. To see if anything had changed, a user had to reload the page. I made the case for real-time updates, a significant engineering lift, but one with clear user value grounded in what Overseers told us they actually needed. With live status updates, the dashboard became a genuine monitoring tool rather than a periodic status report.

Usability testing

Before finalizing designs, I ran usability testing with representative users from both groups, Overseers and Frontline Workers. Testing confirmed that the channel-first view helped users identify and locate alerting sensors more directly. It also surfaced refinements: label clarity, sort order defaults, and a few edge cases in the warning setup flow that we addressed before launch.

Mobile

Frontline Workers aren't at a desk when an alert fires. A nurse responding to a vaccine fridge alarm is on the floor. A warehouse technician is between racks. But the need for mobile access wasn't limited to frontline responders. Overseers managing dozens of locations don't always have a browser open either. The same ambient awareness that made the dashboard valuable at a desk needed to work just as well in a pocket.

I designed a companion mobile experience that gave both user types the channel-first view on their phone: named channels, live status, and the ability to acknowledge and act on alerts wherever they were. For Frontline Workers it meant faster response. For Overseers it meant the system was always with them, not waiting at their desk.

Channels

Channel Detail

Alert History

The mobile companion app extended the channel-first experience to both user types, giving them immediate visibility into active alerts wherever they were.

Results

A clearer path from alert to action

The redesign made alert identification more direct. Instead of drilling through a device hierarchy, users could start from the channel itself: what was alerting, where it was located, and how urgent it was.

The previous system asked users to navigate a data hierarchy before they could act. The redesign made that first step immediate.

Earlier intervention through warnings

Warnings gave users a chance to act before an alarm became an excursion. This was especially valuable in regulated environments, where an excursion does not just mean a problem occurred. It means documentation, follow-up, and compliance burden. For customers who adopted warnings, teams could intervene before the threshold was crossed, helping reduce excursions among warning adopters.

Strong qualitative feedback

DicksonOne received unsolicited positive client feedback after launch, something that hadn't happened before. The response came from users who had quietly struggled with the previous system and found themselves with something that worked the way they expected it to.

"Today I had a call with Sharon Burdess at OSF. She asked me to pass along her feedback about the new dashboard on DicksonOne. She knew the information was all available on DicksonOne, but the way it is presented on the dashboard has allowed her and her Clinical Practice Team & Clinic Managers to be more proactive and respond quicker when there are excursions, calibrations due or firmware updates available."

Sharon Burdess, OSF Healthcare, relayed on her behalf by a Regional Sales Director

A new always-on behavior

The dashboard created a new behavior among some administrator-level users. Rather than logging in only after something went wrong, they could keep the dashboard open as an ambient view of system health. One head of compliance at a major aviation company told the team he keeps it open all day.

What made this work

DicksonOne's users aren't just completing tasks. They're managing compliance for organizations where failure has real consequences: compromised vaccines, failed audits, patient risk. The urgency in their workflows is real.

"Nurses are often charged with being responsible for the temperature monitoring of vaccines on their floor. A nurse should not be focused on that. Patient care is what they should be focused on. So anything we can do to get them doing more of patient care is a benefit to everyone."

Matt McNamara, VP of Product, Dickson

What the previous system missed was that those users needed to act, not search. The entire pre-existing flow asked them to navigate a data hierarchy before they could do anything. By the time they found the right channel, precious time had passed.

The redesign reoriented everything around that moment of action: surface what needs attention, identify it clearly, make it possible to respond immediately. That's a product philosophy as much as a design decision, and it's the lens I'd apply to any complex, high-stakes information system.

What I'd do differently

Define baseline metrics before redesigning

The qualitative signal was strong: users were happier, excursions were down among warning adopters, and the dashboard was getting used in new ways. But I didn't have a clean enough baseline to quantify the full impact.

If I were starting this engagement today, I would define success metrics before launch, including:

• Time from alert received to channel identified
• Time from alert received to issue resolved
• Number of excursions before and after warning adoption
• Dashboard usage by role
• Support requests related to alert setup, channel identification, and alarm confusion

That would have made the impact easier to measure and easier for the client to track over time.

Name the paradigm shift earlier

The device-to-channel reframe became the organizing idea behind the work, but it took time to articulate clearly enough that the client could advocate for it internally. A sharper early framing would have accelerated alignment.

Keep listening for the job behind the complaint

Users complained about excursions and paperwork. Nobody asked for an early warning system. Warnings came from listening for the need underneath the complaint: users needed a chance to act before the compliance burden started. That's a pattern I'd carry into any engagement. The most valuable design solutions are often adjacent to what users explicitly request.

Collaborators