3 Timeless UI Debates: A Practical Guide

The work of designers is often underestimated. When an interface works well, users move through it effortlessly, without realizing how many tricky decisions the designer had to face to arrive at the final result.

Only those who work hands-on with platforms every day truly understand the complexity behind them. Sometimes it comes down to microinteractions, but these can require hours of thought and, quite often, discussions even among members of the same team.

With this article, we want to untangle part of that knot. While these topics are ultimately a matter of convention, we aim to provide concrete reasoning behind our choices.

Tooltips: the silent enemy of usability

What’s controversial about tooltips? After all, they are components we all know and use daily, present in the vast majority of web platforms.

And yet, behind a seemingly simple tooltip, there is often a real usability issue:

• If users are not aware that a tooltip exists and do not accidentally hover over the element that triggers it, the information remains invisible and therefore useless.
• Tooltips are often not visible on focus, preventing their use by users who navigate via keyboard. Even widely adopted libraries such as MUI, unless developers take additional steps like providing the tooltip with a clickable child element (for example, IconButton, as shown in the documentation), do not automatically ensure it appears on focus.

Another issue is that tooltips can encourage laziness. “Is this section of the platform not perfectly clear? Okay, let’s add a tooltip to explain it better!” This line of thinking, which we hope belongs only to a few designers and only in moments of time pressure, is flawed and does not solve the real problem: a platform that is unclear to users.

When (and how) to use tooltips

But do we really need tooltips? In some cases, the answer is probably yes. There are situations where the functionality offered to users is complex and even a well-designed UI is not enough to explain how to use it. Or cases where creating a full tutorial would be excessive and would interrupt the user’s flow.

In these scenarios, the solution comes down to a few key principles:

• Make sure tooltips are usable via keyboard. When building a platform, we must be aware that users may have different habits or accessibility needs. It’s our responsibility to account for all of them.
• Improve tooltip visibility. This can be done by attaching them to inherently interactive elements, such as buttons, or by using conventional symbols, like a question mark placed near the relevant feature.

When to avoid tooltips

The answer to the previous question is not always yes. Sometimes, tooltips are simply unnecessary. As a general rule, if the information can be conveyed through elements that are always visible on screen, that option should be preferred.

A common example of tooltip usage is explaining password requirements, such as minimum length, the need for a lowercase letter, or at least one number.

In this case, the best solution is to provide users with the information they need without hiding it. This can be done with a bullet list below the input field or, if space constraints motivated the use of a tooltip, by placing a short explanatory text beneath the input, in the area usually reserved for error messages, until an error actually appears.

Show password: open eye or closed eye?

Every conscientious developer has asked this question at least once: if the password is hidden, should the button to make it visible show an open eye or a closed one?

It’s a subtle detail, but no clear, universally accepted guideline seems to exist. So let’s reason through which solution makes the most sense.

The component makes the difference

There’s no doubt that the eye icon (or text label, for those who prefer it) is a button. Why does that matter? Because buttons typically describe the action that will be performed when clicked, which would suggest showing an open eye.

But there’s a catch. Due to its function, this button closely resembles a switch. And with switches, we usually expect to see the current state. Think of how Apple indicates Airplane Mode: blue for “on,” gray for “off.” These are clear indicators of state.

So should we treat it as a button or as a switch? The answer is: it depends. On one hand, the average user has no knowledge of the underlying code. For them, anything that behaves like a toggle is effectively a toggle. This would argue in favor of showing a closed eye when the password is visible and an open eye when it’s hidden.

On the other hand, sometimes the element is clearly a button, especially when it has a background. And if, instead of an icon, we used text, we would have no hesitation in writing “Show” to reveal the password and “Hide” to obscure it.

Which icon should be used to hide the password?

In our opinion, the deciding factor is YouTube. The password eye icon has a lot in common with the “play” button: it’s almost always an icon-only button and it also toggles between two states.

YouTube, as well as Spotify and other media apps, displays the “play” icon when content is not playing and switches to a “pause” icon while playback is active. Applying the same logic here leads to using a closed eye when the password is visible, and an open eye when it’s hidden.

That said, if you’ve always done the opposite, don’t worry. Regardless of the choice, users will understand what action will be triggered when clicking the eye icon. What truly matters is maintaining consistency across your product.

And if none of this convinces you and you’re still unsure, you can always follow Google’s path of neutrality and use a clear checkbox labeled “Show password” below the input field.

Skeleton or spinner: that is the question

Waiting is frustrating for users, and studies show that load times longer than three seconds are associated with high abandonment rates: up to 53% on mobile. Managing loading states properly is therefore crucial to retaining users.

The final debate we want to address is the choice between skeletons and spinners, two of the most common loading patterns. Let’s be clear from the start: this is not a case where one emerges as the definitive winner.

Both skeletons and spinners have their place, each with strengths and weaknesses. This is precisely why there are scenarios where one is more appropriate than the other.

Skeletons: a refined loading experience

Skeletons are an elegant and refined way to handle loading states. With their neutral color palette, typically shades of gray, and their subtle animation, they give users a preview of the content that will appear on the page. Because they create the impression that content is already present, they help retain users.

This is their main strength: they prepare users for what they are about to see, minimizing layout shifts once the content finally loads.

Skeletons are especially suitable for:

• Longer load times involving large sections
• Text-heavy content with long, narrow shapes
• Sections with distinctive layouts, such as activity blocks inside a calendar
  

On the downside, skeletons require knowledge of the final layout in advance. This is not always possible, for example when loading data that determines whether a user is an admin, resulting in significantly different page content.

From a developer’s perspective, creating skeletons for an entire page also requires considerably more effort than adding a simple spinner. The cost-benefit ratio must therefore be considered. Even so, skeletons remain the preferred choice whenever they can be implemented properly.

Spinners: a no-frills loading indicator

Spinners are the universal symbol of loading. A rotating indicator is immediately recognizable and quick to implement. Spinners are therefore the best choice when dealing with:

• Single sections whose shape cannot be anticipated before data is loaded
• Buttons that trigger time-consuming actions, where a spinner can replace or accompany the button label without affecting the rest of the page
• “Dense” sections, such as embedded videos, where skeletons could be confusing

That said, when used for large sections, spinners leave too much empty space, quickly leading to boredom and frustration during longer waits.

In such cases, alternative solutions may work better, such as loading animations or progress bars, especially when skeletons are not feasible and spinners are insufficient.

Did you enjoy this article? Keep following our blog for new posts every week. And if there are other UI topics you’d like us to cover, or if you simply want to share your thoughts on these debates, write to us here: