The "User-Friendly" Engineering Framework
Your Product Isn’t User-Friendly. It Just Makes Sense To You.
An engineer ships a feature.
CI is green.
Latency is fine.
No errors in logs.
And yet customers still hesitate.
They click, pause, go back.
They open tickets that start with:
“I thought this would…”
So we respond like engineers.
We add a tooltip.
Write documentation.
Record a Loom.
But the real problem isn’t the missing explanation.
The system behaves correctly — but it teaches the wrong mental model.
And that’s the uncomfortable truth behind user-friendly products:
Engineering doesn’t ship code.
It ships behavior.
I ran into this problem years ago, before I had language for it.
While leading a mobile engineering team, we implemented a feature that let users reuse a card for recurring payments.
There was a constraint:
we couldn’t store full card details, so the card could only be reused in that specific recurring flow, not everywhere.
From an engineering perspective, it was a neat solution. So we explained it like this:
“We’ll save your card for this recurring payment.”
Technically true. But users understood something else entirely.
They assumed their card was saved in general.
They expected it to work in all future payments.
And when it didn’t, they experienced it as data loss.
Nothing was broken in the moment.
The failure appeared later, in a different flow, at a different time.
Eventually, we stopped talking about “saving the card” at all.
We framed it purely as recurring payments.
That’s when it clicked for me:
You can design a perfectly working screen —
and still break the user journey.
The Missing Lens for Engineering Leaders
Good engineering is about building systems.
Great engineering is about making them feel obvious
And that’s the lens most engineering leaders were never taught to use.
Some time ago, I picked up “User Friendly” by Cliff Kuang.
It’s a book about how products quietly shape human behavior — how small design decisions change what people do, what they trust, and how much mental effort they have to spend just to get through their day.
That, to me, is exactly the territory engineering leaders should operate in.
Most engineers were trained to think in systems:
inputs and outputs
contracts and guarantees
happy paths and edge cases
Design, on the other hand, often sounds vague.
Emotional.
Subjective.
But User Friendly makes one thing very clear:
Good design is not about taste.
It’s about reducing human confusion.
I tried to translate that idea into engineering language.
Below is the User-Friendly Engineering Framework, rewritten specifically for software engineers who don’t think of themselves as designers —
but already are.
The User-Friendly Engineering Framework
Each pillar answers one question:
“Why does this system feel harder than it needs to be?”
The entire article with The User-Friendly Engineering Framework materials are available only for paid subscribers. You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!
