I was wiring up exciting new features for my language learning platform. I spent several evenings in the code structuring the database models, writing the backend, and assembling the frontend. By the end, the interface felt obvious and intuitive. I was very proud!
I asked a friend who had never seen the project to try it. They stared at the screen, clicked on an unrelated navigation option, hesitated over the primary action button, and asked: "What do I do now?"
It was a very sore reality check. When you spend days immersed in a codebase, you construct an intimate internal map of how every piece connects. You know which tab holds the settings. You know what the shorthand labels mean. You know that State A must precede State B, etc, etc. All of that context lives rent-free in your working memory. Because of that bias, you are the single least qualified person to judge whether a newcomer can use your interface.
The curse of knowledge is everywhere
This gap between builder intuition and user reality is not limited to frontend layout. It shows up across almost every artifact that engineers produce. This doesn't just apply to writing software either; it applies when you're building physical products too.
Many developers write personal READMEs or quick runbooks to remember how to generate a database export or run a local migration. Many open source projects on GitHub have long, elaborate READMEs touting the benefits of every feature they're offering.
When you write those notes while deep in the task, the steps seem clear, fluid, and self-explanatory. Revisit that same document a few weeks later after the mental context has cleared, and half the steps are incomprehensible. Most people think conceptually rather than purely step-by-step. Because those mental assumptions occur automatically, we often skip recording every granular step and leave our future selves and others scratching our heads.
Early-stage tech startups fall into a similar trap. A team announces a major release with huge internal fanfare, but when you open their homepage, you are greeted with total abstraction:
ShinyTech is an efficient, scalable Fipple for your existing Package Fuzzler. Take a look at our pricing structure and see if you qualify for "ShinyTech for Enterprise".
Inside the team's office, everyone understands what "Fipple" and "Package Fuzzler" mean within their system architecture. To 99% of people outside their bubble, it reads like random noise. The founders have spent so long talking to each other that they have lost the ability to explain what problem they are solving in plain language.
Well-run engineering organisations often hand tutorials, FAQs, onboarding packs, setup scripts, etc to new hires with a mandate to follow the steps, note everything that breaks or doesn't make sense, and update the docs.
This sounds like grunt work, but it is vital. Senior engineers on the team have developed muscle memory for every paper cut. They know that .env.example is missing a secret, that Docker Desktop needs a restart after sleep to prevent weird wake behaviour, and that a local service binds to port 5555 instead of 3000. They do not notice the friction because they instinctively steer around it. A new hire has no internal map yet, making them uniquely capable of spotting the gaps.
Friction logs
Some teams at Google formalised this observation into a practice called friction logging.
A friction log is:
...a live diary written while attempting to complete a specific user scenario from scratch (such as "install the CLI and deploy a sample application"). As you move through the workflow, you record every action you take alongside your direct reactions.
- Which buttons or links you clicked
- Where you stopped and had to guess what to do next
- Terminology that confused you or assumed prior context
- Error messages that gave no clear path forward
- The difference between what you expected to happen and what occurred
The difficulty in friction logging lies in deliberately suppressing your insider knowledge. You must fight the impulse to fix a minor bug on the fly or reach for a familiar terminal workaround. This is why newcomers excel at friction logging - they do not know enough about the internal mechanics to bypass the flaws.
Usability testing can be surprisingly cheap
Many builders skip UX testing because they assume it requires an enterprise budget to organise dedicated focus groups, observation rooms, eye-tracking monitors, and formal research reports.
Manyyears ago, the Nielsen Norman Group theorised and measured how many test users you need.
In summary: - A single test user typically uncovers about 31% of the usability problems in an interface. - Testing with just five users surfaces close to 85% to 90% of the total usability defects.
Usability Problems Found (%)
100% | * (5 users ~ 85%)
80% | *
60% | *
40% | *
20% | * (1 user ~ 31%)
0% +--------------------------------------------
0 1 2 3 4 5 6 users
Beyond five users, the curve flattens significantly. You watch different people hit the exact same snags. The return on investment drops.
You do not need fifty participants. You need five people willing to sit down for fifteen minutes while you give them a clear objective without coaching them. If four out of five struggle to find the search bar, you know there is a real problem to address.
Take the ego hit early
Engineers and founders often avoid watching people use their products because watching someone struggle with your creation is uncomfortable. They have spent weeks of their life obsessing over data structures, colour contrasts, and responsive layout. Watching a user click the wrong element can feel like a direct criticism of your competence.
You need to embrace that ego hit early.
You are not building solutions to admire your own design patterns. You are building solutions to solve an external problem. When a user points out that a workflow feels disjointed or that an icon conveys nothing, they are giving you the exact adjustments needed to make your product usable.
Step away from the desk. Hand your chair to someone unfamiliar with your product, ask them to complete a task, and watch in silence. You will discover more in five minutes of observing real usage than in five days of "polishing" in isolation.