著者はVisual Basicの開発者で、今はコンサルタント。 いわゆるUI研究者ではないが、正しい意見を数多く述べて おり、正しい実例もたくさん示している。しょーもない 「UIガイドライン」本より余程役にたつと思う。
同じことをあちこちで言ってるようなのが気になるのと、 参考文献が無いのが惜しい。(何も参考にしていないのだろう)
DeMarcoとShneidermanとPARCとBrenda Laurelしか知らないようである

・尋問モード(アメリカのレストランモード)になるな。
ユーザに色々聞かずに自分で選択させろ！Buttoconを使え
Chap8
ファイルメニューなんて不要ではないのか
Chap9
データをうまく捜す方法が大事である
Chap11 なめらか？
"Flow"を重視せよ。思考をさまたげるようなインタラクションを
させるな
モードレスにフィードバックせよ。
工具を使うみたいな感じで使えるインタフェースにしろ
Chap12 プログラムの性質によりインタフェースを変えろ。
毎日使うものは少々ややこしいものを表示してもよいが
たまにしか使わないものでは自明にせよ
Chap13 アホなダイアログを出すな！
全然「OK」でないのに「OK」ボタンを押させるな
Chap14 履歴データの活用について
前のセッティングを次回使うようにすることは
有用である。選択枝が沢山ある場合でもそのうち
よく使うのは何種類かだけだからそれだけ示せればよい。
常に前回のを提示するようにすると、2種類交互に使う
とき困る。
Chap15 マウスを恐がる「象みたいな奴」も助けてやれ
Chap18
マウスにバーニヤを！
Chap24 クレディットをちゃんと表示せよ
「イースターの卵」式に隠しコマンドにするのも面白い
・絶対エラーがおこらないようにしろ

This is an exhaustive discussion of graphical user-interface design, particularly oriented towards Windows. The author starts from a work-oriented perspective on computer use and demonstrates how a graphical user-interface can be designed to support productivity and learning on different levels. Interaction techniques and widgets are dealt with in detail and the vocabulary introduced by the author should be very useful. There are also some significant ideas of wider scope, such as re-designing file systems, using animation in the interface, and endowing programs with memory. The writing style is easy-going and sometimes a bit colloquial, but the book is very accessible and generously illustrated. The author consistently writes as a designer rather than a usability expert, something that is sorely needed in the HCI field. On the whole, the book should be very valuable for interaction designers who need to build up their graphical user-interface repertoire.
(Lowgrenの本棚より。)

ニールセンのページ
設計初期段階におけるチェックにより相当な経済効果がある (変なインタフェースのために生産性が下がらない) にもかかわらず、その点が軽視されている。
■ スローガン

• 設計者がいくら考えても抜けがある(からユーザに実際に操作させることが絶対に必要)
• ユーザはいつでも正しい (ユーザの不満や失敗は常に改良の余地を示している)
• とはいえ、デザインに関するユーザの意見は正しいとは限らない。実際にモックを見せて評価させないとだめ
• カスタマイズ機能によりユーザにデザインさせるのはうまくいかない
• デザイナはユーザと同じ感覚をもてない。 一度見てしまうと、感覚が前と一緒ではなくなる (e.g. ランダムドット中の動物の絵) (この話はCooper本にあったのか？？)
• 副社長みたいな人の意見を聞いてはいけない
• 機能は少ないほうが良い
• 小さな違いも問題になることがある
• ヘルプがあればいいというものではない (なくても使える方がよい)
• ユーザビリティエンジニアリングはプロセスであり、こうすればいいという特効薬はない

■ ガイドライン

• 単純で自然なダイアログ
• ユーザの立場の言葉を使う
• 覚えなければならないことを最小に
• 首尾一貫
• 実時間フィードバック
• 簡単に抜けられるように
• ショートカット
• わかりやすいエラーメッセージ
• エラーが発生しにくいように
• ヘルプ/ドキュメント

正しい指摘が多いと思うし、そのとおり製品を作れば 正しい製品が出来るのだろうが、 面白い製品を作ることはできないし、 根本的に新しい製品を作ることもできないだろう。 例えば、VCRが何故使いにくいのかといった明白な問題を 分析することはできるだろうが、 WindowSystemのインタフェースがなめらかでないことが何故問題か、 といったことは分析できないし、 解決策を思いつくうまい方法があるわけでもない。 そのあたりは工学でなく芸術の分野に近いのかもしれない。
正しい設計をするためのヒューリスティクスも色々書いてあるが もちろんそれで全部ではなく、Cooper_AboutFaceに書いてある ような設計知識も必要だと思う。たとえば自明かもしれないが

• 自分で作る/使う/直すというループの高速化が必要

といったことも挙げられると思う。

UsabilityがUsefulnessの一部、みたいに書いてあったのが 不思議である。使いやすさと便利さはちょっと違うような 気がするが。(e.g. UNIXは便利だが使いにくいし、いくら 使いやすくしても便利さは特に変わらない) (1997/6/5 増井)

単純なシステムしか使わなければ、 ガイドラインの大半も不要かもしれない。