Confusing a Heuristic with a Moral Imperative

Heuristics are excellent assistance in identifying potential problems with a given user interface design. The trouble lies when people come to rely on these as the sole input, that somehow they can come and overtake the more rigorous and far more accurate methods of evaluation. So please don't read below as being anti-heuristic but rather anti-misuse of heuristics.

I have been working more and more with consultants and pseudo-designers who have been working on evaluating web applications with a ton of heuristics in their hands. I can hear them clear across cubeville with clipboards in their hands:

"This is terrible, you are inconsistent between these pages, those pages ignore web standards, these other pages behave differently than the others, and oh my gosh look at all these unnecessary graphics, rip these all out. Get rid of the background coors, and ugh those button colors!"

Concept and user groups can trump heuristics

The fact is there could be a valid reason for violating every single one of these heuristics. Worse yet, there are these type of evaluators who without so much as learning the context go in a tear apart a site for violating, standards, UI conventions and other heuristics of all sorts.

A well defined and innovative concept will often require breaking a few rules. Moreover, if a concept is tailored to a specific user group, who is not the evaluator, then all the heuristics are almost invalid.

Heuristics are defined as (according to my Mac dictionary, and why should we doubt Apple?):

Heuristic (/hjʊˈrɪs.tɪk/) is an adjective for experience-based techniquesthat help in problem solving, learning and discovery. A heuristic method is particularly used to rapidly come to a solution that is hoped to be close tothe best possible answer, or 'optimal solution'. Heuristics are "rules of thumb, educated guesses, intuitive judgments or simply common sense.

Well here are some of these so-called common sense rules of thumb with some food for thought to think about along side of them, I am using the list from Jakob Nielsen's site, just to pick 10 basic one (http://www.useit.com/papers/heuristic/heuristic_list.html) This is not to pick on Jakob, as the point here is to discuss the pitfalls when heuristics are used as the sole means for evaluation, as such every heuristic can be picked apart and discredited, these are just 10 examples:

Heuristic	Justification (From Nielsen)	Yes but...
Visibility of system status	The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.	Maybe the user doesn't and shouldn't care. This heuristic assumes a user population actually cares about what is going on. Many user's could careless unless it's going to cause them a problem. You should have some basic trust built with your users and that trust may mean only informing them in the case of a problem, or handling the back end status problems yourself.
Match between system and the real world	The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.	Unless the purpose of the site is teaching the user a domain, or new task. An example would be Google Ad Words, where a novice user does need to learn some basic Advertising terminology or the advanced features will be lost on them.
User control and freedom	Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.	This heuristic seems to justify poor design. User control and freedom come more from safety is more than just redo or undo, its the ability to let the user explore and play around with the system. This is done through facile interaction design, a heuristic I have never seen listed.
Consistency and standards	Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.	This assumes 1. the user has no other reference point than platform standards 2. the platform has standards or usable ones Again this justifies lazy design. Standards are a fall back (I say this as someone who has written UX standards for 3 major software companies); the conceptual design should be leading.
Error prevention	Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.	Here is a useless Heuristic. What is an error? One man's error is another man's exploration. Maybe you should enable errors?
Recognition rather than recall	Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.	Indeed the memory load should be lightened for a user. However the better way to do this is to employ well established visual and interaction patterns. Worse, this explanation can be very misleading for the naive reader. Indeed I have experienced many a designer and developer use this heuristic explanation to 1. attack progressive disclosure and 2. To create a ridiculously busy screen throwing all functionality with equal visibility into a "one-stop shopping" kind of screen. Or worse a screen with a huge amount of text explaining how to use the screen. All of which are from a cognitive ergonomic perspective completely unusable.
Flexibility and efficiency of use	Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.	Building in redundancy to support multiple styles of interaction would be a better way of putting this. However, this needs to be seen in the context of a broader design concept. For example, there is often this designer fetish for drag and drop, when often it is only the designer who wants to perform this action. Also, implementing drag and drop in one place, invites the user to try it everywhere and very annoying when it does not work as they expect it to. So pick these accelerators well and not just for their own sake.
Aesthetic and minimalist design	Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.	The explanation is here at odds with the heuristic. The heuristic seems to cry for everything to be a Scandinavian styled minimalist design; whereas the explanation goes on about text. The visual design should leverage the brand and ability to communicate. Gratuitous graphics are supposedly bad unless the delight the target users (think of Google's doodles on their home page). As far as minimalism, I recall Tufte who said anyone can pull information out, how you pack information into something and keep it intelligible and usable is the real challenge.
Help users recognize, diagnose, and recover from errors	Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.	My only problem here is the "precisely indicate the problem." I am sure Jakob did not mean go into gory technical details of the problem, but rather concisely describe the issue. E.g. "Your data was not saved." not "Your data was sent to the application layer and experienced a time out longer than 3 ms and the system sent back the data in an unusable format." My formula for error message writing: "Short sentence what happened. (forget why) Short sentence how to fix it. A link can be added "Learn more" or "Why did this happen to such an undeserving user as me" for the morbidly curious.
Help and documentation	Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.	Far from apologizing for help we should revel in it.Help and documentation should be electronic and in context. For example, micro help (a question mark icon or What's this link which work on mouseover or a small popup) often assist the user without interruption.

The mythical 80/20 rule

In a sad day for most digital products and services, an italian economist, Vilfredo Pareto, observed that 80% of Italy's wealth was owned by 20% of the population. From that economic observation has come a torrent of the most far flung interpretations of a non-existent 80-20 rule. There is no 80-20 rule. There never was and never will be. Yet so many developers, designers, product managers evoke this mythical rule to justify the most outlandish pipe dreams, shoddy work or just plain laziness. Which is a pity because it ruins the credibility of a principle that in 20% of the circumstances can be 80% helpful.

The crux of when the 80/20 principle is helpful is when you need to fend off perfectionists. The the 80/20 principle helps you to illustrate that a minority of factors can result in a majority of effects, the aka 'biggest bang for your buck.' But how can you tell when the principle is being used wisely or not.

80/20 Pipe dreams
Some G-d forsaken Gui Guru once said that 80% of screens could be driven by templates; while only 20% of the screens needed to be designed. This completely unsubstantiated drivel has lead to many efforts to "automatically generate a UI". It has lead to millions of wasted dollars and development effort in worthless tools and idiotic processes all aimed at designing without designers. If the Guru was right then about 80% of the screens could be generated, reasoned the technocrati, you hit the 80/20 rule and you applications will be fine except for 20% of the time. Some more thoughtful product managers then would hire in an army of designers to cover the 20% they thought 'really needed design.' But even then, as one Product manager in just such a project told me, in how own pipedream: "I want you to design templates with such a narrow path of movement that a designer can only make the right choice."
The reality of the matter is more along the lines that 80% of a given screen could be generated while 20% needed to be designed, but oh the devil is in the details and often that 20% is where the most difficult design challenges lay. Therefore, the 20& should end up driving the other 80%, not the other way around. [Never mind the fact that this pipe dream totally negates the necessity and power of the conceptual design (see It's all about the concept).]

80/20 Shoddy work
Often someone will deliver (or even ask for) 80% of the work they really need to get done. This is usually done to purposefully keep the quality low. Example. A software engineer asks the designer for rough documentation that is quick and easy to read, just giving the 20% key interactions and let the 'no brainers' to the engineer himself. This assures the design bar remains low. With it this low shoddy work can triumph the design goals being so low. The design fails to deliver but it was set up to fail and no one even expected it to succeed in the first place. This way the technology can triumph, reason the developer, while the design has a systematic back place.

80/20 Laziness
All to often a designer themselves will end with a rough sketch and miss some of the finer details of the design they need to deliver again claiming to deliver according to the 80/20 rule. Often the excuse is: "No need to over deliver those developers won't design it to spec anyway." Or: "Stuff always comes up during development it will change anyway. I will just give them 80% and give them 20% margin to play with." This is pure laziness. As any good designer will tell you that the devil is in the details. Or as some of the better desigers have pointed out G-d is in the detail; because those small details are often what separates an ordinary design from a truly excellent well thought out design. That last 20% is again, the last thing you want to leave to a developer or other non-designer. Furthermore, those gnarly details you have solved will go a lot further in helping developers improvise when they have to than if you just leave them a blank space to fill in all on their own.

80/20 rawks
The 80/20 principle works excellently when you need to stop someone going off into the weeds of perfectionism. The software should be bug free. The software should please every user to do everything. The software should have perfect tests. Anything that reeks of perfectionist is liable for the 80/20 rule. For as we all know at one moment, the waters can get murky. e.g. one user's bug is another user's feature. Just make sure whenever some pulls an 80/20 on you, or you pull it on someone, that you have an objective measure to back up your 80/20. Yes, 20 percent of the people own 80% of the wealth. Yes, if we provide 20% of the functionality we will make 80% of the users happy as we can see in these usability tests, etc.