My "Never Do This" List
I am often told I’m too negative, but I think I am progressive. I am hopeful. I complain about the bad so we notice, and improve. Think of the point of autopsies or air crash investigations. They aren’t ghouls, or there to assign blame, but are there to find the root causes, and arrest people, add process improvements, manufacturing changes, regulations, to try to avoid them happening again.
And also, I am more positive than most people. Almost all widgets are fine when used properly. Dark patterns aren’t really evil widgets, but evil use of them; the big patterns book has a paragraph or two on anti-patterns at the end of each one, so you know how to avoid pitfalls and peril. Lots of people say to never use very common things like say the Hamburger Menu or Infinite Scroll. But these are fine, and often by far the best choice as long as used remotely properly. Bad implementations don’t make an item bad itself.
But there are a handful of Bad Things. Evil widgets that should be gathered up and buried in a circle of stones at midnight under a full moon. Yet, they persist:
Visual CAPTCHAs
Any of those that make you read some distorted letters, or do a math problem, or find all stop signs. These are anti-bot tools, they say. But they are wrong. They are anti-human tools. Seriously. The image matching tools are to train bots to be better at that task. The distorted text ones? Yes, machines can match those better than people, almost 10 years ago.
So they don’t work but they are accessibility nightmares at least. The accessible ones? Those make blind or low-vision users press a button to get an audio version. Just no.
Their very concept dismisses the human part of the system. CAPTCHA is an abbreviation that starts “completely automated” but of course, we have to put in a lot of effort to use these. That’s not automation.
I even see these on sign on pages! And generally, they are a lazy lack of a solution to problems solved other ways. I have literally never designed and implemented a visual CAPTCHA.
A few months after launching a rather successful product, the security team came to tell us to add a visual CAPTCHA. I said, nope, not doing that, so explain why you need it. Turned out there were evil eastern-European bots sending spam to our customers using this open tool. Within hours I had discovered they were sending thousands of messages a second. Which is faster than humans type. I put a stopwatch on a half dozen of my team members, picked a likely-fastest time, and we simply blocked new-message submission faster than that.
This worked. It ruined the financial model upon which the spambots worked, without the user being burdened, or even being made aware of it. It turns out it is one of several methods security professionals already know about to avoid these problems, and Visual CAPTCHA isn’t even on that list.
Clear Form
You are on a form, on a website or app. At the bottom of the page is Submit and Clear. Clear deletes all entries on the page. Why? I have been doing this a long long time, worked places with good research cadences, and great analytics. I have designed a huge number of products across a wide range of industries and uses cases. I have zero confirmed examples of anyone legitimately using a Clear Form button. Ever.
I worked in data entry for a couple summers back in college. I used some of the other functions from where it arose just fine. PF12 is Submit and Create Empty Form, very common when doing repeated entry from paper. Even there, I am almost entirely sure I never simply pressed Clear Form. Because why would I?
But if you include one, it’s not just useless, it’s dangerous. Clear Form is clicked plenty. By accident. Do not solve this some other way. Do not add an Are You Sure guard or anything. Just remove it. There is no need for Clear Form, ever.
Clear Field
I mean, same thing. Do I even need to explain this? It’s just Clear Form, but smaller. Same issues. Mostly people want to edit not delete, accidental usage is un-undoable so cause more problems than they solve.
And as a bonus for these, they are mostly unlabeled and maybe only appear on hover in the input itself so are very very easy to misinterpret or misunderstand and activate accidentally!
OK Dialogs
You are going along in your app or website, and something happens. An error appears, cryptically, in a dialog that just says “OK”.
You carry out an action, get a nice happy dialog, that says it worked. And to keep going, must get rid of the dialog. There’s a big “OK” button.
Error or success, clear or cryptic, even if the one button doesn’t say OK, if all you let people do is dismiss the dialog, why does this exist? Any time the system has one choice, don’t make users click that, but do it for them.
“Are you sure?” Guards
First we need to define terms because no one does that anymore. A guard is a system to prevent the user from performing a dangerous or unrecoverable (or difficult to recover from) action. Physical guards are common, like guard rails, or covers on dangerous switches, or over spinning saw blades. In industrial settings these are mostly easily removed, to perform service, to use the rare action like shut down the machine for an emergency.
The typical guard on a website or app is: useless. Well, most are counter-productive. They keep you from doing something that isn’t that consequential, or dangerous, so are just annoying.
But the form of the typical guard is the dialog saying “Are you sure” then OK or Cancel. Even with slight wording changes, they are hard to read, ambiguous (often you have a guard for cancelling an action with “Cancel” as the button to NOT cancel the action… it’s awful). But most of all, even when well designed, well explained, good button labels, maybe even icons:
They don’t work.
At all.
Why? Because of the proliferation of dialogs like the OK above or too many guards on everything else. Maybe they see this exact one every day, and usually they mean it so agree. Then one day they press the dangerous button by accident and still default to just going “yeah yeah” and agrees, which makes it not a useful guard.
There’s also some other cognitive mode stuff going on as even users who you make read it (for example in a test session, they have to read aloud) do not internalize the choice and fall into completion bias. Their brain is in a mode of task-completion, assuming they made the right choice already, so questions to that choice are wrong.
But people do often review choices afterwards. Undo, or the concept of the computer desktop trashcan, all work because that’s how people work. They make a choice… Oh no! Then they want to correct it.
So instead, give them an undo method. For guards you mostly invert the model. Let them do it then give them an out. Of course you may say “undo is impossible” and it often is unless you lie to the user. Gmail has a good one of these. You can, for a few seconds, undo or revoke sending an email. How? The undo is just a timer. It doesn’t send until after that time. Easy! You can do that. You can even set up systems like this as guard dialogs that just have a timer and lean to the “no, not that!” recovery button.
Unlike the other two, this isn’t always one you just delete but which you solve in another way. Action-free items should usually get a passive notice. A banner or simple inline status in the relevant spot. The rare times you get a fatal error, that should be an interstitial (a full page that interrupts) and the action should still not be OK but one that fixes the problem, even if it is to exit the app and start over.
“Home” Pages
Websites generally are organized with a home, landing page, portal, or dashboard at the center of everything. The traditional way we’ve decided over the decades to label this is a little house icon. However, this is a common practice that is often a worst practice. Unlike others here it won’t destroy your company or anything, but it’s on my list. It is something I never do anymore, ever, for anyone.
First off, there are often multiple “home pages.” Every project likes to make their first page labeled “Home.” My credit card rewards site literally has a home which is not the home of the credit card company, account management or anything else.
For many sites, or apps, the home page is also unimportant; search, or intents, or other linking means nearly all visitors come in to other than the home page. Real data I have seen from many clients has around 1/10th of 1% of visitors arriving at the home page. So the promise of it as the home is not fulfilled anyway.
The best thing is, however, that a huge number of products and services intersect your home life. As in, things that happen in your “home” vs your business, your vehicle, vs out and about in the world. Let’s say you have a home improvement store and offer a repository of info about your purchases in order
Or, you make electrical power systems, like generators and switches and solar. For industrial, backup power, utilities, and also… home backups.
Or you are a hospital network, and among other things provide discharge instructions, or what they call “Home care instructions.” There are things that happen in your house, as opposed to the hospital or clinic.
All these that confuse the information-architecture digital home with the physical home are confusing, in bad ways.
What to call it? Well there’s no one answer. Here’s two of my more typical answers:
Nothing. If it’s not that important, have it but don’t include in navigation at all. Let it exist, and the whole click-on-logo but… be careful about all those microsites! If clicking the logo goes different places for different sites, that’s bad.
Decide what home is, and name it. While you are at it, maybe name subordinate pages also so there’s a system. One I did recently had a Dashboard with individual Hub pages. Calling them that worked well in this case.
Customization
I mean the thing where you have a menu, or a portal, and you let the user push things around to their preference. Often, you do this as a way to give up on IA design; no card sort needed, let the user customize. Wrong. Never works. Ever. I cannot emphasize this enough:
It never works.
So few people customize that it’s statistically zero. If you had a system with errors as rare as customizing users, you’d be delighted. And I don’t just mean the everyday website where of course no one customizes their account they mostly visit once a year, and the really involved users visit monthly for bill pay. I mean things like legal secretaries who spend all day in MS Word, are very very very detail focused, do specific tasks with specific required formatting, are well paid and professional and THEY essentially never customize.
This sort of stuff is where the Microsoft Ribbon came from. They saw that despite claims everyone wants to customize — and since then, complaints about the Ribbon are always that we can just customize and get the same effect, even! — that’s a lie. This is the poster child for:
What people say they do, and what they do, are two different things.
Everyone in bad research, like focus groups, will tell you they want customization. It’s very aspirational. But it never happens, and we should only design for the way people behave.
TBD: There’s TONS of great data on this, from MS and Yahoo as well as me and… I can’t find it! Will add when I do so it’s not lost forever.
Hide Inputs
I mean the practice of masking over password entry. Or Social Security Number entry. Or account number entry. Or… so on.
And when creating a password? Oh HELL no. Because then you do the double entry thing and it’s just a mess. This article outlines the basic issues and some design solutions, and quotes people designing big big products (including me!) as proof that it’s fine:
https://www.lukew.com/ff/entry.asp?1941
But… that’s for passwords. I am seeing if anything even MORE hidden fields now, and it must stop. The same issues are true (masking encourages errors, and there is no such thing as shoulder surfing), and the same solutions (I guess a /few/ people have to enter actual secret info in training or otherwise while sharing screen, so allow for the hide toggle, but default to visible!) but I see so many things that are not at all secret hidden.
Best guess I have is default, kneejerk behavior like a lot of “best practices,” where the developers or designers choose the most secret stuff on each page, mask that. Naw. Only allow to be hidden things that can be exploited. Credit card number? Pretty dangerous to be out there. Social Security Number? Naw, that’s used too much so isn’t truly secret.
For bonus points: avoid the secret codes at all. E.g. If passwords are risky, remove them and get into out of band authentication methods and token systems like FIDO faster.
—
Many of these are most of all violations of the design principle to let computers do computery things, so people can do human things. Don’t offload actions to people but consider them part of the system, and a limited resource as well.
Parenthetical plural(s)
It’s small and could be considered nitpicky but I think it’s very important and emblematic of cutting corners in iteraction, trying to make interface solve the problem.
Say you have a relative date, and want to write “1 hour ago” then also later on “2 hours ago.” Well, relative date/time display is a lot of parsing rules, so dev decides to dump some and want it to be “1 hour(s) ago” etc.
Parenthetical plurals are inherently confusing. Always. No one talks or thinks like that, so users have to parse it. And we know that UI content is hardly read anyway so any additional cognitive load is going to mean either the content is ignored, or it is misunderstood.
Don’t specify or placeholder like that, and don’t allow it to go to production. Make the effort to get custom pluralization for value labels or references.
Future topics?
Other things I may add in the future but I am not so strident about being hard bans:
Log Out. For apps at least, but even on the web, too many sign-on-each-time when not really needed, that leaves you with higher risks due to assumption of security.
FAQs. More the name and format but still.
Help. Design process-wise, yes. Never start assuming you need help but really a ban?
Upload dialog after dialog. Most upload-from-client takes too many steps. We want to upload a file so press the button, get the native picker. One step.
Lying and too many buttons. Print. Print. Print.