When technical jargon shuts designers out of the conversation
I was three years into my UX design career when a developer said something in standup that made my brain freeze.
When technical jargon shuts designers out of the conversation
I was three years into my UX design career when a developer said something in standup that made my brain freeze.

“We need to make sure the rewards API call is idempotent, otherwise users could double-claim.”
Everyone nodded. I nodded too.
I had no idea what “idempotent” meant.
I could’ve asked. The developer wasn’t being condescending. The team wasn’t hostile. But in that moment, asking felt like admitting I didn’t belong in the conversation. So I stayed quiet. And that silence cost us three days of rework.
I stayed silent in meetings constantly during my first few years as a designer working with developers. Not because I wasn’t curious. Not because I didn’t care about the product but because I was terrified of revealing that I didn’t understand the technical language everyone else seemed fluent in.
“We’ll need to debounce the search input.”
“This component should be stateless.”
“Let’s add a feature flag for the rollout.”
I nodded through all of it. Took notes. Googled it later, in private, assuming I had written it down correctly.
And when I finally switched careers and started coding, I realized something that made me furious: I wasn’t less intelligent, I just couldn’t see what they were seeing.
Here’s what I mean: When a developer says “the API call needs to be idempotent,” they’re not just using fancy vocabulary. They’re seeing a system behavior that isn’t visible in design tools. They’re seeing: if a user taps a button twice because the first tap feels unresponsive, the server might process two transactions instead of one. The user could accidentally claim $20 in rewards twice. The accounting team would have to manually reconcile it.
All of that lives in their mental model. None of it appears in Figma.
When I was designing, I genuinely didn’t know that double-tapping was a system concern that needed to be designed for. I thought it was an edge case developers handled automatically. It wasn’t that I lacked intelligence. It was that my tools didn’t show me the problem existed.
The asymmetry works both ways.
Developers can’t see what I saw in Figma either. They don’t instinctively notice that a button has 12px padding instead of 16px. They don’t feel the flow break when a modal appears without animation.
But here’s the difference: when developers don’t understand design decisions, they ask questions (Figma makes sure of it 😂). When I didn’t understand technical decisions, I stayed quiet.
Not always. Not with every team. But often enough that it became a pattern. And the reason I stayed quiet wasn’t unique to me… I see it now in every designer I work with.
Technical language functions as a gate. When you’re in a room where everyone else is fluent in a vocabulary you don’t have, silence becomes the rational choice.
Asking “what does idempotent mean” feels like asking “what does this basic word mean” in a language class where everyone else is already conversational. You don’t want to slow down the meeting. You don’t want to seem like you’re not keeping up. You tell yourself you’ll figure it out later.
Sometimes you do. Often you don’t. And the gap compounds.
The cost of that silence doesn’t show up in the meeting. It shows up three days later when the feature ships and something feels off.
In my case, the rewards button I designed didn’t account for the double-tap scenario because I didn’t know it existed. The developer built what I designed. A button with no visual feedback, no disabled state during processing, nothing to prevent a second tap.
During QA, someone on a slow connection tapped twice. The system processed two claims. The bug got flagged. The developer added a loading state and disabled the button after the first tap. It worked. But it looked clunky because it was invented in code, not designed.
We iterated. I redesigned with a progress indicator. He rebuilt. Three extra days. Because I didn’t ask what “idempotent” meant in standup.
I see this same pattern every week now. Different teams. Different products. Different vocabulary. But the silence is always the same.
A designer sits in a technical conversation, doesn’t understand a term, doesn’t ask, and later discovers they designed around a gap in their mental model. The developer isn’t at fault for using technical language. That’s how they think about systems. The designer isn’t at fault for not asking. Silence is a reasonable response to asymmetry.
The problem is structural, not personal.
When I started coding, I thought learning syntax would close the gap. It didn’t.
What closed the gap was learning to see the states and behaviors my design tools didn’t show me. Loading. Error. Empty. Locked. Offline. Rate-limited. Cached. Stale. These weren’t edge cases. They were core system states that existed whether I designed for them or not.
When I didn’t design for them, developers made UX decisions in code. Sometimes well. Often not. And we iterated.
The translation I needed wasn’t technical definitions. It was a mental model of what happens between the screen I designed and the screen users see.
Figma shows me the destination. Code has to build the journey.
Once I understood that, the vocabulary stopped feeling like a gate. “Idempotent” just meant: this action should have the same result whether it happens once or five times. “Debounce” just meant: wait until the user stops typing before searching. “Stateless component” just meant: this UI element doesn’t remember anything between renders.
The concepts weren’t complicated. I just couldn’t see them in my tools.
I don’t blame my past self for staying silent. And I don’t think designers should have to learn to code.
But I do think designers need to see what their tools don’t show them. Not because it makes them better designers. Because it makes collaboration possible without silence.
Im building a framework for this. The complete model of states, behaviors, and system dynamics that sit in the gap between design and code. It’s called How Software Actually Works for Designers. No code required. Just the mental models I wish I’d had before I spent years nodding in meetings I didn’t fully understand.
The waitlist is here.
메타데이터
- post_id
- d438b7af262d
- slug
- when-technical-jargon-shuts-designers-out-of-the-conversation-d438b7af262d
- url
- https://medium.com/@agustina.lanzaque/when-technical-jargon-shuts-designers-out-of-the-conversation-d438b7af262d
- canonical_url
- https://medium.com/@agustina.lanzaque/when-technical-jargon-shuts-designers-out-of-the-conversation-d438b7af262d
- author_url
- https://medium.com/@agustina.lanzaque
- status
- ok
- fetched_at
- 2026-06-26 12:24:55