一般に、設計チームはプロトタイプの制作をインタフェースデザイナやソフトウェアエンジニアに一任してしまいます。ところが、彼らの本職は「完璧を目指す」ことなので、プロトタイプであっても一生懸命に作り込んでしまいがちです。何日も徹夜して”完成”させた”労作”がテストでさらしものにされると、それを作ったデザイナやエンジニアは自分自身が批判されているように感じてしまいます。
(略）これは全く無駄な議論です。テストで問題点が見つかるのは当たり前のことです。それも、初期のプロトタイプならば問題は山ほどあって当然です。設計チームは”犯人探し”に時間を費やすのでなく、”解決案の議論”に時間を費やすべきなのです P77

”段ボール箱”の自動販売機でも、人間が中に入れば商品を販売できます。音声コマンドを人間が聞いてシステムに入力を行えば、ユーザは声で操作できているように感じます。このようにコンピュータの代わりに「カーテンの影から操作」して、あたかもシステムが動作しているように見せる手法をオズの魔法使いといいます。 〜 プロトタイプの工数削減について P71

プロトタイプは、テストの目的と直接関係する部分だけはハイファイ（少なくともローファイではない）に作られていないと役に立ちません。例えば、建築家が作る模型の家は”間とり”を正確に表していますし、風洞実験のための模型飛行機は実際に”浮力”を生みます。
同じように、外観のデザイン案を比較検討するためのプロトタイプならば高品質なグラフィックスを使って、”見た目”は本物と同じレベルでなければいけません。オンラインショップのショッピングカートの機能を検証するためのプロトタイプは、購入プロセスの画面遷移やエラーメッセージを完全にシュミレーションできなければいけません。
プロトタイプとは全体をおおざっぱに作ることではなく、目的を達成するために「必要最小限のインタフェースに絞って作る」ことです。 P 68

ユーザの声を重視しているというと、ユーザ中心のアプローチを採っているように見えますが、極論すれば”ユーザ任せ”にすぎません。もし、ユーザが本当に実用的なアイディアを考え出して無償で企業に提供してくれるのであれば、そもそもプロの設計チームは不要でしょう。 P22

では、"想定ユーザ"を決めれば事足りるのでしょうか。例えば「流行と自分らしさの調査和を大切にする大人のユーザ」という定義をしたとします。しかし、これでは設計チームメンバーが自分勝手なユーザ像を思い描くことができてしまうので、何も定義していないのと同じなのです。このようなユーザ定義を、アラン・クーパー氏はゴムのユーザ(elastic user)と揶揄しています。 P6