Launching the new monitoring device at 88% completion | removing onboarding friction in > 3 weeks
Role:
Product Designer
Company:
Truemfg
Read Time:
5 minutes
Timeline:
May 5, 2026 - May 7, 2026
Platform:
Web Application
Focus Areas:
Retention & Habit Design, Psychological Safety in UX, Deliberate Practice Loops, MVP Scoping & Validation
Context;
I built this unsolicited design exploration to show how I think, scope, and deliver — using nothing but the public PitchSense AI vision.
88%
74%
Onboarding completed without support
35%
Authentication-stage drop-offs
The Initial Brief
We needed to streamline the process of connecting scientific refrigeration devices to our monitoring platform. Users would scan a QR code on a device, bind it to a refrigeration unit, and claim ownership.
At first glance, this looked like a straightforward authentication and device binding problem.
The Existing Role Architecture
Our platform already had a mature role-based access control system:
Customer Admin
Customer Analyst
Store Admin
Store Analyst
The natural instinct: add a fifth role, build a fifth dashboard.
WHY?
The existing roles are managerial role, they have sensitive data on the dashboard and on app after logging in! And the user group that were going to unload the device, they do not have a dedicated access to the system.
The Design Assumption
The initial approach seemed obvious:
QR Scan → User logs in or signs up
Device Binding → Connect device to a refrigeration unit
Dashboard Access → Grant role-based access
THE FLOW?
QR Scan
↪ Is Device Valid?
↪ No ➡ Error
↪ Yes ➡ Is it a Scientific Device?
↪ No ➡ Load Page that conveys can't Provision
↪ Yes ➡ Sign Up/ Log In
↪ Provision (Bind & Claim)
This was all correct. But we were missing one critical question.
Who Actually Scans the QR Code?
Key Findings
Most device onboarding happens through part-time employees or contract-based workers.
These are temporary staff setting up equipment on their first day. They scan the QR code, bind the device, and move on. They have no interest in analytics dashboards or strategic insights. They're just setup people.
The Design Friction Point
These users don't need a full dashboard. Building one is waste.
They don't need persistent accounts. They're not coming back tomorrow.
Adding them as a formal role creates unnecessary complexity in permissions logic.
It creates unnecessary support burden
The solution
We proposed an anonymous flow—a user path that required no persistent role at all.
The New Flow?
A person scans the QR code with no account required.
↪ Is Device Valid?
↪ No ➡ Error
↪ Yes ➡ Is it a Scientific Device?
↪ No ➡ Load Page that conveys can't Provision
↪ Yes ➡ In Device Bind?
↪ Yes ➡ Public Asset Dashboard Page
↪ No ➡ Device Setup Page ➡ Is it a Truemfg Refrigerator?
↪ No ➡ Provision with a custom name
↪ Yes ➡ Provision with Truemfg SN
In both the cases, you need to either Sign Up or Log In to provision the device, but you can also use just use the anonymous flow to just bind the device with the custom name or Truemfg SN.
So we have a flow for users who do want to claim ownership and access the dashboard, they can sign up or log in at that point. But it's optional, not required.
Anonymous flow—
Provision flow—
Flow comparison—
The Old Flow
↪ Is it a Scientific Device?
↪ No ➡ Can't Provision
↪ Yes ➡ Sign Up/ Log In
↪ Provision (Bind & Claim)
vs
The New Flow