Redesigning IoT alert setup for InstaHub

B2B SaaS
A/B Testing
6 Months
Shipped
To comply with my non-disclosure agreement, I have changed some of the quantitative data and omitted some information in this case study. All information in this case study is my own and does not necessarily reflect the views of InstaHub.

TL;DR

InstaHub’s property managers were abandoning alert setup mid-flow, generating a high volume of support tickets and increasing operational error rates across client properties. The existing interface forced a sensor-first mental model that conflicted with how operators actually think about facility problems. I redesigned the end-to-end alert creation experience around problem templates rather than sensor selection, reframing the entire flow before touching wireframes. Task completion rate improved from 27% to 92% in A/B testing across 74 participants.

The Problem

InstaHub is a B2B IoT platform where property managers configure sensor-based alerts. Getting alerts right directly affects energy efficiency and operational cost for their clients.

The existing setup flow had a critical failure: most users couldn’t complete configuration without abandoning or making errors. Creating downstream costs in support time and client trust. The product needed to make independent, correct setup the default, not the exception.

Final Solution

Impact & Metrics

The Core Insight

The existing flow was built around a sensor-first mental model:
Select sensor → Define parameters → Create alert

But through research, I discovered operators don’t think in sensors. They think in problems:
“I need to catch if the HVAC in Building 3 runs hot.”
“I want to know if someone enters Zone 4 after hours.”


This wasn’t a UI problem. It was an architecture problem. Solving it required reframing the entire entry point of alert creation, not redesigning the existing form.

Research

Before wireframing, I ran two research streams in parallel:

Session Recordings: 12 recorded sessions, Drop-off was highest at the sensor selection screen.

Contextual Interviews: 23 property managers across enterprise clients. Goal was to understand their mental model, not just usability issues.

Key Findings

- 18/23 managers started with a problem ("HVAC running hot"), not a sensor type.
- Drop-off was highest at the sensor selection screen (8/12 sessions)
- Zero users understood "threshold delta" without hovering for help text.

A/B Testing

We tested two design approaches with 74 internal and client users.

Test tasks given to participants:
1) Create a temperature alert for a specific building above 78°F
2) Edit an existing occupancy alert to change the notification recipient.
3) Delete a misconfigured alert and recreate it correctly.

Version A (alternative flow): Sensor-list entry point → parameter configuration → save

Version B (my proposed flow): Problem-template entry point → guided parameter setup → plain-language preview → confirm

Version A
Version B

Version A (alternative flow): Sensor-list entry point → parameter configuration → save

Version B (my proposed flow): Problem-template entry point → guided parameter setup → plain-language preview → confirm

© 2020-2026 Designed & Developed by Omkar Dixit