3 UX mistakes you might be making when building your product

Let's talk about usability and 3 common mistakes you might be making when building that product.

Confusing 'Account Setup' with 'Onboarding': Your onboarding flow is meant to serve a primary purpose, which is to show the user why your product matters; lead users to their first 'Aha' moment. This is about discovering the value of your product and how it applies to them, more precisely, how it provides a solution to their pain point. We often think onboarding is for us (the product owners); to get the data we need for the product's functionality, but in reality, onboarding is for the user. Data collection for very critical functionalities is important but it should never replace the primary reason of why the onboarding flow exists in the first place. Every piece of information you ask for should try in making them see the value of your product. If asking for their 'Company Size' doesn't immediately change what they see on their dashboard, don't ask for it...yet. And in some cases, if done well, some parts of onboarding could also be used to collect critical setup data. But value must come before asking, helping your users understand the 'why' of your product would encourage them to provide their 'what'. In addition to this, the 'why' should also not be left out during data collection. Helping users understand why they need to provide their information also builds trust. Let’s look at a real-world example of a product that does this well.

Sample Product: Duolingo
The User's Pain Point: The intimidating feeling that learning a new language is too hard or will take years.
The "Aha!" Moment: Realizing they can translate a complete sentence in a foreign language in less than 60 seconds (this would excite any new learner)
How Duolingo shows value during onboarding: Instead of starting with even a "Create Account" screen or asking for your name and email, Duolingo drops you straight into the product:
- Choose Your Goal: The user immediately selects what they want to achieve (e.g., "Spanish for Travel").
- The Interactive Lesson: The user is immediately placed in a mini-lesson. They click buttons, hear audio, and solve puzzles. Some infornation gotten includes the "Technical Setup" introduced as a game.
- The "Aha!" Moment: After 5-10 screens, the user has earned their first win and realized that they can 'do it'.
- The Delayed Setup: Only after a user has finished the lesson and felt the win does Duolingo ask them to 'set up' - save progress by creating an account.

Now, imagine what this would have felt like if Duolingo started with a 10-field registration form and a "Verify Your Email" requirement, most users would lose interest before they ever learned a single word. The onboarding flow led with the solution and providing value (in this case it was learning) before earning the right to ask for the data (the account).

While this approach is harder to build (because you have to manage temporary "guest" states in your database or client side), the payoff in user conversion is almost always worth the engineering effort.
Feature Overloading: It's easy to feel like having a lot of features increases the value of a product, but this isn't so, because more features would mean higher cognitive load and more friction points for the user. With feature overload, users would have to use more mental energy to navigate the product interface than actually achieving their core goals. It specifically hurts the product by trigerring decision paralysis. They become overwhelmed and confused about 'what to click on', 'what to click first', etc. This isn't a coincidence but an actual phsychological principle, Hick's Law, which states that the more choices you present, the longer it takes for a user to make a decision. This in turn affects the product learning curve, making it a lot steeper because of feature clutter. It also further buries the main purpose of the app, the core value proposition that keeps them coming back. And if there are more chances for users to face friction points then there would also be high drop offs out of frustration. To fix this issue, it is important to ensure that the core functionalities of the the product are easy to access and priortised in the user flow. Patterns like progressive disclosure could be adopted to handle secondary features in sub-menus, internal pages, modals, accordions, etc where they would not be competing for the user's attention.

The design below shows menu and hamburger, an example of progressive disclosure. Design by Nicholas Ergenia
Skipping Usability Testing: Usability testing is commonly ignored and this shouldn't be so. Apart from the usual functional testing (which checks if the product works), you still need to test how usable your product is. Usability testing involves observing how real users interact with your product as they try to complete specific user tasks. It checks if the user can actually navigate and use the solution you’ve built. It shows where users get confused, where they hesitate, and where your assumptions about their behavior don't match reality. It also helps to validate the 'Aha' moment, whether it is reachable or if users are getting stuck on unnecessary friction points that you might not notice. The good thing about usability testing is that you can start small with about just 5 people, this usually leads to dicovering about 80% of usability issues. Skipping usability testing makes a large number of your users unknowingly test your app, but instead of reporting an issue as a bug, they totally stop using the product.