Simpler Is Better — Smashing Magazine


You’ve seen them before. Confusing and frustrating design patterns that seem to be chasing you everywhere you go, from one website to another. Perhaps it’s a disabled submit button that never communicates what’s actually wrong, or tooltips that — once opened — cover the input field just when you need to correct a mistake. They are everywhere, and they are annoying, often tossing us from one dead-end to another, in something that seems like a well-orchestrated and poorly designed mousetrap.

User Frustrations in 2021
There are plenty of frustrating design patterns on the web today. In the new series of articles, we’ll tackle them one by one. (Large preview)

These patterns aren’t malicious nor evil. They don’t have much in common with deceptive cookie prompts or mysterious CAPTCHAs in disguise of fire hydrants and crosswalks. They aren’t designed with poor intentions or harm in mind either: nobody wakes up in the morning hoping to increase bounce rates or decrease conversion.

It’s just that over the years, some more-or-less random design decisions have become widely accepted and adopted, and hence they are repeated over and over again — often without being questioned or validated by data or usability testing. They’ve become established design patterns. And often quite poor ones. Showing up again and again and again among user complaints during testing.

In this new series of articles, let’s take a closer look at some of these frustrating design patterns and explore better alternatives, along with plenty of examples and questions to keep in mind when building or designing one. These insights are coming from user research and usability tests conducted by yours truly and colleagues in the community, and of course, they all will be referenced in each of the upcoming posts.

We’ll start with a humble and seemingly harmless pattern that we all had experienced at some point — the infamous birthday picker that too often happens to be inaccessible, slow and cumbersome to use.
We’ve written about perfect date and time pickers in much detail already, but birthday pickers deserve a separate conversation.

Every time you apply for a job application, open a bank account or book a flight, you probably will have to type in your date of birth. Obviously, the input is a date, and so it shouldn’t be very surprising to see interfaces using a well-adopted date-picker-calendar-alike widget (native or custom), or a drop-down to ask for that specific input.

We can probably spot the reasons why these options are often preferred. From the technical standpoint, we want to ensure that the input is correct, and catch errors early. Our validation has to be bulletproof enough to validate the input, provide a clear error message and explain what exactly the customer needs to do to fix it. We just don’t have all these issues with a dropdown or a calendar widget. Plus, we can easily prevent any locale or formatting differences by providing only the options that would fit the bill.

It might seem that the best way to prevent mistakes from happening is to design a UI in a way that mistakes will be difficult to do. That could mean being strict and explicit in form design — basically allowing only for well-formed input. After all, providing an ill-formed input is impossible if all available choices are well-formed. But while the input indeed will be well-formed, it doesn’t have to be accurate, especially if providing that input is tiring and frustrating.

In practice, we actually make similar mistakes with over-complicated and rigorous password requirements, too. It’s not uncommon to see people get so annoyed by these requirements that they put passwords on a sticky note on their screen, or hide them in a personal.txt file on their desktop, just to be able to re-type them if needed. Corporate Wi-Fi passwords and a complex SuperPIN for online banking are good examples of that in action.

It turns out that people are very creative at bending the rules in their favor, so when a system isn’t usable, it’s not secure; and when a form input isn’t usable, the data we receive is going to be less accurate and lead to more errors. Ultimately, it of course would lead to situations when users are locked out and are forced to abandon the UI as they can’t make any progress.

There is a flip side to that coin as well. We could of course eliminate all complexity and always provide a single input field, allowing users to type whatever they prefer. In practice that means that they actually will type whatever they prefer, often in a poorly structured and inefficient way.

In the case of a birthday input, in usability tests, customers type in anything from July to Jul to 06 to 6, often with random delimeters and a few typos along the way, and with a mixed order of days, months and years. Validating that input after submit doesn’t serve users well because they don’t know what input formatting would work. Obviously it doesn’t serve our needs well either.

With our design, we need to provide a respectful, straightforward guidance, along with an accessible technical implementation. This brings us to some common downsides of native date pickers and dropdowns.

The Pitfalls of Native Date Pickers and Dropdowns

Unfortunately, native date pickers, prompted by , come along with plenty of accessibility nightmares. At the moment of writing, when used out-of-the-box, they aren’t a very accessible choice for pretty much any kind of date input. Not only are there plenty of screen reader issues, but also focus and layout issues, confusing and generic error messages.

I’ve seen a good number of implementations disabling keyboard input altogether (see above), requiring customers to use native date picker’s calendar widget exclusively. And this is painfully, painfully slow. Without a keyboard input fallback, users have to embark on a long-winded journey between days, months and years, taking up dozens and dozens of taps or clicks.

While we know the date immediately, the interface prompts us to navigate between dates, and then find our date in the monthly overview once we get there. That’s the reason why these experiences are frustrating.

Chrome’s native calendar view. This can be shown only for mouse users. Invalid dates are differentiated are not selectable. (Image source)

In that light, drop-downs are much faster and easier to navigate. They are accessible by default, plus rather than navigating between months and years, it’s enough to locate the right numbers in 3 lists — days, months and years. But drop-downs are still slow. They have zooming issues. Pinching scrollable options is tiring. They take up a lot of space. The list of years is long. And when specifying the input, we need to tap the control, then scroll (usually more than once), find and select the target, and continue to the next dropdown. It’s not exhilarating either.

birthday picker showing 6 February 2019
The iOS calendar reels are shown after tapping onto the date control. (Image source)

So it’s not uncommon to see dropdowns considered the UI of last resort, and usually replaced with buttons (e.g. for filters), toggles, segmented controls, or autocomplete boxes that combine the flexibility of a text box with the assurance of a