Trent Nguyen.

The thing I've noticed over twenty years of this work is that most teams run research cycles that produce reports nobody acts on. They conduct interviews, synthesize themes, present findings. Three months later the product looks exactly the same. The insight-to-action gap is where most UX programs fail, and it's the problem I've built my practice around closing.

Research only counts when it changes something. That means the work doesn't stop at the findings deck. It means being in the design, in the critique, in the room where the tradeoffs get made. I have always stayed closer to the actual work than most people at my level do, because that's the only way to make sure the research actually lands.

My career didn't start with visual design. It started with IA, strategy, and research. Over time, as the work demanded it, I moved further into delivery: wireframes, prototypes, and polished UI. Today I operate across both. The strategy side tells me what needs to be designed and why. The hands-on side makes sure it actually gets built well.

How research shapes the UI

Most designers make visual decisions from instinct or convention. When you've spent years watching people actually use things, those decisions come from a different place. I know where users read and where they skip. I know which patterns feel familiar enough to trust and which ones create hesitation even when they look clean. I know that the thing a stakeholder calls a "minor copy change" can double task completion, and that an animation a designer loves can obscure the one affordance a user needed to see.

That grounding changes what I reach for in a UI. Hierarchy isn't about aesthetics; it's about surfacing the right decision at the right moment. Spacing isn't decoration; it's grouping logic made visible. When I push back on a layout or insist on testing a pattern before shipping it, it's because I've seen enough sessions to know what will happen if we don't. Research background doesn't slow UI work down. It just makes it harder to fool yourself about whether the design is actually working. That's ultimately what pulled me toward UI. I wanted to close the loop myself, not hand off findings and hope someone acted on them.

What it's like to work with me

I'm in the files, not just in the review sessions. People who have collaborated with me consistently mention that I stay hands-on in ways they don't expect from someone operating at a strategic level. I give feedback early and directly, not to be difficult, but because late-stage polish on a fundamentally wrong direction is the most expensive thing a team can do. I'd rather surface the hard question in week two than discover it in UAT.

I work best on problems that are genuinely complex: healthcare workflows, enterprise data platforms, omnichannel experiences where the edge cases are the real design challenge. The through-line across every engagement is the same: understand what's actually happening in the experience, figure out where and why it breaks down, and fix it in a way the organization can sustain after I'm gone.

Accessibility and inclusion

Accessibility is part of how I evaluate whether a design is finished, not a compliance step at the end. I've run WCAG audits, embedded screen reader testing into research cycles, and helped teams treat it as a shared responsibility. The clearest indicator that a team has matured on accessibility is when no one says "we'll add that later" anymore.

Leadership philosophy

I run teams by staying close to the work. I give early, direct feedback, push for real critique over politeness, and try to make the problem visible enough that people can solve it without escalating. The goal is a team that doesn't need me in the room to make a good decision. The best thing I can do as a leader is make myself unnecessary for the day-to-day and reserve my involvement for the decisions that actually need it.