As a product designer, you probably think you’re breaking new ground all the time. This is, after all, an exciting field to work in these days. What with a whole new generation of digital tools at your disposal, not to mention the industry-wide shuffling of priorities resulting in a new, user-focused paradigm, the rules have totally changed, right?

Maybe, but if you really look deeper into what drives product design — actual people — things really haven’t changed at all. Humans are humans and their behavior changes very slowly over the course of time. Chances are, you’re designing products for people who think and behave very much like the people your industry forebears were designing for.

But it’s true: a generation ago, what did they know about Agile? And surely, without the benefit of all the digital tools we have today, collaboration back then weak, at best, right?

Perhaps, but there’s still a lot to learn from designers who were doing their thing half a century ago. So while it’s true we have great collaboration tools and today’s design teams are hyper-aware of how important it is to focus on the end user throughout the entire design process… there are still some common truths about product design that haven’t changed at all…

4 Common Traps to Avoid in Product Design

These are some rules that haven’t changed in our industry. To make them easier to digest, we’re giving them to you in the form of mistakes you don’t want to make.  

1. Focusing Too Much on Features

OK, we’ve all been guilty of this one at one time or another. Hopefully, that time for you was long ago but we’d understand if it wasn’t because this is a very common trap for designers: getting too wrapped up in creating cool features. What’s the problem? If you’re spending all your time geeking out on designing cool features, you’re apt to lose sight of the real problems you’re supposed to be solving.

Remember: you have a customer and that customer runs a business that has real problems. They came to you to solve those business problems. While they may appreciate some ‘wow’ factor in the product you design for them (and even that’s not a given), that’s not what’s going to get you the final nod of approval in the end.

Features are great but the product roadmap should be more than a list of features. It should really be a blueprint for solving business problems. And how do you know what those problems are and how you’ll go about solving them? See below, where we talk about one of our favorite topics around here, the Discovery Phase of the Making Sense product design process.

2. Losing Sight of Reality

When you’re designing products as part of a team, it’s easy to get caught up in the ‘process’. That can make it hard to focus on what really matters, which is the end user. And yes, while everyone talks about keeping the end user in mind throughout the entire design process from start to finish, sometimes that’s not enough.

You see, thinking about the end user is great, but actually going out into the real world and seeing the life of the people you’re designing for is even better. Likewise, discussions about the end user are helpful but real-live observations that stem from walking in their shoes is even better. By actually experiencing yourself the environment in which your product will be used, you’re able to use all your senses to answer questions, rather than just your brain.

You’ll be able to witness the kinds of struggles your end user is trying to overcome. You’ll get a sense of how your product fits into a larger world. You’ll see what it’s like to use the product and how people feel about it. You may even observe potential pitfalls and go back to the team to work out ways to head them off.

In short, you’ll gain tons of extra insight if you go out and try to experience your end users’ world for a bit.

3. Designing for Robots

When you’re thinking about the natural flow of things in an app environment, you naturally apply some basic rules of logic. For example, take a look at a seemingly plausible set of expectations around a common app feature, the ‘notification’:

Something in the system needs attention  → the app sends an alert to the user about it → the user responds promptly to the alert  → problem solved

The problem is, the step which calls for a prompt response from the user is based on an assumption that is often flawed. That assumption is that humans always behave logically and in ways that produce optimal results. That simple logic tree is flawed because it’s really created for an end user who is a robot, not a human.

Typically, when there’s a breakdown in a system like the one described above, it’s called ‘human error’. As designers of the 21st century who truly care about UX, there should be no such phrase. We should not be designing products that require users to act logically 100 percent of the time… in other words, like robots.

As product engineers and designers, we should be helping users climb out of situations where human error can be a factor. We should be helping them at every junction to interface with our products to achieve their goals. If lots of ‘human error’ is causing a product to fail, the team needs to re-examine their thinking and go through a few more iterations to get it right.

4. Failing to Give Weight to the Discovery Process

Very often, companies come to us with a list of problems they want us to solve. If we set to work right away on solving those problems, we’d be making a huge mistake. Why? Because we’d be skipping over the step that gives us what we need to build the right product and to build it properly.

That step is called the Discovery Process, one we’ve talked about many times here on the Making Sense blog. It’s where we talk to the company, get to know their business and their industry. It’s where we come to truly understand their pain points. It’s where we dig deeper than the list of symptomatic issues they brought to us and where we ask “why?”. It’s where we discover the root of all those symptoms.

In other words, the Discovery Phase is where we make sure we’re solving the right problems and where we try to get to know what’s causing those problems, so we can then be able to reach the right solutions. It’s the lynchpin of our entire process here at Making Sense, and we couldn’t do what we do without it. It’s why we’re ending with this point. If you remember anything from reading this, we hope it’s how important it is to incorporate a Discovery Process into your business routine as well.


If you and your team, if you have one, can avoid the four pitfalls we’ve just outlined, you are doing very well for yourselves. Believe it or not, each trap we’ve warned you about is taken from advice that was around thirty years ago. Nothing that much has changed about designing products for people. The technology sure has changed, but the people haven’t!