Dimitry Fadeyev at UsabilityPost defines False Simplicity this way: “Sometimes, what appears on the surface to be simple is actually far from it”. What is being referred to here is when a User Interface (or a UI element) is made visually simpler, but as a result becomes more complicated to use or understand.
False Simplicity is particularly worth paying attention to in the design and conceptualization phase because it often pass for being “simpler” at first glance, when in reality it actually makes the interface more complicated to use. Let’s take a look at 3 types of “False Simplicity” where you should stay alert.
One type of false simplicity arise when you simplify an interface in a way where the user end up losing context. Such loss of context can happen when you oversimplify or outright remove UI elements such as hierarchy indication (indentations, semantic markup, breadcrumbs etc.), navigation history (visited link state), labels, indication of selections, instructions and so on.
One specific example of losing context as a result of simplification is forms with labels inside the form fields. You find such an implementation during checkout at e-commerce sites such as RueLaLa (seen above), Apple and J&R.
Having the form field labels inside the form field itself makes for a very simple visual appearance of the form. The form fields however get very difficult to interact with because each field loses its context the second the user starts typing. This not only makes it more difficult to fill in the fields, it also makes it difficult to correct errors in the form since the labels are now missing.
When conducting our checkout usability study we observed that when users had to correct errors in forms with the field labels inside the field, they ended up deleting the entire input just to be able to read the label once again – after which they’d have to re-enter the same information once again with just a couple of characters changed. All form fields ultimately look alike, the only thing that separates two text fields is their context, and this context is mainly set by the field’s label, so when you remove the label as the customer starts typing, it becomes difficult to differentiate one form field from the other. (Update: These issues with inline labels were confirmed in our mobile e-commerce study as well – only, they are even more severe in a mobile context.)
It’s visually simpler but in the end more complicated to use.
Another type of false simplicity can arise when you simplify an interactive UI element to a degree where the user can no longer immediately understand what the element does. “Immediately understand” is of course a very loose description since what your specific user group can or cannot understand may vary greatly by previous browsing and computer experience, age, culture, language and so on. But in general the further you move away from a shape and style that follows traditional design and web conventions the more likely you are to end up with a case of False Simplicity due to a UI element that is ambiguous and too open to interpretation.
An example of such simplification could be the category navigation at SpringWise, a business trendspotting blog. The category navigation consists of a set of 21 icons located in the sidebar, each icon acting as a link to a category with a hover title. This icon deck looks super cool but the user has to hover every single one to know what each of them represents unless he can guess the meaning of the icons. E.g. is the travel/tourism category represented by the sun, suitcase or airplane icon? (What’s your guess?)
Icons can be great in an app or website that the user use on daily basis because the initial cost of adoption (due to ambiguity and non-convention) can be paid back in the long run. But when the interface is used less frequently (e.g. twice a month in the SpringWise example) the scenario changes – the cost of adoption increases greatly as the icons will be more difficult to remember when there’s weeks between each encounter, and between each possible return-on-investment.
Again: Visually simpler but ultimately more complicated to use.
(Side note: when using UI elements that rely on hover titles remember that there is no hover state on touch devices so you’ll need to provide an alternative for those users or they’ll have to do a lot of trial and error.)
It’s aggravating when a simple task is obstructed by an overly complex user interface. I believe much of the success for many business web apps seen these days are propelled by their ability to match simple everyday tasks with equally simple user interfaces. (Something most traditional business and enterprise software has a history of being notoriously poor at).
Another type of False Simplicity can however arise when the opposite is the case. When a rather complex task is given an interface that’s too simple. Simple tasks are best suited to be matched by a simple user interface. But sometimes to solve an advanced task an overly simple interface just doesn’t cut it. Sometimes the user needs the reassurance and confirmation of fine details (even if that means a bit of added complexity) to be able to solve the task at hand.
An example of such a case is found in OS X Lion when setting the security level for formatting the hard drive. In the recent OS upgrade it went from being a set of radio buttons (top image) to a slider (bottom image). The slider-based dialog only displays the description for the option currently selected. While this is certainly a neat way of removing a lot of descriptions, the user now has to slide between all steps just to figure out what his options are.
For certain everyday tasks this type of simplification might be a good thing - having a slider and removing clutter by only describing the selected option. But setting the security level for formatting your hard drive is hardly an everyday task. It’s something most users won’t do more than once a year (if ever). When it happens most users are likely to want to know a little more about their options and the differences between them in order to make an informed decision (in this case the security vs time spent tradeoff).
This is especially true because the user will have to click an “Options” button to even see these. So the options are already hidden and now the user has explicitly asked for the “Advanced” mode – surely he’s interested in seeing more information about the options. Simplifying an “advanced settings” screen this way creates a mismatch between the task at hand and the UI.
Once again: Visually simpler, but in the end more complicated to use.
The use case is often what tilts the scale from simplicity to false simplicity. E.g. removing text descriptions in favor of icons might be a good decision in an interface the user will use every day where the initial cost of adoption is paid back over time. But if it’s on a site only used rarely the cost of adoption increases greatly as the non-conventional simplification will be more difficult for the user to remember.
In general watch out for False Simplicity when the simplification might lead to: 1) a loss of context, 2) an ambiguous UI, and 3) a mismatch between UI and task complexity.
With false simplicity it’s worth noting that the interface doesn’t become “broken” and unusable, so don’t expect end users to alert you directly with lots of complaints or remarks. False simplicity instead often leads to extra work and friction for the user: having to delete the input to re-read the form field label (example 1), hover all the icons (#2), or slide back and forth to understand each option (#3).
The general strive for simplicity is great and the intention is good, but beware that sometimes visually simple can actually end up being more complicated to use.
Do you have other examples of False Simplicity? Then post them in a comment.
Join 24,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
I completely agree with the article. Although Apple tries to keep the labels in their registration form visible as long as possible with a really subtle degradation of the text when you first click the field once you have entered the text there is no way of knowing the original label.
Precisely, once you’ve entered text the label is gone.
Google Chrome handles placeholder text in the same way – when you first enter the field the label is still visible until you type the first character.
This article is incredibly interesting and well written.
I agree the most with your consideration.
A solution to the problem of form fields with label inside, could be a label who remain visible (inside) up to when the user start typing, becoming a tooltip while typing and after.
It is difficult to explain the way to managed this, but it is a thought that needs testing and investigation.
Hi Federico, it’s an interesting idea of having the labels inside become a “tooltip” next the the label as the user starts typing (and the label would have otherwise disappeared). If you do such an implementation please let me know, I would love to see it in action. One “danger” might be that the solutions ends up being overly complex compared to just displaying a form label above the field (the traditional way).
Hi Christian, you are right about the possible complexity of the solution.
I was just wondering about this possibility when in needs for the inside labels as (i.e.) in lightboxed login or similar for make the form compact
Usually I go following the traditional way, with the label above the field ;^>
I disagree on the third point. I would argue that most users don’t care about the details but the general trade-off (fast vs. secure). The top exampel is for people who have a general clue about formating and security, the latter is for apple users who only want a simple choice: fast or secure.
“(Side note: when using UI elements that rely on hover titles remember that there is no hover state on touch devices so you’ll need to provide an alternative for those users or they’ll have to do a lot of trial and error.)”
Well, that and keyboard users have never gotten title tooltips, because they also never hover. While I’m glad suddenly everyone’s paying attention because of fancy tablets and smart phones, this has been a usability issue for a very long time.
Though if the situation makes sense you could CSS the title tooltip if the elements are natively focusable, but in the example shown, this would still mean needing to tab through all the options just to know what the options are.
Tab through all the options? Not necessarily, as long as you ‘highlight’ the fields that need attention.
Really well thought through analysis. It’s amazing how such seemingly simple things can make our computers easy or difficult to use.
I like the observation about hover and how on touch this usability feature we’ve known for years isn’t there! Mobile first has become desktop second and we’re in danger of making it less usable in the name of simplicity.
Every designer should read and understand this, but most won’t.
Even this webpage fails a bit on desktop because the font size is so huge it looks bad; tablet and mobile browsers should compensate for desktop-size font (like 10-12px) by just increasing the default (to like 16-18px) automatically and giving the option to the user to adjust.
Even if that breaks formatting on mobile, the browser and/or developers can compensate for this with responsive and media screens. It’s a problem that probably isn’t that difficult, we haven’t reached the sweet spot yet, and would just take some coordination between website developers and computer developers.
Thanks for the blog. I can actually sit through more of these examples of what not to do. Hopefully, there is a Part 2 coming. Good stuff!
Try signing up for a new account at Target.com. The labels are inside the fields, but when you click into the field they animate up to become labels outside the field. That keeps the form sparse, solves for the disappearing label, and adds a delightful micro-interaction.
I think this quote is wildly true, especially in the UI/UX world. Often the most simplistic UX is the most complicated under the hood. Thank you for this.
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 firstname.lastname@example.org