General application user interface guidelines:

• Always use cute icons, buttons, and graphics. Everyone loves big red hearts, pink bunnies, and yellow smily faces.

• Don't be afraid to experiment with colors!

• Your application should play fun sounds while operating to keep the users entertained.

• Never, ever, under any circumstance use the OS-native graphical controls or widgets. Users get bored of the same old buttons, text boxes, and stuff.

• When possible, disable window management and use unusual, oddly placed graphics for the windowing functions such as the window close option.

• When writing your own controls or widgets, make absolutely sure they look and feel nothing like the OS-native widgets or anything else the user might expect. Otherwise you might accidentally make the user think that your application is actually designed for their OS.

• Use your own creative ideas on how a "save as" dialog should look and work. Built in ones are always too limiting.

• It is important that the user should never be able to tell the difference between a checked and unchecked check box or option box.

• Always use obscure or poorly drawn graphics for your tool bar buttons, and never put text on them.

• Avoid including a preferences or options dialog. Instead, let the user use the standard OS provided text editor or an editor of their choosing to edit text configuration files. .

• Users need time to think about what they are doing and get coffee. Your application should always take at least 5 minutes to load even on the fastest available computer.

• Make sure an accidental double-click on a single-click item does something really nasty or unexpected.

• Tool tips are the perfect way to display critical information.

• To get the most screen space, force your application to always run maximized.

• Always make the default positions of floating properties windows cover something important.

• Use the most exotic fonts you can find.

• Your application's user interface should be flexible and customizable to the point where if the user accidentally sneezes on the mouse or keyboard they will have to spend the next half an hour setting things back.

• Let a 5-year old draw your graphics, including your corporate logo.

• File browsing dialogs are not needed, users can easily remember and type in long file paths.

• Design your application so it requires the user to set their tiny monitor to 10512*7430.

• Always crash at a critical step and then display a fake apology to the user.

• It is a mistake to make use of application hooks in the native desktop environment such as new file templates, file associations, or program menu icons.

• The exception to the above is placing icons in the system tray. Place as many icons as you can in the system tray and make sure that the user can not remove them.

• If your program implements keyboard shortcuts be original and make them completely different from any other applications.

• Rent extra UI space in your application out for advertising. Advertising benefits the users and your wallet.

• Never underestimate the power of nudity.

• Don't forget to embed a hidden video game as an "easter egg".

Application Help: How to make a help system that is impervious to usefulness.

• There is no need to include a manual with software. These days users are smart enough to figure out this kind of thing on their own.

• If you do include documentation, there is no need for printed manuals. Users love staring in to a 17 inch light bulb all day.

• Always put your installation instructions on the CD-rom rather than in a printed manual to save paper. The instructions should be installed with the rest of the program so they are not accessible until it is installed.

• Keep help files simple. Only state the bleeding obvious about any given topic.

• There is no need to use consistent terminology.

• For program error, warning, question, and information messages, explain what is going on to the user in the most technical terms. They really need to know and learn this stuff because it is important. As part of the message dialog include a help button that opens the help file and displays exactly what the message just said.

• Display as many information and question messages as possible in as many different places as possible. Except before critical irreversible operations such as wiping the hard drive.

• It is acceptable to use "Engrish" throughout your application. All your help file are belong to us.

Making the web do things it has never done before
(and should never do again).

• Always build a web browser in to your application. For best results make your own web browser.

• Always hard code hyperlinks in to your application. Then make sure that the links don't work two months after the application is deployed.

• When you launch a web browser, never use the user's default browser. Always launch the crappiest one available (I.E.: IE) (See above, you should write your own).

• Always use hyperlinks instead of buttons. Hyperlinks are cool.

• Be sure to include a throbber graphic in every window of your application.

• Applications should look like web pages because the web is the embodiment of usability.

• All modern applications are required to automatically sign users up for spam.

OS Specific tips
 

• For a great first impression during your OS setup, never set the video to a refresh rate that works with user's monitor.

• In fact, your OS should never, ever set the proper refresh rate for the monitor. Eye strain is good. In fact, whenever possible set it to a refresh rate that the monitor can't handle at all. If the user does manage to set a higher refresh rate, make sure it is non-standard so they have to fiddle with the monitor sizing and positioning. Bonus points for finding a refresh rate that makes the monitor blow up.

• When packaging a GUI or operating system make sure the same functionality is available in at least a dozen different places in unrelated programs.

• Include three of every kind of application program. (four or more if possible).

• Install all possible advanced utilities and mindless junk that the typical user will never use.

• Uninstallation options are out of style, don't include any. If you do need to include them make sure they always choke on dependencies.

• It doesn't matter if your file manager / desktop shell is slow and sluggish. Go ahead and integrate it with your web browser. In fact, integrate it with several web browses while you are at it.

Application design for the ultimate user experience (in hell)

• Begin coding the guts of the program immediately. Designing the UI can come later in the development process.

• Don't waste time writing efficient code. GUIs don't need to be responsive and it is easy to make users upgrade to the latest 10,000,000 terahertz CPU and who doesn't need another zillion gigabytes of ram?

• You can implement features half way. Your users will forgive you. (And if they don't, screw them anyway). Or you can always make them upgrade to the next version.

• You don't even need to finish your software, if someone else has a problem with it they can fix it themselves.

• It is safe to ignore the overall purpose of the application you are writing. Just make it do what you want.

• There is no need to do any kind of user testing or research. Programmers always know the best way to design a user interface.

• Let the users dictate design and implementation decisions, after all they know what they need.

• If this is a corporate environment, always design the user interface the way the boss wants it. After all, that degree in user interface design he has is how he got to be the boss right?

• When porting your application to another OS platform, there is no need at all to modify the way your application looks or behaves.

• Always hard code all references to the file path your application must run in. The user will never have a need to install anywhere else and you will never run in to naming conflicts.

• Sue anyone who makes a UI even remotely like yours. That's what the legal system is there for right?

• Always use bizarre, scary sounding code names for the name of your application. For best results it should be an acronym for something that doesn't make any sense, and the acronym should be recursive.

• Never remove old, obsolete, buggy, or nonsensical features from your application.

• Pre-load your (now huge) application at system startup. It doesn't matter if it slows down the rest of the system, it is important that your application, which most users only use only occasionally, start the fastest. .

• Add all possible features to your application. Even those that already exist in the OS. In fact, your application should eventually become an OS.