Day 1 Feedback: Heidi Remote – Serious Real‑World Usability Issues
I
Ian Maclean
Day 1 Feedback: Heidi Remote – Serious Real‑World Usability Issues
We started using the new Heidi Remote today with two clinicians. Our first question after day one is simple:
Was this product tested in real‑world clinical environments before release?
User 1 Experience
4 failed attempts using the remote today
No syncing occurred at all
The only data captured was the session start time
No notes, no transcript, no audio
Approximately 2 hours of clinical data lost
One session reported incorrectly as “too short”, despite being ~20 minutes
A major usability issue:
The start/stop button does not respond to a normal or firm press
It appears to require a very light, precise “micro‑press” to work
Long or firm presses do nothing
It took us ~1.5 hours to even work out how to successfully start or stop a recording
This is not intuitive, not discoverable, and completely impractical in a real clinical setting.
User 2 Experience
Better overall outcome
Used the remote across 10 sessions
However:
2 sessions failed to load or work
1 session incorrectly flagged as “too short”
Another failed due to a Bluetooth connection interruption
This raises a major concern:
We were under the impression that the remote did not require continuous Bluetooth connection to function. If Bluetooth dropouts can invalidate sessions entirely, this needs to be made explicit.
Critical Design Flaw: No Recovery or Re‑Sync Option
The most serious issue we’ve identified:
If a session fails to sync, there is:
No ability to retry syncing
No way to force upload/download
No way to reconnect the remote and retrieve data
No way to assign or reattach the session to a new appointment
Once it fails, the data appears to be permanently lost.
For a clinical product, this is unacceptable. Temporary connection issues should never result in irreversible loss of clinical records.
Summary
Right now, Heidi Remote:
Feels unfinished
Is not resilient to real‑world conditions
Lacks basic usability safeguards
Introduces risk of irretrievable data loss
This was day one. Multiple failures, lost data, and significant clinician time wasted. At its current state, this product is not ready for routine clinical use.
We strongly recommend:
Immediate review of button interaction design
Clear documentation on Bluetooth dependency
Robust retry / re‑sync / recovery options
Real‑world clinician testing before further rollout
We want this product to succeed — but right now, it is creating risk rather than reducing workload.
D
Danny Cheng
Hi Ian,
Thank you again for sharing such detailed feedback, and I’m really sorry about this experience. This is not what we expect from the product. We take this very seriously and I wanted to follow up on a few of the key issues you raised.
- Syncing failures and data loss
This is not expected behaviour. Once a session is recorded on the device, data should not be lost. Our engineers are investigating your case as a priority and will do everything possible to identify the cause and recover data if we can. We’ll update you as soon as we know more.
- Sessions marked as “too short”
This is a known issue related to the auto-detect language setting and is not specific to the hardware. For now, we recommend selecting a specific language instead of using auto-detect. We’re working on a fix and may temporarily disable this feature. I’m sorry this affected your sessions.
- Start and stop button usability
What you described does not match our expected behaviour, so we would like to better understand what is happening. If possible, could you share a short video showing how the button responds to different presses? That would help us confirm whether this is a device issue. If so, we’ll replace it immediately.
- Bluetooth interruption and session failures
Bluetooth dropouts should not invalidate sessions. Recording should continue offline and sync once reconnected. Based on your description, this again points to a syncing issue, which we are actively investigating. In normal use, the app continuously syncs when connected, so there should be no need for manual retry and no data should remain on the device.
We understand how serious this is in a clinical setting and are treating it with urgency. I’ll keep you updated.
Best regards,
Danny
Mo from Heidi
Hi Ian Maclean — thanks for taking the time to write this up. This is really helpful (and I’m sorry to hear you lost that much clinical data on day one). We’re looking into the sync failures, the “too short” flagging, and the button press behaviour, and we’ll come back to you once we’ve dug in a bit further.