You’ve seen the work. Now interrogate the person.
Hey there, I’m Yuti ♪

Product designer who learned to ship, not just spec. I design the product and the system underneath it, usually with Figma and a terminal open at the same time.
Designer, and increasingly comfortable in code. In a field moving this fast, with the tools we have now, learning to build isn't a different job; it's part of this one. I can take an idea to a working prototype without a translation layer, which is usually where intent gets lost. And I'm always picking up the next skill; that's the fun part.
It means I built one, alone, and put it in production, Lumen, open source, the whole thing. Not "maintained the Figma library." Not "contributed a few components." I made the call on token naming, on what to include and what to leave out, on the convention that lets Figma and code finally agree. The hard part of a design system was never the buttons. It's the opinions, and I have them.
It's less of a stretch than it sounds. My undergrad was in Visual Communication, my Master's in Experience Design, and lately I've been learning to build products end-to-end, so the research, the design, the visual, and the front-end already live in one head. That tightens the loop: no telephone game between the person who knows the user and the person who picks the type. The honest trade is depth; I'm not the single deepest specialist in any one lane. I'm the person who keeps them from contradicting each other.
I work solo well; I built Lumen with nobody else in the room. But solo is just where I've been, not where I'm best. I'm sharper with a team to spar with, I lean hard on feedback and real data so the work isn't just my taste in a vacuum, and I care about the people on the other side of the screen as much as the system behind it. The honest catch: I move fast and I hold opinions, so I want people around me willing to push back, and I mean want.
Most onboarding is an apology for a product that didn't explain itself. If the first run needs a five-step tour, something failed upstream and the tour is the bandage. The best onboarding I know recognizes the person instead of teaching them, a higher bar, which is exactly why most teams reach for the tour instead.
I command it, I don't chat with it. Claude Code, Cursor, and a Figma MCP pipeline stay open while I work; I move from a Figma node to working code without redrawing it by hand, and I treat the agent like a fast junior I review closely, not an oracle I trust blindly. The skill was never prompting. It's knowing what to delegate and what to never hand off.
Build the smallest ugly version of it. I'm useless in the abstract and pretty good the moment there's something real on the screen to react to, so I get to "real and bad" as fast as possible and let the thing tell me what's wrong. Talking about a design is the slowest known way to improve it.
That polish is a virtue. I used to buff things to a shine before showing anyone, and most of that effort was insurance against being seen unfinished. Now I'd rather ship at eighty percent and learn the last twenty from contact with real use than perfect a guess in private.
A team building something where taste and systems both matter, sharp enough to push back on me. Based in the States. The contact link's right there; bring me a hard problem.