What does it mean?
What this means is that you need to look at the whole picture, not just part of it. It's not enough to make something easy to learn, if it's not then easy and efficient to use. And ease and efficiency of use are blindingly important, but you can't lose sight of the fact that somewhere along the line, this has to be learned too.
There's a lot of angles you have to look at a project from. Some of them are hard to do as a designer. But if you skip steps, it'll show in your final product.
What to do?
First off, forget pleasing everybody. In a lot of cases, forget pleasing most people. There is no such thing as one-size-fits-all. That's where Microsoft has failed; they essentially try to force the same mold on everybody. And it just doesn't work.
Options
If you try to force one method on everybody, it will fail, and it will probably fail spectacularly. The fewer options you supply, the less applicability it will have. Now, removing options is a route to greater simplicity. It fulfilles the "easy to use without learning" criterion. But that's not a sustainable strategy.
Options. Confiurability. Exchangeability. For all its flaws, the X Window System, which is the standard graphic environment on Unix-type sytems, has achieved resounding success precisely because of its modularity (and associated replaceability) in terms of the final interface. You can freely swap around any of a number of window managers, such as ctwm (which I use), KDE, Gnome, fvwm, and a boatload of others. Some are simple, some are massively intricate. Some look stripped down, others resemble more complex interfaces like the Windows one. I could rattle off about 50 offhand, but I'm not going to do that. You get the idea.
The people behind it all realized that the specifics of a graphic interface are NOT one-size-fits-all. It's very individualistic. Building a good overall system means allowing choice, not trying to make the choices for the users.
Standards
Stuff needs to get done. And there are a lot of base tasks. You add a lot of configurability, you add flexibility, you add features... but sooner or later, someone will want something you don't, can't, or won't provide. Then, that person is going to use someone else's program.
This is all well and good for the spiteful people, but in the real world, work needs to get done. That's why open standards are important. This page is written using HTML, with some CSS for styling. Both are explicitly open and explicitly standard. As a result, any number of programs, from simple ancient open-source programs like Lynx, to big complex new browsers like Mozilla, to big closed-source proprietary monstrosities like Internet Explorer, can all view this. ASCII text is a very informal, and rather implicit, standard, so an unbelievable number of program can process, view, or edit it.
In contrast, formats like the default save format for Microsoft Word, are very tightly closed formats. They're really only usable by the (proprietary, in this case) programs that use them. And they're not exactly the most useful or efficient formats, either. It sounds pretty good from a commercialistic business-case sense, but pretty rotten from the usability perspective.
Documentation
Documentation can be written, in-program, verbal, or human. Support, be it mailing-list, newsgroup, phone-in, or big seminars, is part of documentation.
Have it. Provide it. Allow it. Encourage it. Keep it up-to-date. There's just not an alternative.
Conclusions
Operating Systems
Contrary to what is touted by Microsoft and their partisans, Windows is not truly easy to use, to say nothing of truly user friendly. Nor does Unix lack the essential qualities of usability.
Windows shines in instant-acquisition, or the ability to use without learning. They lack something in learnability, since there's no clear path of advancement available. They fail terribly, overall, in true usability, since their products focus on how they want something done, rather than how you the user want to do things.
Unix has traditionally shined (practically scintillated) in usability. It provides you the tools, and then stays the hell out of your way and lets you use them. It has also traditionally been pretty wretched at learnability. It's got plenty of reference, and plenty of power, but without someone who understands it to help you, the first few steps are pretty nasty. And it utterly lacks the ability to be used without knowledge.
Documentation would help the Unix side a lot. And there's plenty of it. What's needed is good, unified, consistent documentation, that hangs together. A single body of documentation that takes you from the absolute basics up to a moderate level of proficiency, and does it without oversimplifying. Oversimplifying makes things easier in the short run, to be sure, but it just causes trouble in the long run.
And a lot can be done with frontend programs. The command line is an immensely powerful tool, but it requires a correspondingly large amount of training and understanding. It's one of the traditional arguments against Unix systems. Good frontend programs are the right cure for this. Don't replace the backend; extend the frontend.
Windows pretty much fails to be suitable for extension in this way, since most of its base premises are built on control, rather than flexibility. You'd have to start over from scratch. And when you got done, you'd have something that looked a lot like a prettified Unix, anyway.
Design
Know your users. Talk to your users. More importantly, listen to your users. They know what they think they want. You know what you think they need. If you can find somebody in the middle to tell you what they really want and really need, you're well on your way to true success.
Don't lock either yourself or your users in. Flexibility is the root of all power. Sufficient complexity is essential. Excess complexity is obfuscatory. It's not easy, and sometimes not possible, to find a happy medium. But don't err on the side of excess simplicity, either.
Ending
True easy of use, with true ease of learning, is the ultimate goal. Don't sacrifice the former for the latter. But don't ignore the latter in favor of the former. It's a balancing act.
Happy tightroping!