A few months ago, I asked for design book recommendations to create better interfaces for clients.
I did start with them. But the books and blogs initially fell short. Or rather, I didn't get the most out of them.
What worked really well was designing products, putting them in front of users, getting brutally honest feedback, and iterating rapidly. This feedback was painful to hear but became the fastest way I found to shortcut the learning curve.
Also once I started designing, I absorbed design principles from books and blogs more effectively. The ideas connected to my experiences, like leaves attaching to the knowledge trunk I was developing. Earlier, it was just a bunch of leaves floating around with no place to hang them.
This post shares two design principles I wish I'd known earlier. These blindspots are common among engineers because we think differently than regular users.
These two principles came to me after watching people struggle with my interface designs and reflecting on those observations. I'm sharing them here in case they help you.
Here's the first lesson:
Don't Show Off Technical Complexity
When building something complex, your engineering instinct wants to showcase all the powerful features.
It's like building a jet engine and wanting to impress users with all the controls and switches by taking them to the cockpit.
But imagine a beginner who just wants to get from point A to point B.
If you put them in a jet cockpit and tell them to fly, they'll be overwhelmed by all the controls. They might not even know where to start and just walk away.
This trap is especially easy for engineers to fall into. We love our complex systems.
Instead:
- Meet users where they are
- Only reveal what users need for their immediate task
- Progressively reveal complexity when they're ready for it
- Focus on what users actually need to accomplish
Start with simplicity.
Give users a "go-kart" with just start/stop buttons.
As they grow comfortable, gradually introduce more controls. Then maybe an automatic car, then manual transmission, and eventually the jet engine.
This approach requires deep thinking about user journeys and ruthless prioritization. You must constantly ask: "Does the user need this right now?"
The easier approach is to show all the controls and switches. But that's not what users need.
I made the same mistake early in my design journey. After watching users struggle with my interfaces, I can't unsee it in my work and in previous startups I worked at.
If you need inspiration, look at Vercel. They offer complex frontend-cloud tools for developers.
When I started using Vercel, I was productive immediately. I was starting from scratch leaning about frontend development and still I din't feel overwhelmed or anything like this.
From Day 0, I was able to deploy my frontend apps with ease.
As my skills grew, I discovered more advanced features that were revealed when I needed them. I never felt overwhelmed.
Their developer experience ranks among the best I've seen and represents what I aim to create.
So that is the first lesson:
Meet users where they are.
The second lesson was equally painful to learn.
Fix the Product, Not the User
When users get frustrated, your instinct is to provide instructions: "Do this, then that."
The solution seems obvious to you.
But for users, you're asking them to perform mental gymnastics. Good design should feel like a walk in the park, not a training exercise.
Empathy fades when you're immersed in your code or use your product daily. This happens especially with engineers.
View frustration as insight. Each point of confusion reveals design opportunities.
When users report problems, I now assume the issue is with the product's design language. I fix the root cause instead of explaining workarounds.
The best designs need no documentation. They're intuitive.
Users rarely directly express struggles. Watch for these signals:
- Workarounds and hacks
- Abandoned features
- Limited product usage
These signal deeper issues.
When users struggle:
- Blame the product, not the user
- Fix the frustration source
- Adapt your mental model to users, not vice versa
This requires seeing your product through fresh eyes.
Products that feel effortless retain users longer.
As engineers, this challenges us. We create complex solutions and expect users to adapt. Great design means doing the hard work so users don't have to.
So what's the takeaway from all this?
Learning Through Building
These lessons came from creating real products and watching users interact with them. No amount of reading could have taught me what I learned by simply putting my designs in front of real people.
Books and blogs are valuable foundations, but they only clicked for me after I had practical experience to connect them to. That's when theory transformed into understanding.
The feedback loop of building something, watching users struggle with it, improving it, and trying again taught me more in months than years of passive learning could have.
So my advice? Start building now. Put your work in front of users early. Embrace the uncomfortable feedback. It's the fastest path to becoming a better designer and creating products people actually want to use.