Two projects, one question underneath both: how much should the system decide, and how do you make that boundary legible enough to trust?
I keep relearning the same lesson across every project that touches AI: it's only useful once it's found the right scenario to sit inside. AI has to integrate into the work, not the work bend to fit the AI. I don't ask AI to "make it smarter" or "make it feel more AI." I ask it to do one specific thing: cluster raw interview transcripts by problem type, narrow a field of candidates before a human decides, hold a conversation's context so a driver doesn't have to. Those are tasks where speed and pattern-finding remove real friction without removing my judgement, or the user's, about what actually matters.
The two projects below are the clearest version of this I've built: 1Soul, where AI mediates a human relationship decision, and Xiaomi Auto's digital cockpit, where software mediates a human's control of a physical machine at speed. Different domains, same underlying design problem.
Both projects put a system between a person and a consequential moment: who they'll meet, or what their car does next. In both, the wrong move is the same: let the system quietly decide more than the person realises, and trust breaks the instant they notice. The right move is also the same: make the boundary between "the system narrows this" and "you decide this" visible, stated, and consistent, not just implied through polish.
Research surfaced a specific fear: a match arriving with a name but no context, and an implicit expectation to just trust an algorithm's judgement about who to meet. The fix wasn't more reassuring copy, it was a mechanic: Cupid narrows candidates and offers one small, human clue first, and the decision to go further is restated as explicitly hers, every time. The AI's authority stops at "worth considering"; it never quietly extends into "worth meeting."
A digital cockpit is the same trust boundary at higher stakes: the system is making micro-decisions about what to surface (a navigation update, a driving-assist prompt, a rear-display alert) while the driver needs to stay in control at speed. The design work was about sequencing and hierarchy: what the interface says now versus what it holds back, so a driver's attention is never split between "what is the car doing" and "what should I do," and every automated suggestion reads as a suggestion, not a fait accompli.
Written side by side, the throughline is a working principle I now carry into everything: an interface earns the right to automate more only by first making it completely legible what it isn't deciding for you.
When I audited 1Soul's homepage, the question wasn't "does this look nice"; it was "would a stranger actually believe this is a serious product built for them." I broke that down into four things a visitor's brain checks in the first few seconds, roughly in order: is this real or a novelty, who's actually using it, does it understand why they hate the alternatives, and would meeting someone through it be safe. The homepage as it stood had a gap at every one of them.
The plainest example was the copy itself. The public-facing line was "Your agent is already dating on your behalf." Meant to sound futuristic, it actually said the exact thing a first-time visitor is primed to fear: that the AI, not them, is the one making contact. It's the same boundary-legibility problem I describe above, just failing inside a single sentence instead of a whole flow. I rewrote the hero around a plainer promise, built for people who want something serious rather than another feed to swipe, and moved the "AI narrows this down for you" framing to where it actually helps: after someone already trusts the product enough to want the shortcut.
The brand tone told a quieter version of the same story. The site ran on a deep maroon that a couple of testers independently described as feeling "like a magic book": moody and mysterious, better suited to a fantasy app than a platform whose entire premise is who your next serious relationship might be. If a colour choice needs explaining before someone understands what kind of product they're looking at, the palette isn't doing its job.
Safety became its own section, not a line item. Every interview came back to the same unresolved worry, meeting a stranger from an app, and the homepage answered it with one reassuring sentence buried mid-page. I pulled safety out as a first-class section on its own, and rewrote it around specific, checkable mechanisms rather than adjectives: verified student and real-identity accounts, first meetings held at verified campus venues, background context on a match before you meet them, visible ID checks at in-person events. The principle I took away and still use: a safety claim only works if it's backed by a feature you can point to. An unsupported "we're safe" reads as worse than saying nothing at all.
I restructured the rest of the homepage around the order a visitor actually needs answers in: lead with the pain points real users named (dating fatigue, conversations that go nowhere, feeling disrespected) before any feature list; translate every feature into the benefit it protects ("not endless swiping" becomes "every match is vetted before you see it"); and only then bring in social proof and the product's more playful ideas, like a "Secret Match" campus event kept genuinely surprising rather than over-explained.
None of it was about making the product louder. It was about closing the gap between what the founders already knew to be true about 1Soul, and what a stranger, given five seconds, could actually tell.
Working inside a team shipping system UI across a real product line is a different discipline to designing one screen. The interface has to hold up across car variants, screen sizes, hardware configurations and languages (Chinese first, then English as the international rollout followed) without the underlying logic falling apart at any of those seams.
The clearest lesson was about compensating for hardware with design. Apple's Dynamic Island made its designers famous for turning a hardware limitation, a front-camera cutout, into a feature. At Xiaomi Auto, that's not a rare, celebrated exception; it's routine. Different devices have different comfortable reach-zones for a driver's hand; a rear-entertainment screen added to one car variant could, in an edge case, partially block the rear-view mirror. In an industry still young in China, hardware rarely arrives perfect, and design is often the last, quiet layer that makes the imperfect thing usable. My mentor once took what should have been three separate hardware hubs and, through interaction design alone, made them read as two.
I also learned to use AI as a second check on my own judgement rather than a replacement for it: running a shadow system or a colour decision back through AI to catch what my eye had gotten used to, while still making sure I could produce the same quality of work without it. That's become a working rule I hold everywhere now: AI should sharpen a decision I've already made, not make it for me.
In practice that meant building Figma Make and Gemini into the actual design loop, not just using them for inspiration. I'd use them to explore a wider set of directions in the time it used to take to sketch two or three, which let iteration move faster without cutting corners on how many options actually got considered. But the more useful habit was running my own decisions back through AI to reverse-verify them, rather than only asking it to generate: feeding it a colour system I'd already chosen and asking it to independently optimise for contrast and hierarchy, then comparing its answer against mine to see whether my choice actually held up or whether I'd just gotten used to it. I did the same with grouping and layout. For a screen with a lot of competing functions, I'd let AI work out its own best path through the information architecture, then treat any place where it diverged from my structure as a prompt to ask why, not as an answer to copy. AI stayed a way of pressure-testing my design, never the source of it.
The last lesson was about scale. At a startup I owned a project end to end, research through shipped product. At a company the size of Xiaomi, nobody does; every person owns one link in a much longer chain, and being good at the job means understanding your link well enough to hand off cleanly in both directions. It reframed how I think about my own range: not as one person who can do everything, but as someone who can plug into a chain at almost any link and still move it forward.