When engineers sound like they’re speaking alien.
So the firmware manager is showing me around on day one & he’s like –
“When the RAA489000 TCPC PHY detects CC line voltage variations, it updates the connection detect register bits, but remember that the ISL9241’s NVDC mode has different SMBus register mapping than HPBB mode and obviously the battery fuel gauge IC talks to both through I2C but with completely different bit field interpretations for the same charging states. The USB-PD firmware stack reads these registers constantly, but the GUI will show ‘Connected’ versus ‘Disconnected’ for the same 0x01 bit that the SMBus interface reports as ‘CC_ATTACHED_SRC’ and the battery charger reports as ‘ADAPTER_PRESENT_STATUS’…”
I’m sitting there like…
Meanwhile he’s tab-switching between like 5 different software windows. One’s got Enable/Disable checkboxes (why?), another with Active/Inactive radio buttons. Some have hex calculators (??), some are just text fields, others have toggles — literally every form element known to humanity. Plus random hex codes everywhere with the most unnecessarily complex labels you’ve ever seen!
And this guy’s like “so yeah, it’s pretty straightforward.”
Sir, you have 20+ years of experience!?
I’m frantically taking notes thinking I need to become fluent in firmware speak to survive this project. Spent 2 whole weekends down YouTube rabbit holes trying to decode these systems.
Plot twist; after all that, here’s what he actually meant –
When you plug in a charger, some chips notice and flip bits from 0 to 1. Different apps just show the same info with different labels.
Literally that’s it. All that chaos just to say the most basic thing about charging your phone.
Why you can’t hide behind your PM forever
In most product-based companies, there’s usually a PM who speaks human instead of engineer to you. They talk features, user journeys, business goals — stuff that makes sense to designers (who might not be a subject matter expert). But in this project, it was just me, some very smart engineers & zero clue what anyone was talking about.
The market’s kinda messy, team structures are evolving or getting more chaotic (idk?). You can’t always count on having that nice PM buffer layer anymore.
Sometimes you’re the only designer in a room full of techies & congrats! You’re now the translator by default. 🙃
I’ve been super lucky to work with some amazing Sr. PDs, Lead PDs, Managers, & Directors. They all had this one thing down — they’d figure out how your brain works first, then explain stuff in a way that actually made sense to you.
Communication 101 — know your audience, speak their language.
They get that forcing their perspective on people is just a waste of everyone’s time and leads to messy projects.
But sitting through those firmware demos made me realise something.
We designers already have the exact skill we need for this.
Empathy. The same thing that helps us understand users?
Yeah, that works on the engineers too. 🙂↕️
We just gotta put in the work to learn how they think and process info — which, spoiler alert, might be completely different from us. So instead of getting frustrated when these experts sound like they’re speaking in code, I started treating it like a user research problem.
How do these people think?
What actually makes sense to them?
How do I bridge this gap without losing my mind?
Plot twist: They actually think this makes sense
You see when that firmware manager said “so yeah, it’s pretty straightforward,” he wasn’t humble bragging. He actually thought it was pretty straightforward. His brain’s wired like that (hehe, electronics pun intended) after spending years in that world where complex integrated circuit configurations are just Tuesday morning stuff.
Their explanations are simple to them.
It’s pointless trying to restructure how they think or get them to adopt a user-centric approach. And honestly? It’s survival season out here in corporate land, so I hope this helps you navigate whatever technical chaos you’re dealing with.
The faster you accept that they’re not going to change their communication style, the faster you can focus on what actually works — learning to decode what they’re really telling you. Because buried in all that technical jargon is usually something pretty useful for design decisions.
So how do you actually do this without your brain melting? Let me walk you through some real examples of how I cracked the code.
Alright, story time!
Story 1 — The “Users Will Figure It Out” Translation
I’m showing the lead dev some new wireframes & pointing to this section with like 12 toggle switches & I asked, “Should we add some help text here? Users might not know what these control.”
He looks at me like I suggested explaining what a doorknob does. “They’ll figure it out. VBUS_EN obviously controls the enable state, CC1_PD is just pull-down resistors…” and he rattles off more acronyms.
Me in my head — Sir, WHAT is obvious about any of that??
Initially, I thought he was being dismissive. But then I started asking follow-ups like “When someone sees CC1_PD for the first time, what do they usually ask you?”
Turns out, even experienced technicians would ask sales engineers demoing the GUIs which setting to use ALL THE TIME.
Turns out, in his world, these acronyms were as basic as “power button” to us. He wasn’t trying to gate keep — he genuinely forgot that not everyone lived in register-mapping land 24/7.
Design insight 1 –
Engineers think in system logic, users think in task logic. The solution wasn’t dumbing down the labels, but adding contextual hints like “CC1_PD (typically 5.1K for sink mode)” that bridge both worlds.
Story 2 — The Documentation Drama
During usability testing, users kept getting stuck on error messages like –
“Invalid configuration detected in register 0x47”
When I brought this up, the firmware guy was genuinely confused. “But that’s exactly what’s happening! It’s all in section 4.3.2 of the manual.”
I’m thinking, Boss! nobody’s going through a 200-page manual to decode an error message.
But here’s what I learned — to him, the manual WAS the interface. That’s how he used these tools, with documentation open in another window. When I asked him to show me his own workflow for that error, he spent 10 minutes hunting through the pdfs to remember which register bits conflicted.
Design insight 2 –
Engineers often confuse technically accurate with practically useful. The solution was inline error messages like “Register conflict: Power delivery mode can’t be enabled while debug mode is active. Try disabling debug mode first.”
Story 3— The Status Update Translation
My favourite learning moment was working on status indicators. I ask what states users need to monitor and get this response, “Well, they need to track the TCPC connection state, obviously. Plus monitor whether we’re in PD contract negotiation, check if VCONN sourcing is active, watch for any CC line fault conditions, and keep an eye on the power path configuration status. Oh, and display the current EPR state if we’re in extended power range mode.”
My brain — That’s like 47 different status indicators. Our UI is gonna look like a spaceship control panel.
I thought everything was equally critical, but when I asked “What’s the first thing you check when something’s broken?” it was just “Is it connected?” and “Is power flowing?” Everything else was debug detail that only mattered when troubleshooting.
Design insight 3-
Engineers think in debug mode by default. The solution was progressive disclosure — show the essential states prominently, but make detailed diagnostics available on demand.
Here’s the tea.
These experts aren’t trying to confuse you. They’re just operating from a totally different mental model where their domain expertise is everything and user context gets lost in their bubble. Whether it’s engineers, data scientists, legal folks, or any other specialist — once you understand their perspective and start asking the right follow-up questions, their technical word salad actually starts making sense.
Let’s wrap it up!
After fumbling through way too many technical conversations, here’s what I learned the hard way –
What actually works
- Ask about their actual workflow — “What do people usually ask you about this?” is pure gold. Gets you past their assumptions straight to the real confusion points.
- Add context, don’t remove accuracy — Instead of changing “CC1_PD” to “Setting 1,” go with “CC1_PD (typically 5.1K for sink mode).” Keeps the experts happy, helps everyone else survive.
- Progressive disclosure is your friend — Show the basics first, hide the debug nightmare until someone actually needs it. Not everything needs to be visible at once (shocking, I know).
- Treat it like user research — Because it literally is. You’re just studying a very specific type of user who happens to speak in acronyms.
- Ask “what breaks first?” — Cuts through SO much noise. Gets you to the actually important stuff instead of the nice-to-have monitoring.
What doesn’t work (trust me on this)
- Assuming they’re being difficult — They’re not trying to gate keep. They just live in a bubble where everyone knows what TCPC means.
- Trying to change how they communicate — Save your energy. You’re adapting to them, not the other way around.
- Dumbing everything down — Removing technical accuracy usually just creates new problems (learned this one the hard way).
- Taking their “it’s straightforward” at face value — That’s your cue to dig deeper, not nod and move on.
- Thinking everything is equally important — Spoiler: it’s not. Most of their detailed monitoring is just “nice to have” unless something’s actually broken.
Basically, stop fighting their technical brain and start using your design brain to understand it instead. Way less exhausting.
So yeah, that’s how I went from sitting there completely lost while someone explained register mappings to actually getting what these tech folks were trying to tell me. The funny thing is, once you crack this communication thing, it works with everyone — data scientists, legal teams, product managers throwing around metrics. It’s just another design problem to solve, except the users happen to be your coworkers. If you’re currently stuck feeling like everyone speaks a different language, you got this.
Now go translate some technical chaos into something actually useful!
Oh, and if you’re curious about what actually came out of all this technical chaos, I documented the whole project (including all those confusing interfaces I had to redesign) in my portfolio.
Check it out here — it’s way less painful than my learning process was!
Byeeeeee! ✨
The designer’s guide to decoding engineer-speak. was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.