About
I’m a designer and researcher who works best in complex and collaborative environments. I’m drawn to problems that don’t lead to easy solutions and systems that need to hold up over time, not just at launch.
Most of my work sits at the intersection of design systems, accessibility, and agile product teams trying to move fast without breaking things.
Experience Over Time
Designing at Scale
As my work shifted toward design systems and shared platforms, my responsibility expanded beyond individual features. I began thinking more about consistency, governance, and how decisions ripple across teams and products.
The problems became less about “what should this look like” and more about “how do we make this sustainable.”
Product Design in Complex Environments
Earlier in my career, I focused on end-to-end product design for features with diverse users and edge cases. This is where I learned how to balance user needs, technical constraints, and stakeholder priorities without losing sight of what mattered most.
It’s also where I learned when to push and when to ship.
Learning Through Execution
My early roles were hands-on and execution-heavy. I was learning how to translate research into design decisions, collaborate closely with engineers, and build confidence in my own judgment.
That foundation still shapes how I work today.
My Approach to Design
How I think about design
I come to design through research first. Before I touch a Figma file or Miro, I want to understand the people who'll use the thing I’m designing. Learning their mental models, their workflows, what they're actually trying to do versus what they say they want is my goal. My background as a librarian trained me to think about information architecture and findability in a pretty specific way, and that still shows up in how I approach UX problems.
How I like to collaborate
I'd rather surface a problem early on than polish something in isolation. I work best when there's space for honest feedback. That means sharing rough work, asking direct questions, and being willing to hear when something isn't working. I've spent a lot of time working across roles (designers, developers, stakeholders, clients, vendors) and I think the most useful thing you can do in that context is just make the thinking visible.
How I work
I don't follow a fixed process. The shape of the work depends on the problem, the challenges, and the people involved. That said, I tend to anchor things in research, whether that's a formal study, a few quick conversations, or a close read of existing data. From there, I move into synthesis then design. I try to stay in close contact with my team throughout so decisions don't happen in a vacuum.
What I try to avoid
I like to avoid treating an implemented process as a substitute for judgment and leading with tools. I'm skeptical of the "this tool is awesome, let's use it" impulse. People come first, and I'd rather meet them where they are than ask them to adapt to a method or platform that doesn't fit how they work. I also try not to see constraints as limitations. More often than not, they're just interesting problems worth figuring out.