UI vs UX: 4 frustrating components on your website

UX and UI are two terms we’re not used to hearing in contrast with each other. Yet some UI components, no matter how polished or widely used, can actually worsen the user’s overall experience.

In this article, we focus on four components that are commonly used but hide potential pitfalls, and how to improve their usage. Our perspective is that of a developer, but first and foremost, we try to adopt the user’s point of view. Are you also using these components on your website?

Time pickers and calendars: how to complicate a simple task

Have you ever had to select a date from a calendar, maybe your birth date, and found yourself scrolling back and back through months until you reached the right day? It’s frustrating, and scrolling through years has the uncanny power to make anyone feel older than they really are.

Even worse is when selecting a time involves an iOS-style time picker. It’s a beautiful component on mobile, but unnecessarily complex on the web. As if working with dates in JavaScript weren’t already complicated enough!

So why do we insist on using these components? The truth is that they are aesthetically pleasing and familiar. Users don’t have to wonder how to use a calendar or a time wheel, because they’ve seen and used them many times before on other platforms.

However, familiarity alone doesn’t fully justify their use. Let’s see how we can improve user experience without sacrificing visual appeal.

Let users choose how to spend their time

Whether selecting a date or a time, one obvious solution is to use a simple text input. This is the approach Google uses in its account management interface.

There are, however, two objections:

• First, aesthetically, this solution is less attractive than a visual picker.
• Second, it forces users to use the keyboard, which can be inconvenient, especially if they weren’t already typing and must switch from mouse to keyboard just for this interaction.

A solution we in Mabiloft believe is often more appropriate is to offer both options. This means pairing the traditional calendar or time picker with an editable text field, ideally with a placeholder indicating the expected format.

This approach is also recommended by the U.S. Web Design System, the official design system of the United States government, and aligns with WCAG accessibility guidelines.

Do we really need sliders?

Another tricky area is numeric input. A plain text field may seem outdated and unclear at first glance.

HTML’s default number input looks almost identical to a regular text field, which can make its purpose less obvious. To address this, more creative and visually appealing solutions have emerged, such as number fields with increment/decrement buttons or sliders.

So why include them in this article? Because too often they become the only way to enter a value, instead of simply assisting the user.

How to use sliders properly

Sliders become problematic when they are not paired with an editable text input. This is especially true when dealing with precise or decimal values.

Sliders also present accessibility challenges. They often require precise movements, may not work well across different input methods like keyboards, and their focus states and handles are frequently overlooked.

Additionally, sliders require predefined minimum and maximum values in order to calculate movement increments. This assumption does not always fit real-world scenarios.

So why do we still use sliders? There are at least five good reasons:

• They are visually appealing.
• They provide a sense of scale within a range.
• They allow quick navigation across large ranges.
• They are familiar, especially on mobile devices.
• They work perfectly when the number doesn't count, such as adjusting volume.

To make them truly functional, sliders should always be accompanied by an editable input field, allowing users to refine values quickly and accurately.

When to use number fields

A number field is a text input combined with increment and decrement buttons. This component is especially useful when there is no limit on the number that can be entered.

A common mistake is removing the editable text portion and only showing buttons. This reduces usability, especially when users need to enter values far from the default.

Number fields are often the ideal solution because they combine accessibility, usability, and aesthetics. Unlike sliders, they do not inherently require strict value limits, but can support them when needed, for example by disabling buttons at boundary values.

Better alternatives to hamburger menus

This is a sensitive topic. Even our own website uses a hamburger menu. Why mention it then? Because we learn from mistakes, and because we still believe it’s a clean component that maximizes space for content.

So what’s the problem? Hamburger menus require additional clicks for navigation. Users must open the menu before they can access anything.

Worse, users cannot immediately see all available options. Even though the pattern is familiar, it subtly slows navigation and increases cognitive effort.

This issue is especially relevant for platforms where efficiency is critical. On showcase websites, especially those with minimalist design, hiding navigation may be acceptable in favor of visual presentation. (Are we trying to justify ourselves? Maybe!)

How to replace hamburger menus while saving space

The best alternative, when possible, is a visible navigation bar at the top or side of the page. But what if there are too many items?

One solution is using icons, which take less space and allow more options to be visible at once. Wherever the screen could host four of five extended names, with icons at least the double can fit on screen.

However, icons have limitations:

• Abstract concepts can be difficult to represent visually with a meaningful icon, leaving the user to guess what's the meaning of each one.
• Too many icons can become confusing and visually overwhelming.

Another widely used solution is grouping items into categories, displayed on hover or interaction. This approach, used by sites like IKEA, allows complex navigation without overwhelming the interface.

A controversial opinion: should we abolish infinite scroll?

Let’s end with a bold statement: infinite scroll is not always better than pagination. Let's clarify. Infinite scroll allows users to continuously scroll while content loads progressively, usually with virtualization of content not shown on screen. An example can be found in this page.

It creates a fluid and modern experience. However, it also introduces usability issues.

Finding previously seen items becomes difficult because there are no clear reference points. Users may have to scroll extensively to locate something again.

Additionally, restoring scroll position after a page reload is not always straightforward, making it harder for users to resume where they left off. This is technically solvable, but still often poorly implemented.

This doesn’t mean infinite scroll should be avoided entirely. Instead, it should be used thoughtfully. Ask yourself: will users need to find items again, apply filters or share links to specifical result pages? If yes, pagination is the best choice.

This concludes our overview of commonly used components that can harm user experience when misused. There are many more examples that we could bring, such as excessive use of modals, or that we brought already, such as tooltip usability issues, which we’ve discussed elsewhere.

Is your website truly optimized for UX, not just UI? Want to discover how to improve your digital product? Contact us to explore how we can help.