I started to figure out why intranets are so bad, and I came up with a list of problems that all of the ones I’ve seen seem to share. That’s when I noticed that these problems are in no way unique to intranets.
Many products I’ve used or worked on have had at least some of these problems.
None of the products I’ve used has ever managed to combine all of these problems into one enormous, unholy mess in quite the same way that a bad intranet can, but that doesn’t mean you shouldn’t give it a try! To help you out, here is a list of horrible things you can do to make your product just as bad as a typical intranet. Good luck!
Never throw anything away
The first key to really ruining your product’s usability is to never throw anything out.Have a new feature, link, or module? Throw it onto the main screen along with everything else you’ve ever released! If even one person thinks it’s important or useful, you must be sure to support it until the end of time. This will ensure that your interface is so cluttered that nobody will be able to use the 10% of your product that is actually interesting to 90% of your customers.
Don’t put anybody in charge
It is very important to make sure that no single person is responsible for your overall product. If you want a really terrible product, make sure to enforce this total lack of responsibility and ownership.After all, if you were to put somebody competent in charge, they might do something rash like develop a vision for the product and make sure that only relevant, useful features got added while unused features were removed. They might also get to know the users of the product and start coming up with new product ideas that would please paying customers. Even worse, they could be held responsible for changes in important metrics and expected to understand what features were affecting trivial things like revenue.
Let everybody change everything
For the love of God, don’t restrict who gets to make changes to any part of the product! With more companies using wikis instead of regular intranets, we’ve learned an important lesson: everybody should be changing everything all the time.Remember, within your company, everybody’s opinion is, of course, equally valid, and everybody should be independently making decisions about product direction. If you were to actually restrict who got to make changes and when, you might end up with a consistent look and feel to your product. You might even have somebody who actually knew everything that was being added to your product, which would ruin the surprise when one of your customers asks, “what the hell is this new feature, and why does it work like this?”
Ignore anything that doesn’t generate revenue DIRECTLY
Intranets almost never sell anything to anybody, so they don’t directly bring in money. Similarly, there are whole swaths of your product that don’t contribute in an absolutely direct way toward separating your users from their cash. For example, very few people actually pull out their credit card during registration, so it’s very important that you not spend ANY resources improving your registration process, no matter how many potential users give up in disgust. Only a very small percentage of them would have ended up giving you money anyway, so your time is probably better spent rebuilding the credit card submission process for the 37th time or creating a complicated promotion.Also, you shouldn’t believe people, particularly interaction designers or user researchers, when they tell you that happy, unconfused users are far more likely to pay for or continue using a particular service. Those people are lying to you for fun.
Don’t invest in improving infrastructure
Once a product or intranet is built, it is critical that you NEVER EVER change any of the underlying infrastructure. Do not tear out or rewrite old code. Do not optimize queries. And, I am begging you, do NOT change anything to improve scalability. Changing infrastructure takes time and resources, and all it provides is a more stable platform and a better, less buggy experience for your users. Instead, you should just keep hacking new bits onto the original shaky framework until the whole thing collapses in a heap.Use as many out of the box platforms as possible
As a corollary to the above, make sure to save time by integrating dozens of different out of the box solutions that almost do what you want them to, rather than taking the time to research and buy or build exactly what you need. There has never been a case where a pre-built, open-source solution was hard to install or maintain. They always do exactly what they’re supposed to, and, because your engineering team doesn’t build them, they are 100% bug and hassle free!Never do a full UX overhaul
Really, this is key. Whatever happens, do not, under any circumstances, do a complete sweep of your product in order to make sure that the end to end experience is consistent, usable, attractive, and intuitive. If each individual feature seems to make sense, there’s absolutely no reason why hundreds of them wouldn’t all work together seamlessly.Don’t Test It!
Why on earth would you want to observe people using your product? You might see the places that they’re having problems or getting confused. You might come up with ideas about how to improve the user experience. If you want a truly horrible product, you must never watch a customer fail to use it. Trust me. That will only make it less awful.Or Do the Opposite…
Of course, if you don’t want your product to be a bloated, confusing mess, you can always do the opposite of the above things. It doesn’t guarantee that your product will be perfect or make you rich, but at least it won’t be as bad as most of the intranets I’ve seen lately.Enjoy the post? Follow me on Twitter!
