Process

Most designers hand off to engineers. Most engineers implement what they’re handed. I’ve always been suspicious of that gap — it’s where nuance gets lost, where accessibility gets deprioritized, where the thing that ships looks a little less like the thing that was designed.

Having both skill sets doesn’t mean I do everything alone. It means I speak both languages fluently. I can design something in Figma knowing exactly how it might be built, and I can build something knowing exactly what the designer intended. That fluency makes me a better collaborator, a faster executor, and a more honest advocate for the user.

Accessibility has been important to me for a long time.

In college, I sat on the boards of organizations working to lower barriers to earning a CS degree for women, people of color, and people with disabilities. At Microsoft I owned accessibility for my team, which in practice meant I was the one in the bug queue, fixing the issues that made our product unusable for people relying on screen readers, keyboard navigation, and other assistive technologies.

That experience changed how I design. I don’t think about accessibility as a checklist you run at the end, but as a constraint that makes everything better, the same way designing for mobile first makes desktop layouts stronger. If you can’t navigate your product with a keyboard, your interaction design has a hole in it. If your contrast fails, your visual hierarchy was never as strong as you thought.

This website was built with WCAG 2.1 AA as a baseline. Skip navigation, visible focus states, semantic HTML, aria labels, prefers-reduced-motion support were my first principles. I hope you can see the care I put into building this website :)

I admit I used to be a luddite when it comes to AI for many reasons, but one of them was also because I was worried about what it meant for work I cared about.

I’ve watched the job market shift dramatically in the past year. Both software engineering and product design roles are changing faster than anyone predicted, and honestly for a while I was worried about if my previous experience was even useful or sought after anymore. I thought the answer was to resist that change, to prove I could still do things the old way.

Building this website with Claude Code changed my perspective. I worked faster than I ever have on a front-end project. I wasn’t writing every line of code myself, but my engineering background meant I understood everything being written, could catch mistakes, push back on bad implementations, and make real decisions rather than just accepting whatever the model produced. My design eye meant I could direct Claude Code the way you’d direct a skilled collaborator: with intent, with taste, with specific feedback.

What I realized is that AI doesn’t replace design thinking, it accelerates it. The structured problem solving, the user empathy, and the judgment calls still have to come from a designer. Frameworks evolve, methods evolve, tools evolve, but the need for structured problem solving will never disappear. We’re just able to move a lot faster now, which means the thinking matters more, not less.

I’d rather be better than stay bitter. And I think this is a genuinely exciting moment to be jumping into product design.

Every project starts with the problem, not the solution. I research, I talk to users when I can, and I write things down before I open Figma. I prototype early and test with real people. I care about what ships, not just what’s in the deck.

I work best on cross-functional teams where design and engineering are in conversation from day one, not handed off at the end.