How I think
Before I design a feature, I need to understand why it should exist.
A feature request is usually just the starting point. I begin by asking:
- What are we trying to achieve?
- What evidence is behind the request?
- What should change?
- Are we solving the right problem?
Every project starts differently. Sometimes there’s research to build on, and sometimes there’s only a request or a sense that something isn’t working.
The process may change, but the questions I ask stay consistent.
Questions I keep asking
What are we actually trying to solve?
Before thinking about layouts or interactions, I want to understand what success looks like.
What are we trying to change? Who is affected? Why now? And is the proposed solution addressing the real problem, or only its most visible symptom?
On the Enterprise Analytics project, that reframed the ask from ‘add more charts’ into building a trustworthy analytics model organized around the questions admins were actually trying to answer.
What don’t I understand yet?
I don’t like designing around assumptions I haven’t examined.
I research, ask questions, and talk to the people closest to the problem until I have enough context to make a thoughtful decision.
On the Irrigation Controller, that meant validating the interaction assumptions directly with technicians in the field before locking in the design.
Am I still right?
I’m comfortable changing my mind.
When new information reveals that I misunderstood the problem, I adjust quickly.
But when the research points in a different direction, I’ll say so—even when it’s uncomfortable.
The goal isn’t to win the argument. It’s to help the team make a better decision.
On the Design System, when it became clear implementation wasn’t going to catch up on its own, I changed direction — expanding into the engineering workflow to move the shared foundation into production.
Is this really ready?
Approval isn’t the finish line.
I stay involved through implementation, review the product before release, and work with engineers to refine the details and protect the reasoning behind the design.
On the New Models Wizard, that meant carrying the design from Figma into a working front-end artifact, then partnering with engineering through review and implementation to protect the reasoning behind the flow.
What’s missing?
Some of the most valuable work I’ve done started with a gap that wasn’t formally assigned to anyone.
At Tabnine, that included analytics and developer interviews during my first months on the team — and, most clearly, the Design System, which was an unowned gap between Design and Engineering until it was formalized and connected to production.
When I see something limiting the team’s ability to understand users, make decisions, or scale, I usually start by giving it shape.
Working with me
I ask a lot of questions—not because I want to question everything, but because clarity early usually saves time later.
I’m direct, collaborative, comfortable changing my mind, and likely to stay involved long after the design review.
And yes, I probably left the Figma file cleaner than I found it.