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.

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.




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.


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.


- 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.
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 (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

