Records spinning, a candle that smells like rose espresso, and the snacks I refuse to design without. Hover to peek inside my world →
A few of the things on rotation lately: flowers, focus, and a perfectly iced oat latte.
So what's a Computer Science Engineer doing here?
Honestly? I started where most CS students do: writing code, debugging at 2am, wondering why interfaces were so confusing to use. Then I took a Human-Computer Interaction course and something clicked. The problem was never the code. It was the experience around it. Before that click, I'd published two research papers on AI systems, in IEEE and Springer. Peer review is where I learned to defend a decision with evidence, which turns out to be most of what UX research is too. I've spent every moment since learning how to design that experience, through internships, research, teaching, and now a Master's in Human Factors & Ergonomics at SJSU. Turns out, knowing how something gets built makes you a lot better at designing it.
"UX is the space between what someone needs to do and how effortlessly they get it done." A user should never have to think about the 'how', only the 'what.' The moment someone notices the steps it took to get somewhere, something went wrong.
"Good design, when it's done well, becomes invisible. It's only when it's done poorly that we notice it."
Jared Spool
That's what I'm chasing: experiences so intuitive they disappear.
And I plan on chasing that for the rest of my career.









Talk to people. Not sketch, not research competitors. Talk to the actual humans who have the problem. In FreshBite, I ran surveys, focus groups, and user interviews before a single wireframe was drawn. That research improved our task success rate by about 40% through usability testing, because we built the right thing, not just a thing.
I refuse to pick. A beautiful design built on bad research is just a pretty mistake. I've run surveys, focus groups, usability tests, and interviewed both users AND service providers, because the full picture matters.
I've been on the other side of the handoff. I know what it's like to receive a design spec as an engineer, which means I document interaction states, edge cases, and component behaviors clearly enough that engineering doesn't have to guess. On ACME Phoenix, that was the whole point: a console investigators could trust because every state was accounted for.
As a thinking partner, not a shortcut. I use AI to brainstorm directions faster, synthesize research insights, and pressure-test my problem framing, but every decision that makes it into a final design has gone through my own judgment first. AI helps me move faster. It doesn't replace the thinking. And honestly, knowing how to prompt well is its own skill, one I've been deliberately building.