What I Learned About Product Design as an Engineer
Hassan Saado
Aug 31st, 2025
I've been wanting to write a blog for a long while now, and finally I am happy to share my first post. Working within the AI field I initially thought about several topics within the AI domain that I could write about, but then i was reminded of my Linkedin flow and that everyone is writing about AI lol, so my first post is about another thing I have become passionate about lately, which is product design (don't worry, AI blog posts will definitely come).
Some of what I'll share might super sound obvious, but the truth is it's often ignored when building products. So here's my take: 7 things I've learned about product design as an AI Engineer.
1. It's the small decisions that make UI/UX world-class
World-class products don't happen because of one big design decision. They happen because someone cared enough about the little ones.
The difference between a decent UI/UX and a world-class one usually comes down to many small choices that add up. Having the main functionality in place doesn't mean the product is finished. It's the small details that decide how it actually feels to use, and whether people enjoy it enough to keep coming back. As the Swedish saying goes: "Många bäckar små gör en stor å," translating to: many small streams together make a big river.
Here are a few examples to illustrate my point:
- That extra 100ms delay that makes an action feel slow and frustrating.
- The number of clicks. Even a single unnecessary click is a failure.
- Consistency in borders, padding, font sizes, and spacing.
- A clear color system with good contrast and shading.
- Tiny layout choices in menus and forms that keep the interface readable and easy to navigate.
2. Superpower to set yourself in the user's shoes
Making assumptions about the user is one of the easiest traps to fall into and one of the most dangerous. I've caught myself doing it plenty of times, thinking I know how someone will interact with a feature, only to watch them do something completely different. That's why the real superpower in product design is being able to put yourself in the user's shoes.
The best people in design are the ones who really get the user. They can almost predict how a user will feel about a new feature, and they understand the pain points on a deeper level. I do think this is a skill you can train and improve, but it's also tied to personality and worldview.
Users don't always tell you what's wrong directly, where the real insights often come from small signals: a pause before clicking, a repeated tap on the same button, a little frown when something doesn't behave as expected. Spotting and acting on those subtle signals is just as important as listening to what users say out loud.
Here are some things that help along the way:
Mindset driven:
- Be empathetic and open-minded
- Really care about the product
- Be driven by helping the user
User focus:
- Pay attention to the small signals such as body language, hesitations, repeated actions
- Talk to users often and gather feedback as much as possible (this honestly can't be overstated, see next section)
3. Iterative feedback from users
Having an iterative workflow is a well-established practice in software development, but it's just as important when building the product and the overall user experience. Frequent check-ins and feedback sessions with core users are by far the best way to figure out what to build, and if what you're building actually solves their problems.
From experience, I've noticed that most users tend to highlight the same confusing parts of the product, the same missing features, and the same areas to improve. Another big benefit of doing this often is that you reduce the risk of building something no one needs, which means less wasted time.
What I really enjoy is the back-and-forth with users where each iteration brings you a little closer to what they actually want. And when you finally land on that version where the user is completely satisfied… that feeling is such bliss.
4. Don't expose technical details
As engineers, it's easy to overexpose technical details to users, forgetting the negative impact it can have. We fall into the trap of assuming they care about the same things we do, but users don't want to dive into the technicalities, they just want a product that solves their problem with minimal effort.
One typical example is overloading an interface with options such as configurations, settings, and parameters… we think this gives users control, but in reality it overwhelms them. The fewer choices they face, the better the product feels. This ties directly to the idea of "decision fatigue" where every extra choice drains mental energy, and as a result the user experience takes a hit.
5. First impressions matter a lot
It's scary how fast a user makes up their mind about a product. You can spend weeks building something, only for a user to reject it within seconds. The easy reaction is to blame them for being impatient or not "getting it." But in reality if the product doesn't feel right from the very first moment, that's on you.
Why first impressions matter:
- The initial experience shapes a customer's overall perception of the product and brand.
- A positive first impression makes users more likely to stick around and start using the product.
- First impressions are rapid, gut-level judgments based on visual and verbal cues, and they're highly influential.
If the UI feels clunky, uninviting, or just off, users won't give it a second chance. Add a complicated onboarding or a steep learning curve on top of that, and most users won't even bother to use the product. Studies even show that users form an opinion about a product's credibility in under 50 milliseconds, which means your first impression really is everything.
6. Build features to solve a specific problem
The point is simple: identify the pain point first, then build the feature that solves it. Otherwise you are just adding noise.
This one might sound obvious, but in practice it is often overlooked. Too many products end up adding features because they seem cool, competitive, or "nice to have" in theory, while in reality they solve no real pain point. You see this a lot in AI, where products add the same generic functions like generate, summarize, or rewrite. These are added more out of FOMO than actual user need, and most users already have access to the exact same features in ten other tools.
Why this matters:
- A feature only adds value if it directly addresses a problem the user actually has.
- When a feature removes friction or pain, users adopt it naturally.
- Each feature costs time to design, build, and maintain. If it does not solve a problem, that time is wasted.
7. Someone has to take the product perspective
Engineers aren't inherently product-minded, and our instinct is often to focus on the technical solution rather than the bigger picture. That's why it's so important to have someone who owns the product perspective. Whether it's a PM, a designer, or simply an engineer who has developed that mindset, this role is what ensures the team stays committed to solving real user problems.
For me, this has been one of the biggest learnings: great products don't just come from great code, they come from great product thinking. My goal moving forward is not only to grow as an engineer, but also to sharpen that product mindset so that what I build isn't just technically sound, but genuinely valuable for the people who use it.