In a few rare instances, we find that it is acceptable to override the standard UI components provided natively by browsers and instead implement custom UI components.
During our usability tests, we generally find the default native UI components to be very user-friendly. Meanwhile, custom designed UI components tend to be a lot more hit and miss. In fact, our testing often finds custom UI components to be poor for usability. In the worst cases, we have found them to be outright harmful to the user experience and be the direct cause for site abandonments. Luckily, there is a brighter side to the world of custom UI components too.
In a few instances, our usability tests have shown custom UI components to actually provide the test subjects with an experience superior to that of the equivalent native UI component. This is achieved when the custom UI component affords the user with a superior presentational and interactive experience.
In this article it’s these darker and brighter sides of custom UI components that we’ll explore, looking at when to rely on the standard native UI components (answer: most of the time) and under what circumstances custom UI implementations can be better.
We’re generally very big proponents of relying on the default native UI components. They tend to be virtually bug-free and users intuitively know how to use them because they can recognize the component from the thousands of other websites and applications where they (also) appear.
However, native UI components do come with certain limitations – their data presentation and interactive behavior is often highly restrictive with little room for customization. This can be particularly problematic if a set of options would benefit from a richer data presentation, such as basic text formatting and assistive visuals, or when certain interactions could be optimized to improve form completion times and create a smoother form entry flow.
The exact implementation of the native UI components can differ across operating systems and browsers. For the most part these differences tend to be aesthetic but there are a few UI components where there are tangible deviations in regards to data presentation or interactive behavior.
For example, drop-downs have both design and interaction differences across different operating systems. A drop-down in Firefox will confine a long list of options to an overlay box with an inline scrollbar, while in Safari that same drop-down will be displayed as a long list which extends all the way to the bottom of the screen and has arrows that the user can hover to move the options up/down.
Such differences aren’t necessarily crucial or problematic. Indeed, our testing finds that users are capable of using both, although they naturally have an easier time using the implementation of their preferred OS-browser combination.
Hence despite minor implementation differences across platforms, the reason for pursuing a custom UI component is almost never because it has a poor default design. So when should you implement a custom UI component?
Throughout our usability tests, custom UI components worked better than their native counterparts when they provided a superior presentational or interactive experience. In other words, when significant interaction or data presentation benefits can be realized, a custom UI component may be considered.
The drop-down component is an interesting case because both its presentational and its interactive features may be improved upon for certain types of tasks.
Let’s take a look at data presentation first. The native drop-down component allows close to zero customization of the select options – it’s basically a list of text labels. For many types of data this is perfectly fine. For instance a ‘Quantity’ or ‘Size’ drop-down can convey its options just fine within these limitations, as the options can easily be understood from a simple text label.
However, there are certain types of data where a “richer” presentation of the available options will make it easier for the user to understand, compare and select between those options. The two most common types are:
A custom UI component allows for inclusion of visual aids and more complex layouts. Hence if significant presentational improvements can be made, and it’s important for the user to understand and compare the available options, a custom UI component may be warranted.
Other times what can be improved upon is an even more fundamental aspect of the UI component: its interactive features.
A good example of this is the “country selector”, which on most sites is implemented as a drop-down. However, during testing we consistently observe usability issues with these massive country selector drop-downs (also confirming Jakob Nielsen’s findings dating back to 2000 and 2007).
One solution to this is turning the drop-down into an autocomplete field (on capable devices and platforms), which provide the user with a superior interactive experience. Instead of having to scroll 200+ country options in a tiny drop-down pop-over window, the user simply types the first couple of letters of their country and it shows up. In fact, we wrote an entire article on this topic at Smashing Magazine a few years ago and even developed a plugin that progressively enhance drop-downs into autocomplete fields.
For the purposes of this article, the key takeaway is that there are cases where a custom UI component can provide an enhanced interactive experience for the user. If those interaction improvements are sufficiently tangible, a custom UI component may be warranted.
Unfortunately, there isn’t a single clear-cut answer to what constitutes “significant” presentational or interaction improvements. Most of the time a native drop-down is absolutely the right way to go.
Yet sometimes, a well-tested custom UI component will be a better solution because it enables interactive or presentational enhancements that are so significant that they outweigh the benefits of a native UI component (recognizability to users + bug-free implementation + no development or maintenance costs).
It’s ultimately a judgement call. Designers must use their discretion to evaluate whether to stick with the native component or “go custom”.
The two main benefits of native UI components are recognizability and reliability (virtually bug-free implementations that are kind to screen readers). When implementing a custom UI component these two aspects often require a concerted effort to even be approximated. But they can be approximated, and consequently they should.
It is absolutely possible to implement a close to bug-free UI component – it just requires adoption of “best practice” development techniques and serious investments in thorough testing up-front as well as budgeting for ongoing maintenance.
We cannot tell the number of times we’ve seen custom UI components break during testing – even on e-commerce sites in the billion dollar range. Testing is crucial. (And we haven’t even touched on the topic of accessibility.)
The recommended approach for custom UI implementations is to actually rely on native UI components and then progressively enhance them with custom design and behavior as this promotes both accessibility and reliability. When the underlying component is native, it will still be accessible to screen readers et al, and if for some reason something breaks on the page (e.g. a script fails) the site will still be perfectly usable – it just won’t provide that particular user with the custom enhanced experience.
(For more on how widespread e-commerce bugs are, and three principles to minimize their occurrence, see our article Fixing Bugs – the Next ‘Big Thing’ in E-Commerce?.)
From a usability perspective the main benefit of native UI components is that the user can recognize them from the thousands of other sites and applications they’ve used throughout their digital lifetime. This means users intuitively know how the component works and how to approach it.
It’s therefore recommended to emulate the standard UI components to achieve some level of recognizability. When a site imitates a standard UI component, we find that most users will (tentatively) assume the behavior of the original component to also apply for the custom UI component – unless those expectations are broken, of course.
Emulating native UI components can therefore be a great way to tap into user expectations while still achieving the potential presentational or interaction benefits of a custom UI component.
The litmus test goes: Will the interaction or presentational benefits of a custom UI component offset its implementation and maintenance costs and outweigh the reduction in recognizability?
If the answer is yes, then implementing a custom UI component is appropriate – under the premise that it is implemented flawlessly, fails gracefully and lives up to accessibility standards. We do advise pessimism when making this judgement call.
If in doubt, go with the native UI component. It’s only when the benefits of a custom UI component are overtly obvious that it should win out.
Join 22,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
The country dropdown would be great in an input with a ‘list’ attribute… http://html5doctor.com/html5-forms-introduction-and-new-attributes/
though unfortunately not implemented in Safari or Android browsers, the ones who’d benefit most.
Thanks for the tip Stomme poes, that’s definitely worth considering although the lack of support for synonyms might be an issue in some use-cases. For instance, we’re based in Denmark, which in english is written, well, ‘Denmark’, but in danish it is spelled ‘Danmark’. Hence if the datalist defines it in the local tongue but the user begins spelling it in english (or vice versa), as soon as they had typed the second character ‘de’ the relevant autocomplete result would disappear. On the upside, you get a rock-solid implementation for free that is super accessibility-friendly to boot! That’s pretty neat. And both solutions are definitely better than a plain select field :)
Good guidance. Unfortunately most clients want to native elements due to presentational concerns and not interaction, and that is not alone a good reason.
I will say it would’ve helped to mention the accessibility pitfalls of rolling with your own implementations and how WAI-ARIA can address those.
Exactly. We see native UI components being replaced by custom implementations for aesthetic reasons which is nearly always a bad idea. At the very least a native UI component should provide the basis for the interaction with a custom design superimposed on top of it – for instance, a select-tag / native drop-down may have a custom UI design placed on top of its default state while still relying on the native UI when the user opens the element.
And yes, WAI-ARIA is definitely important when rolling your own custom UI component if the native UI component isn’t progressively enhanced / is removed from the DOM.
Good article. When developing custom controls, it is imperative to have a very strong interaction designer to prototype, test and spec out a solid ui solution.
© 2021 Baymard Institute US: +1 (415) 315-9567 EU: +45 3696 9567 email@example.com