Golden Rules for Bad User Interfaces

Reasoning: Blocking user input (mouse, keyboard) not only prevents users from doing their work, but also from committing annoying errors.

Example: Systems startup is a very good event for blocking user input. If it takes long enough, users can go and get a cup of coffee or go to the bathroom.

Example: Application startup is another adequate opportunity for blocking user input. Users may write or answer e-mails, call someone on the phone, or book a hotel in the meantime.

Example: Page loading is also an appropriate event for blocking user input. Users may chat with their room mates, read the newspaper, or simply stare at the empty screen during that time.

Reasoning: This usually forces users to start over, because they forgot to save their work – and ensures that they will consider their work more intensively and seriously.

Example: Let editors or edit fields freeze at unforeseeable intervals so that users will not fall into the habit of saving their work frequently, which would unnecessarily waste valuable system resources.

Reasoning: We all know that illogical bits and pieces in the user interface are no serious barriers for professional users, but at least a couple of beginners will get stuck...

Example: Label a button that will only prepare an operation so that users believe that it will already do the operation. Here is a real-word example: In many e-mail applications, the Forward button does not actually forward an e-mail but prepares it only for forwarding (because, for example, the recipient has still to be provided).

Reasoning: Making processes that put the computer into agony more or less uninterruptible ensures that users take their mandatory coffee breaks.

Example: Start a backup or indexing process while users are not aware of it. Make this process hard to cancel, that is, let it ignore the users' mouse clicks and key presses.

Reasoning: Additional functionality would provide users with too many choices and might confuse them.

Example: When users want to add items to a list, allow them to add items at the end of the list only and let them then move the items to the correct position. That is, do not offer additional functionality for inserting items at their target locations. To add some spice, introduce spurious errors that return items to the bottom when users have already moved them half-way up.

Example: Do not offer the option of selecting multiple items, for example, for moving or deleting items. The option of working on one single item suffices to let users achieve their goals – apart from that it may take a little bit longer...

Example: After inserting a set of new items (for example, by command, drag-and-drop or copy-and-paste) don't show them as selected. This would help users to recognize where in the list the items were sorted in. To detect the items that were just inserted will consume quite some time, besides the pure recall of which items were inserted. (Contributed by Oliver Keim, SAP AG)

Reasoning: Destroying the work context allows users to reflect their work and ask themselves whether it really makes sense.

Example: Deselect selected screen elements after a system reaction (e.g. a round trip).

Example: Move HTML pages or tables that have been scrolled down by the user to the top after a system reaction (e.g. a round trip); in the case of multiple pages (e.g. in hit lists or document list) return the user to the first page.

Reasoning: Bad defaults are a nice way to surprise users, be it immediately or – at best, unexpectedly – anytime.

Example: Set default options in Web forms so that users get unwanted newsletters or offers, have their addresses distributed, etc.

Example: Set the default option in dialog boxes on the most dangerous option, for example, on deleting a file or format the hard drive.

Example: In forms, set dates (or other data) on useless default values. For example, set the date for applying for a vacation on the current day.

Reasoning: Examples are a perfect teaching method. But as we all know, bad examples are the best – they allure most.

Example: Just follow any of the other golden rules on this page, that's a perfect start.

Example: If you have to make presentations make sure that you include your bad examples in the presentations.

Note: Good examples are hard to find and typically criticized until nobody appreciates them anymore. Why waste time with unproductive discussions?

Reasoning: You are the expert and know what users need – because you know what you need. Why should they need something else?

Example: If you think that a certain functionality is not needed don't implement it – why should other people need it?

Example: Many end users have many opinions, you have one. That's far easier and faster to implement.

Note: Doing without site visits saves your company a lot of time and money.

Reasoning: This teaches people to take more risks, which is important particularly in economically harder times.

Example: Do not offer an Undo function.

Example: Do not warn users if actions can have severe consequences.

Note: If you want to top this and make using your application like playing Russian roulette, change the names of important functions, such as Save and Delete, temporarily from time to time...

Reason 1: This will make your application completely inaccessible to visually impaired users. Therefore, you can leave out all the other accessibility stuff as well. That will save you a lot of development time.

Reason 2: This will drive many experts crazy who used to accelerate their work with keyboard shortcuts. Now, they will have more empathy for beginners because they are thrown back to their speed.

Reasoning: This strategy stimulates users to explore your application and learn a lot about it.

Example: Place buttons for important functions off-screen so that users have to scroll in order to access them.

Example: Hide important functions in menus where users would never expect them.

Reasoning: Lifelong learning is hip. As many of us spend a lot of their time at the computer, it's the ideal stage for learning. Moreover, sociologists bemoan that people's vocabulary is more and more reducing. Applications with a challenging vocabulary can go against this trend.

Example: Always send URLs as UTF-8 (requires restart) (advanced settings in MS Internet Explorer)

Reasoning: Abbreviations make an application look more professional, particularly if you create abbreviations that are new or replace commonly used ones.

Example: Use abbreviations for field labels, column headings, button texts even if space restrictions do not require this.

Examples: Use "dat." instead of "date," "TolKy" instead of "Tolerance Key," "NxOb" instead of "Next Object," and many more...

Reasoning: Most officices have become very hectic and stressful these days. Phone calls, e-mails, smsses, and more hail down on office workers. Slow software brings back at least some stability to their office lives.

Example: There are nearly unlimited possibilities of making software slow. For example, you can include long lasting checks or roundtrips after each user input. Or you can force users through long chains of dialog boxes.

Reasoning: Standards lead users to exhibiting rigid habits and develop certain expectations as to the applications. Today's users need, however, to be flexible and open-minded.

Example: Do not use standard screen elements for a given purpose, such as single selection (e.g. use checkboxes instead of radiobuttons because they look nicer).

Example: Do not place menu items into the categories and locations they typically belong to (e.g. place "Save" in the "Edit Menu").

Reasoning: Users want to be helpful, even to computers. Provide them with sufficient opportunities.

Example: It's a "good" habit to let users enter data that the system already knows and could provide beforehand.

Example: Let users enter data into fields only to tell them afterwards that they cannot enter data there (e.g. an application lets you enter data on holidays or weekends and tells you afterwards that you cannot work on those days).