What I've learned as the sole designer on a team of scientists and engineers
June 2026

Never pretend you understand, keep asking stupid questions.
Never delete anything.
Don’t be afraid to rationalize design into a science, but remember it’s an art, too. Making software work is a science. Making it work well, even. Making good software that works well? Some mixture of both, probably. But guess what: we can argue about science, that’s what makes it science. It’s a process that we can adhere to strictly or loosely. Think of art like science that we can point at.
Being torn between marketing and product; I’ve always leaned technical but couldn’t help but build comb-shaped skills and passions.
Engineers are our primary stakeholders. Even though our job is to advocate for the user, building trusting and harmonious relationships with the engineers on our team is the path to a better product. Even in the agentic era where we can proverbially or literally open pull requests, we’re still beholden to the data, security, and network infrastructures that are overseen by engineers. It’s worth developing the rhetoric skills that take engineering perspectives into account.
“Feedback is a gift, but there’s more things to do than time.” A quote from the CEO (and fellow Product team member). I tend to agree. Feedback triage is a skill that develops hardiness quickly. The crux is finding the right time to ask the right person for feedback, and only letting them ramble if it serves a purpose.
The effort paradox: big design choices require outsized justification, small ones struggle to make it into prod. The natural next step might be “learn to code or use an agent well and push changes yourself.” Then your time is split; carve out a weekly day for pushing improvements.

Also check out

Back to Top