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.

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.

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.