A client once asked me a question that took me a few seconds to process:
<div class="aice-quick-answer" style="background:#f0f7ff;border-left:4px solid #2563eb;padding:14px 18px;margin
*"If you don't give it eyes, how are you any different from a software AI assistant like Doubao?"*
I froze. The truth is, I hadn't wanted to add eyes in the first place.
Hardware founders are pragmatists by default. Adding two small screens for eyes meant extra components, driver integration, and higher BOM cost. My knee-jerk engineering logic was simple: eyes don't add functional utility, so cut them to protect the margin.
That one question completely flipped my perspective.
Sure, our device has custom knowledge bases, specific hardware scenarios, and distinct user flows compared to an app on a phone. But to a stranger looking at a device sitting quietly on a desk—why would they bother walking over? What makes them feel this thing has a spark of life, rather than just being a talking speaker?
That's the problem eyes solve.
At the end of the day, emotional connection hooks people faster than a feature list. Features only matter after someone starts talking to the device. Eyes make them want to walk over in the first place. Those are two completely different challenges.
Once I committed to adding eyes, I wanted them to feel genuinely alive, not just like two glowing LED dots.
We designed dynamic, state-driven expressions. The eyes blink and shift with the rhythm of speech and alter based on mood—not canned, looping GIF animations, but real-time state feedback. I wanted it to feel like a character with an actual personality, not a plastic shell with a cartoon sticker slapped on it.
We also built offline interactive micro-expressions—a detail I'm particularly proud of.
Tap the device, and it triggers "good luck" animations—traditional zodiac icons popping up frame by frame. Toddlers reach out to poke them, and adults smile. Shake it, and it gets visibly dizzy, with cross-eyed, exaggerated expressions. All of this works 100% offline with zero latency or cloud dependency.
Why spend precious engineering cycles on this?
Because product personality isn't built by stacking features; it's accumulated through details. You might not remember the exact Wikipedia answer the AI fetched for you last week, but you'll remember the goofy face it pulled when you shook it. That micro-interaction makes it feel like a spunky little companion rather than a cold piece of consumer electronics.
Coming from a hardware background, my default mode has always been utility-first. I've killed dozens of "looks cool but useless" design ideas. Choosing emotional value over raw hardware efficiency was a rare exception for me.
It turned out to be the right call.
Every time I take Amis to pitch clients or demo at trade shows, the eyes are the first thing people notice. Before it speaks a word, before I run a single demo script, people see those eyes moving, walk straight over, and ask: *"What is this?"*
That reaction converts far better than any pitch deck.
Now I keep one rule in mind: Utility makes a product useful, but expression dictates whether anyone gives a damn enough to pick it up.
Have you ever stopped to look at a product purely because of its "face"? I'd love to hear what caught your attention in the comments. If you found this perspective useful, stay tuned—in my next post, I'll dive into more design trade-offs on Amis that were actually worth the extra BOM cost.
