The single most important rule of UI design is:
Never neglect usability for power users.
Note that this rule is not “prioritize power users over beginners”: On the contrary, it addresses the prevalent problem of current UI design being done more or less exclusively for beginners, leaving more advanced users in the rain. This is also the reason why it is the most important rule: It is the most neglected rule. If the situation was the opposite, the opposite rule (m.m.) would apply: Equal treatment, not preferential treatment.
True, there are more beginners than power users; true, there is more money to be earned on the beginners (because there are more of them); true, every power user was once a beginner. However, the more advanced users typically spend more time with the product, they explore its potential to a higher degree, they are the more frustrated by its limitations, they are the ones that can produce works with it that are worthy of showing off, etc.
Why should the more advanced users be forced into a straight-jacket intended to help beginners? Software should enable, not disable—and disabling using the argument that most users will not want/need/understand a certain feature is unacceptable (solve such complications by just preventing accidental use and informational over-flooding of beginners).
To illustrate a common experience of power users through an analogy:
Consider being a botanist walking along a forest path. Two yards from the path you see an interesting plant that you want to examine—yet you find yourself unable to leave the path, because it is tightly hugged by an insurmountable fence. This happens again and again through-out the day. As you later inquire as to why there is a fence, the answer is “We want to protect visitors from poison ivy.”—a ridiculous restriction better handled by warning signs and the visitors own discretion; possibly supplemented by a hindrance that stops small children, but not adults.
This is to be contrasted with some valid reasons: To protect visitors from bears; to protect plants (or, indeed, bears) from visitors; the forest is private property.
Such reasons occur in software development too, but they are far rarer than the “poison ivy” claim. Further, in real life, even these allow exceptions: A botanist will often be trusted to interact with proper caution with the plants (where a layman would not)—but such exceptions are rarely made for computer scientists.
If the budget is limited (and it usually is) then there may be a need to prioritize; however, considering the principle of diminishing returns, a more equitable priorisation makes sense—in particular, as the beginners’ experience is imperfect not through lack of funds, but through incompetent design decisions, ignorance of research in usability, etc. There is room to improve usability for both advanced users and beginners within the budget of most development projects. (Make no mistake: Despite the priorization of beginners, their experiences are often far from ideal.)
Notably, many of the things that advanced users want are cheap to do, if the software has a good internal design (for example, allowing the users to map any keyboard short-cut to any action available through menus). Really powerful things like an internal scripting language and plug-in mechanisms are more taxing; but even they may pay off in the long run, because they allow users to add new features that make the product more valuable (Vime and Firefoxe are prime examples of this). They can even be beneficial for the internal development team through greater abilities to hot-patch, customize features, provide (possibly fee-based) packages of new features not originally delivered with the vanilla product, etc.
A particular frustration is that many modern software applications seem intent on actively hindering power users, not just passively not helping them. Examples of this include removing command-line switches (with the defense that the same settings are available within the application—which entirely misses the usuability issues involved); and deliberately trying to second-guess the user, which is likely to confuse the beginner and is hell for the power user: If I mean a software to do A and unmistakably tell the software to do A, then I expect the software to actually do A. Unfortunately, all too often, the software presumes to decide “Obviously, you meant B, even if you said A; so I will just do B instead.”, leading to frustration and loss of time.
Software producers should in particular beware that the power users will have different expectations, be less willing to make compromises, be more critical, etc. Consider, in analogy, travel: In the early days of railways, passengers were content to sit on uncomfortable seats, be bothered by smoke and noise, snail along at 30 mph, etc.—in fact, considering the time saved compared to locomotion by horse or foot, they may have considered it a miracle. The modern train traveller will still have to deal with sub-optimal seats and noise, but would likely consider the standards of old inacceptable; and he would be severely frustrated with 30mph. Someone with access to a “Star Trek” beaming device would similarly consider modern train travel inacceptable. (Notably, I am not talking about a “sent back in time and train is the only thing available” situation, but “beaming is available, but you are not allowed to travel by anything but train”.)
The same principle applies to software and software users: A beginner will be impressed with anything, and might even consider MS Word a miracle. The more advanced users will be increasingly critical, knowing that this or that could be done so much more efficiently. The command-line expert who finds himself in a Windows environment occasionally feels like someone has stolen his beaming device, with things that could be done in fifteen seconds, under e.g. Bash, taking fifteen minutes of manual work in Windows. Worse yet, very often artificial constraints make some easy tasks impossible.
A good example of what I am talking about can be found in the “Hal” example in this excellent Vi tutoriale. Consider going at this task with Notepad or Microsoft Word instead of Vi. (Note that delving into and understanding the technical details is entirely unnecessary; it suffices to just observe the magnitude of the task posed and with how litte typing it can be solved with a power-tool, and how very different a manager’s and a good developer’s attitude to leg-work is.)
Another example, from my time at E4: I had discussed our UML tool (Together) with a product manager. I considered the tool slow and user-unfriendly; he thought that it was very good. At a later occasion, I drew a UML diagram reflecting a semi-undocumented work-flow that he had been involved with. I requested and got his feedback for corrections, made the corrections, and requested his confirmation that everything was now as it should. His immediate reaction: Are you done with the changes already?!? Because I was the much more proficient user (both with this particular tool and with computers in general), I was limited by the restrictions and usuability problems of the tool; he, in turn, was limited by himself—not the tool. Correspondingly, I was both unhappy with the tool, and able to work much faster than he; he was happy with the tool, but comparatively slow. For him, it was enough just to be able to accomplish a certain output; I wanted to be able to have the same output fast and with little leg-work.