It is the apparent goal of the software industry to torture the human species into extinction. In the spirit of “Open for Business,” this short  guide provides 13 simple steps to weaponizing software applications to cause as much pain as possible to as many people as possible, to support the software industry in achieving its goal.

1.  Be intrusive

When a user launches your application, this is the perfect time to grab control and refuse to let her do anything else until she:

• Installs updates (especially, large, slow updates that require a reboot to complete)
• Renews her subscription
• Clicks on an advertisement
• Logs into a social network/mass surveillance system
• Configures privacy settings
• Updates her user profile and contact information
• Changes her password
• Chooses new security questions
• Agrees to an obscurely revised 30-page end-user license agreement

If the platform offers you a notification service of any kind, use it! Bury that user in notifications all the time. Give them as many things that need to be tapped or clicked on as you possibly can. Users need to be kept busy or they will get into trouble.

2.  Jealously block all rival tasks

When you are in control, be in control. When you are demanding that the user type something in, do not allow her to use another app to look up the requested information or, heaven forbid, to copy and paste verbatim text. You are the center of that user’s world. Grab that focus and never let go!

When a user brings in a second computer in order to get unstuck with the first, that is the look of success.

3.  Be incoherent

Just because a menu or file system has a hierarchical structure doesn’t mean that you have to be constrained by that rigid, authoritarian thinking. For example, you can have a menu called Object which contains several options followed by a sub-menu which is also called Object. If users were intelligent, they would appreciate the fine thinking and finesse you used to distinguish the Object-Objects from the other things that were merely Objects, much less the Objects which are not Objects at all.

4.  See no evil, hear no evil, speak no evil

Your software is a shining beacon of purity. All else is filth.

Do not allow users to contaminate your goodness by dragging in data from outside. Do not import or export any data format that is not your own. If you must export data, save it some place that the user will never find.

Never telegraph your intentions or your status to the user. The only reason to provide an activity indicator or progress bar is for disinformation. Let them believe that progress is happening at a predictable pace, then either stall indefinitely or surprise them with sudden violence.

5.  Avoid words

Words are no good. Words have to be in some specific language, which is discriminatory against all those who do not know that language. You could get sued for that.

Instead, use pictograms. Pictograms are better than words. Pictograms are intuitive. Everybody understands pictograms just by looking at them. That is why it was so easy for Egyptologists to understand ancient Egyptian hieroglyphs. No translation was needed. It was just obvious!

Let every toolbar, every menu, every option be a jumble of pictograms that you have specially selected for maximum intuitiveness.

6.  Embrace complexity

In prehistoric times, when proto-humans used mechanical devices called typewriters instead of computers, keyboards had an extra key called Shift. Everyone knew what it did: it changed from lowercase letters to uppercase letters.

From that common ancestor sprang the many extra keys that now populate the corners and fringes of modern keyboards:

• Command
• Control
• Alt
• Option
• A pictogram of some kind
• Function
• More functions (F1 through F-infinity)
• Esc

The keys are there, so use them! Or rather, force the user to use them. Every key and every possible combination of keys should do something wonderful and destructive. Finding a needed function should be like a treasure hunt. If users spend all day every day trying different key combinations at random, you want them to have years of fun.

When a key is apparently duplicated on the left and right side of a keyboard, you should never allow that to go to waste. The left and right keys should have different functions.

What if there is no keyboard? Fortunately, touchscreens, touchpads, and mice have evolved mechanisms to replace the complexity of keyboards with fresh, new complexities. People have lots of fingers, so put them to use! Every mouse button, every gesture, and every combination that can be expressed must do something different. Tap, mash, drag, double-click, tap in the corner, drag from the edge, click and hold for 5 seconds…the possibilities are limitless. Let your imagination run wild! Users will be in awe of your inventiveness.

Toolbars and menus! One is never enough. There should be another, secret toolbar that only appears when the user makes a certain gesture. Better yet, secret toolbars should be buried all over the place like anti-personnel mines. Did the pointer hit the side of the screen? Toolbar! Did the user tap on a special place in the toolbar? Whoa, another toolbar! And it’s in the way! And it won’t go away!

Finally, just when it seems that all possible input methods have been exhausted, never forget that any one of those billions of combinations can be a trapdoor to an alternative user interface that is completely different. The user can then embark on an exciting new quest to find the way back home from an alien world.

7.  Document to win

It is generally accepted now that good software needs no documentation, so only losers provide documentation. Don’t be a loser.

The only reason to document anything is so that you can call the user an idiot for not knowing it. For example, if the application bricks the device after being launched 32 times, you should note this fact at the bottom of a text file that is buried under a hidden directory, and then yell at users who complain about their devices getting bricked. It’s their own fault; the behavior was documented, and they were just too negligent to read it.

The only acceptable response to a frequently asked “How do I…?” question is a pedantic explanation of why the user should not, or does not, need to do that.

8.  Punish all escapees

You should offer facilities to customize the user interface to make it less terrible, but only as a trap.

All customizations of the user interface, including third-party add-ons, must be broken by routine, automatic updates. The user who spends hours on customizations will lose all that work when it disappears without warning or explanation.

9.  Keep changing it

Studies have shown that humans, for all their apparent stupidity, are capable of learning even the most complex and counter-intuitive tasks given enough time and incentive. Worse, they have been observed to pass on this learning to their offspring, who then, as adults, display an uncanny ability to navigate the complexity as if by reflex.

This cannot go unanswered. The animals must be kept in their place.

Each major new release of an app should come with a completely new user interface which seeks to neutralize any efficiencies that were discovered in the previous one, and which renders worthless any experience and skill that may have been gained through long-term use.

Under no circumstances should users be permitted to stop the treadmill of updates. Be sure to implement a remote kill switch so that you can deactivate old versions no matter what the user tries to do. Tell them it is for their own good because security is the most important thing. And by security, we don’t mean security for the stupid users; we mean security for the money in your offshore bank account.

Routine, automatic updates should make obscure changes throughout the user interface as if by a process of random mutation. The changes will escape notice until the user is in a time of critical need, when suddenly the critically needed function will just not be there where it used to be.

10.  Gray it out

Graying out a function on a menu is your ultimate weapon. Users who fight their way through the many layers of frustration and torment that you have laid out will arrive at the destination only to be thwarted at the very end. The princess is not merely in another castle: She is turned to gray stone, forever beyond reach.

11.  Gaslight the users

In response to questions about where a function went, confidently inform users that no such function ever existed.

Under no circumstances should any user complaint be routed to a person with the know-how and the access to correct a problem with the software. Your inviolate policy should be that the software is perfect and fails only when it has been sabotaged by stupid users. No matter the nature of the problem reported, always ask users to go through a series of time-consuming and pointless busy-work tasks that serve only to bring the software back to a known-to-not-work state. In the unlikely event that they fully comply with your instructions instead of giving up early, tell them that their problem cannot be reproduced and you cannot help anymore.

Realistically, this is all you can do. You can’t waste resources fixing bugs in the previous product; you need those programmers to be hard at work developing the next big stinker.

12.  Fail silent; fail deadly

It follows from the fact that the software is perfect that error handling is for losers. Any error or exception conditions raised by system libraries should be ignored because they are obviously wrong. Just bury them so that users will have no clue what happened. Remember, users are stupid: Don’t give them something to think about or they will only cause trouble.

The ideal mode of failure is slow, silent corruption that goes undetected until it has permeated all layers of backups, followed by a catastrophic failure at the time of the user’s most critical need.

13.  Cut them off

Long lifecycles for software are like long wars. Just as the true object of warfare is peace, the true object of software development is end-of-life. The timing is not for the users to decide; they are the enemy.

Thus, when you end a software application, end it completely. No documentation, no drivers, no support, no record of its existence of any kind should be left lying around. Leave users with no license, no migration path, and no recourse. It is better than they deserve.

Conclusion

Despite the diligent efforts of user experience professionals, all 13 of the foregoing sarcastic recommendations have already been put into practice. This guide therefore is a contender for de facto industry standard. Look on my works ye mighty, and despair.