Any product or app interacts with users through its features. 

A feature can either make or break a product. Imagine if Instagram had not made uploading and editing a photo as simple and joyous as it is today. Would Instagram be as popular as it is today?

There are several ways to design a particular feature. While on the surface designing some features might appear quite simple, the reality is that designing any feature is quite a complex problem, with many moving parts, complex trade-offs, and elements of making subjective design decisions.

For the sake of this article, I am assuming that designing a feature starts only after the broader decisions about your application are made, for example, you have decided whether it’s going to be a web application or a mobile application, whether it’s going to be an email-based client or an SMS-based client.

In this article, we’ll go over some of the mistakes people make when designing features and how to avoid them.

Mistake 1: Not standing in the user’s shoes

The number one mistake people make when designing a feature is jumping to a conclusion as to how the feature should be. Probably because it’s much easier said than done. Product Managers think, ok, this is the problem and we know the solution, so our work here is almost done.  

In reality, the work has just begun.

They have not yet looked at the problem from the user’s perspective!

How to avoid it:

Once you understand the problem and arrive at a solution, you need to place yourself in the user’s shoes and deeply understand where the user is in their journey of solving the problem, who that person is, what is the exact reason that this problem is troubling the user, what the user would prefer, what the problem makes the user feel, how is his/her experience, what their current situation is…

In short, you do a deep dive into the user’s psyche.

Next, you try to frame the user’s problem, paying close attention to how the user is framing the problem. (Does it match how you were framing the problem?)

How do you do all this? Well, a well-thought-out user interview should do it.

Let’s take an example.

Let’s say you are developing an app for a cab service. The feature you are working on is the SOS feature on the app, that allows a user to alert the police in case of an emergency.

Seems pretty simple?

If we just think of the problem and the solution required, we might just add a big red call button that says SOS on it (and be happy that the work is done).

But is the work really done?

Step inside a user’s shoes and all of a sudden, you see a plethora of doubts popping up. Wait, what if she prefers dropping a text than calling, as she wouldn’t want the driver to know (let’s assume it’s the driver she feels in danger of)? 

What if she knows a friend who stays in the area and she wishes she had shared her location earlier (now that she’s hesitating)?

Just imagine if you realized this AFTER that feature was designed! And you can only guess the repercussions if such a feature is not designed as per the user.

While all this might seem like a lot of work for one feature, what many people don’t realize is that there is a possibility for them to be extremely creative while designing such features. 

And this is where the personality of an app shines through. 

Mistake 2: Not exploring enough options

Once a developer has all the necessary information from the user and a good grasp of who the user is, what exactly he/she wants, and how exactly they want it, it might seem that it’s just a matter of connecting the dots.

But when you’ve put in all the hard work, why not some more?

There can be a hundred ‘right’ ways of solving the user’s problem. Often, the quickest and easiest way is chosen before really analyzing the pros and cons of the solutions at hand.

‘Why this, why not that?’ is hardly a topic of discussion in most cases. But it needs to be.

Not exploring all the options is another pitfall many people make while designing a feature.

How to avoid it:

All the available options at hand need to be laid out clearly, preferably with a SWOT analysis of sorts to logically come up with the solution you want to go for. 

There are several options in the previous feature that the feature design should consider thoroughly before making a decision. For example, 

Who to send SOS to?	Mode of initiating SOS	UI Design Choices
A1. Closest police station	B1. Text message	C2. Voice command to the app
A2. Friends & Loved Ones	B2. Voice message	C2. Voice command to app
A3. App Volunteers	B3. Video message	C3.

You can see from above how the combinations can become quite complex very quickly.

To oversimplify things, let’s take a UI challenge. Let’s say you have decided that the emergency call button on the cab service app will be a big red button inside the app. 

But is that the best placement possible? Is red the best color for the button? Is the size too big? Or too small, perhaps?

We need to consider, ponder about, and deep dive into the tiniest of details to make the right choice. As they say, the devil is in the details.

Only when such extensive thought has been put into the solution should the actual design begin.  

Mistake 3: Skipping user testing

Let’s say an app developer has really understood the user’s problem statement well and designed the feature. The developer is pleased with the outcome and believes it satisfies all the user’s needs. 

But what if there were gaps in his understanding? What if he missed a seemingly insignificant comment the user had made, but it turns out it was actually rather important?

How to avoid it:

Once you have built the feature, it’s vital that the user confirms that it indeed serves the purpose to his or her satisfaction. Else, the deep, priceless knowledge gained from all the information from the users can go to waste.

Moreover, the user might come up with an entirely new problem with how the feature has been designed. It could be a minor tweak in the UI that can fix it, or it can be downright huge…you never know.

Taking the emergency button for the cab service as an example, what if the user, after testing your feature, realizes they had missed something completely? It could also be that your interview was not thorough enough.

To close these gaps, it is imperative that the users test the designed feature and give their feedback on that. It will only make the app a more foolproof and satisfactory product for the users.

Conclusion

Too often, when designing a feature, the solution and its execution appear simple. But there’s a reason why we have so many apps we aren’t happy with, and so many products that fall short of expectations. It’s because of one or more of the three mistakes discussed in this article. All good things take time and effort and if we follow the aforementioned steps, the quality of the products we build will always be high, they will always satisfy the customer, and they will always serve the purpose. And when you achieve that, when you check all the boxes, can you imagine the sense of satisfaction you will feel?