“百聞は一見にしかず” ということわざは，アジャイルの世界では時に忘れられているが，少なくとも設計者の多くはそれを信じている。あるチームでは 設計作業を小ステップで進めるように設計者に求めている が，そのプロセスは必ずしも最高の結果を生み出してはいない。また別のチームでは ワイヤフレームが官僚主義と受け取られていて，効率的開発の妨げになっている。
Booshtukka 氏は，現在の状況で 設計者がアジャイルのやり方を批判をするのは容易ではない，と指摘する。そのプロセスでは，くつべらの設計者にさえ漸進的設計の実行が求められる。それが創造性の発揮を困難にしているのだ。
おかしな話ですね – 設計はそれ自体，総体的な創作活動なのですから。家の絵を描く作業を想像してみてください。ただし，部分ごとに描くのです。最初に煙突。それから窓辺の植木箱。背後にある丘。次に玄関です。いらいらするでしょう。当然です。新たな部分を描くごとに毎回，それまで書いたものを修正して，全体のバランスを維持しなければならないのですから。
Sam 氏はこれと同じような 議論を Agile Usability グループで 始め，そこからワイヤフレームの妥当性と重要性を理解しようとしている。これに対して William Pietri 氏は，ワイヤフレームの必要の有無，あるいは必要な詳細度のレベルを決定するのは 主として個人とチームの役割である，と返答している。氏によれば，
これらの問題に一般解というものが存在するとは思えません。あなたが求めているのは個人の差，チームの差，そして最小の浪費，この３つの共通解なのです。私にとってそれを見つける唯一の方法は，最小の負担で仕事の成果を上げ続けられるように，プロセスに手を加え続けることなのです。
Gene Arch，Paul Spencer の両氏は，ワイヤフレームの有用性は明確であり，多くの状況において困難な事態の予見に役立つ，という意見だ。そのために彼らのところでは設計者はまず，次のスプリントで最も優先度の高い設計作業を PO(Product Owner/プロダクトオーナ) と共同で行うことから始めている。
Pat Cheung 氏は，ワイヤフレームこそ自分たち進むべきの進むべき道である，と主張し，'HTML ワイヤフレームとプロトタイプ：苦痛なく進むために (HTML Wireframes and Prototypes: All Gain and No Pain)' というアーティクルを引用している。氏はアジャイルの世界では，ワイヤフレームの利点はさらに明確なものだ，とも言っている。
HTML ワイヤフレームとプロトタイプの作成は，開発チームを最終製品の開発に可能な限り近付けます。できの悪いアイディアは排除し，有用なアイディアを採択します … 特にユーザフローやページフローが明確になる場合は ...ワイヤフレームにゴーサインが出たとき，その最大のメリットが得られます。最終段階のコーディングに向けて，すべての用意はもはや整っているのです。紙からコンピュータへ，PSD から HTML へといった移し替えの必要はなく，CSS スタイルは大部分がすでに定義されています。HTML ワイヤフレームは広い範囲まで定義されているのが普通なので，実装作業も容易です。
同様の議論で Sascha Brossmann 氏は アジャイル環境で UX を行う最大の理由 として，開発を開始して更新し続ける前に全体イメージを明確にしておくことにある，とコメントしている。さらに，ワイヤフレームを開発よりも１イテレーションだけ前に作成できるならばそれも有効だ，とも言っている。Yoni 氏はこれに加えて，
対話的なプロトタイプ (の持つ，様々なレベルでの忠実性）が，アジャイル環境(とその他でも同様）における最も有効な成果物であることが分かってきました。開発者に馴染み深いことばで表現された成果物を提供することで，コミュニケーションギャップは暗黙的に削減され，提供後の説明(と対応作業の手間）を少なくすることができます。
Willam 氏は，チームに対する ワイヤフレームの価値と重要性 を評価するための興味深いアプローチを提案している。氏の主張によれは，一般的にワイヤフレームに対する受け取り方には，開発者と設計者とでは違いがある。そして設計者に対しては，ワイヤフレームの価値をデモンストレーションすることが効果的だ。
そのアプローチの価値を設計者に納得させるには，いくつかのストーリーをそれぞれの方法で試して，その結果を遡って議論する必要があるかも知れません。何か実行できないことがあれば，それをデモする方法を見つけるのです。
Jérôme Gravel-Niquet 氏が その方法 について付け加えている。その内容は次のとおりだ。
- ユーザストーリーの基本的な説明を元に，ワイヤフレームを迅速に作り上げる;
- 用意ができ次第，エンドユーザ向けのプレゼンを実施してインタビューとフィードバックを取得し，それに従ってワイヤフレームを調整する;
- 基本部分が十分に固まった (ユーザと組織の承認を得られた) と確信できたなら，すぐにインターフェース設計に取り掛かる
- 並行して，相互関係と機能の差異について説明するドキュメントを作成する
- さらに統合に関しても有能な UX 設計者であるためには，開発チームがそのストーリーに従って作業を始める前に，インターフェースと相互関係の可能な限りの統合作業を行っておく。
このようにワイヤフレームは，チーム内部およびステークホルダーとのコミュニケーションを改善する手段として，その重要性の部分での一般的な同意は得られている。重要なのは過不足なく実施すること，負荷を低く保つこと，の２つだ。ワイヤフレームが十分な品質を保持することもまた重要である。Alex Jones 氏の弁を借りれば，大雑把なワイヤフレームは UX の comic sans フォント であるからだ。