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 automation platform used by property managers to configure sensor-based alerts: temperature thresholds, occupancy triggers, equipment failure notifications. Getting alerts right directly affects energy efficiency and operational cost for their clients.
The existing alert setup flow had a critical failure: the majority of users couldn’t complete configuration without abandoning or making errors. Alerts misconfigured at setup would either fire incorrectly or not fire at all, creating downstream costs in support time and client trust.
The business stakes: Every failed setup required support intervention. Every misconfigured alert created operational incidents for the end client. 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: Reviewed 12 recorded sessions of existing users attempting to create new alerts. Identified where users dropped off, hesitated, or backtracked.
Contextual Interviews: Spoke with 23 property managers across enterprise clients.
Goal: understand their mental model, not just their usability issues.
6 Friction Points Identified:
1) Sensor list displayed all sensors upfront, with no grouping by problem type. Users had to know sensor names to find what they needed.
2) No preview of what the alert would do before saving.
3) Alert parameters used technical terminology (e.g., “threshold delta”) unfamiliar to non-technical users.
4) No confirmation or success state after alert creation.
5) Editing an existing alert required navigating away from the alert list entirely.
6) No feedback when a sensor was already assigned to a conflicting alert.
The wireframes reoriented the entry point from the sensor selection to problem selection.
Three decisions shaped the new flow:
Decision 1: Problem-template entry pointInstead of “Choose a sensor,” the new flow opened with “What do you want to monitor?” a set of problem-type cards (Temperature, Occupancy, Equipment, Energy). This matched the mental model surfaced in research.
What we didn’t do: We considered free-text search as the entry point, but testing showed users didn’t know the vocabulary well enough to search effectively.
Decision 2: Progressive disclosureOptional parameters (advanced thresholds, escalation rules) were collapsed behind an “Advanced” toggle. This reduced the visible field count for new users without removing capability for power users.
Decision 3: Alert preview before save, Added a plain-language summary step before confirmation: “This alert will notify you if Building 3 HVAC temperature exceeds 78°F for 10 minutes.” This directly addressed the misconfiguration problem.
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
This project involved close coordination across three teams:
1) Product (PM): Aligned on scope early, we chose to focus on alert creation only, not alert management or notification delivery, to ship something shippable in Q2.
2) Engineering: The real-time sensor validation I initially designed required a new API endpoint (+3 weeks). I proposed an on-save validation fallback that preserved the UX intent without the dependency. Shipped on schedule.
3) CEO / Stakeholders: Presented Version A vs. B findings directly to leadership. Built the case using conversion rate and qualitative confidence scores, not just visual preference.
