xxxxx
Vibe Dot · AI-powered IoT recorder · September 2026 launch
My role: Product Designer
Timeline: 2 months, 4 design iterations
Collaboration: 1 PM and 2 engineers
Background
A simple product promise, a complicated reality
Vibe Dot was Vibe's new personal AI recorder, promising to capture conversations, generate summaries, and automatically record meetings without users having to press Record every time.
But as we approached its September launch, several problems might break that promise.
Users were asked to set up Voice ID before understanding the value it delivered. Hands-free recording features were listed among Vibe Dot's device settings. And a hardware limitation surfaced a month before launch: Vibe Dot could only store 8 scheduled recording entries and couldn't update them without reconnecting to the app.
These problems affected whether users could understand Dot's capabilities, start using them, and trust the device to record when expected.
My challenge was to make Dot's hands-free recording understandable and trustworthy without making users figure out its hardware and system complexity.
01 — How much should users learn before getting started?
Vibe wanted users to activate Voice ID early to enable hands-free recording, but the initial onboarding asked users to read scripts aloud before they had even experienced Dot's basic recording and AI summaries.
I explored 3 interaction directions, balancing between "learning about Dot's main features" and "practicing them during setup".
Having users practice everything might help them learn how to use Dot, but it would make an already-long onboarding even longer while a major concern was also discussed that it could be awkward for users to speak aloud in an quiet office or public place. A shorter and instructional approach was faster, but users might simply "Next" through it without learning much.
My decision: Keep basic recording guidance short, while introducing hands-free recording and Voice ID setup as an optional step.
Instead of treating basic recording, quick idea capturing, and hand-free recording as equally important during setup, I restructured onboarding around what users needed to know immediately.
I reduced basic recording guidance to its essential interaction. I kept Voice ID setup skippable, with guided scripts and a brief explanation of how it enables hands-free recording.
This kept onboarding shorter while still giving users a chance to understand and activate hands-free recording from the beginning.
This balanced 2 competing goals: helping users reach Dot's initial value sooner while making them aware of the more advanced capabilities they could explore later.
02 — Important capabilities shouldn't look like minor settings
Users were told "hands-free recording" can smartly capture conversations as they work throughout the day. When they came to Dot's device page, it made them guess. Initially, Hands-free recording like Standby mode activated by Voice ID and Scheduled recording according to user calendar were plainly laid out in Dot's device settings.
The features were understandable one by one. But, putting them among a bunch of minor settings made them easily ignored. Users had to figure out the settings before understanding what hands-free recording could do.
My decision: Focus on user intent, not device settings
I restructured the Dot's device page with 2 recording features to highlight them and collapsed device information and minor settings out of user's first glance.
- Standby: Dot stays ready to capture conversations when certain conditions are met.
- Schedule: Users set up Dot in advance when to record, including through calendar events.
But the 2 features needed different instructions. Schedule is relatively straightforward. Standby isn't. I included a quick onboarding page with short animation explaining how Standby works and why Voice ID is required when Standby is turned on the first time.
I also addressed a subtle but important distinction: turning on Standby doesn't mean immediately starts recording. Showing its "standby duration" and conditions as instant feedback helps users understand what the device will actually do.
For scheduled recording, the same "switch" interface language might confuse users when they "turn on scheduled recording" while "it's not yet the scheduled time". A setting field that expressed what should Dot do in scheduled times conveyed the interaction more accurately.
What changed
Instead of seeing a lot of settings, users could first understand 2 ways Dot helps them record automatically, then progressively learned what required to use them. The UI became part of how the product explains itself.
My aim was to make advanced recording features learnable through interaction instead of asking users to figure out the product's mechanism from settings and instructions.
03 — Why should users have to manage 8 schedule slots?
About a month before Dot's launch, a hardware engineer told me to display Dot's 8 available schedule slots and remind users to reconnect regularly because Dot couldn't receive calendar updates independently while disconnected from the app.
I was like "HOW would users understand 8 schedule slots that couldn't distinguish the same weekday across different weeks"? And "WHY would they track when all schedules on their Dot are recorded so it was time to reconnect Dot to the app"?
Mental model: Users schedule meetings, not Dot' schedule slots.
The bigger risk was PRODUCT TRUST. If users used scheduled recording for their calendar events, they would reasonably expect Dot to record all events. Running out of slots or missing an updated event on calendar could break that trust.
I designed a scheduling framework that handled most of this complexity within the system.
1. Keep upcoming schedules refreshed
Whenever Dot reconnects to the app, recorded schedules are removed and upcoming ones from user calendar fill the available slots. Inform users how far ahead their schedules are covered and receive a notification one day before another reconnection is needed.
2. Handle conflicts before sync-up
Calendar events and custom schedules compete for the same limited slots. I defined conflict-handling rules to surface conflicts between 2 type of schedules when it's needed so overlapping schedules wouldn't silently replace one another.
3. Set expectations early
Dot can't receive calendar changes while disconnected from the app. Instead of hiding that constraint, I included a quick onboarding to communicate the Dot's sync-up requirement when users first use scheduled recording.
Challenging the hardware limit
The interaction model alone still couldn't make 8 slots enough for most users.
I ran a quick survey on meeting-frequency among colleagues who use Dot and estimated that average users with 10–16 weekly meetings need to reconnect around every 5 days. Heavy users like the C-levels and customer-facing roles would have to reconnect every 2 days.
I used this analysis to suggest increasing the slots from 8 to 16, balancing schedule coverage against device-performance limitation as the hardware dev said "It slows Dot, a little bit". The team adopted the scheduling model, and the slots increase was accepted.
What we couldn't solve
Dot still couldn't receive calendar changes while disconnected. If a meeting was suddenly rescheduled after the last synchronization, the device could still hold outdated schedules until it reconnected. I couldn't eliminate that risk through interface design entirely.
Instead, I separated what we could solve such as slot management, schedule replacement, and conflict handling from what we could only mitigate through reconnection reminders upfront.
The goal wasn't to hide hardware limitations at all costs. It was to avoid turning them into unnecessary work for users while being transparent when they could affect recording.
What we delivered and what we could measure
Across the project, stakeholders and engineers aligned on the redesigned onboarding direction, the Standby/Schedule interaction structure, and the scheduling model.
One concrete product change was the increase in scheduling capacity from 8 to 16 slots, informed by my analysis of meeting-frequency survey. Early post-launch tracking also showed that approximately 20% of users had used Standby mode.
What I learned
Working on Dot showed me that simplifying a complex product isn't always about removing settings or compressing flows.
Sometimes it's more like precisely showing what users need to learn, what they might want to to control, and what the product should handle for them.
Across onboarding, Standby & Schedule, and scheduling conflict, this became the foundation of my design decisions, and helped me turn a set of unfamiliar features and hardware constraints into a more coherent hands-free recording experience.
You can also find me on 💁
- 👨🏻💻 Resume
- 🎨 Behance
- 📱 +886 909607406
- 📧 a870588@gmail.com