BT

InfoQ ホームページ ニュース ワイヤフレームは必要か,不要か

ワイヤフレームは必要か,不要か

ブックマーク

原文(投稿日:2010/06/01)へのリンク

“百聞は一見にしかず” ということわざは,アジャイルの世界では時に忘れられているが,少なくとも設計者の多くはそれを信じている。あるチームでは 設計作業を小ステップで進めるように設計者に求めている が,そのプロセスは必ずしも最高の結果を生み出してはいない。また別のチームでは ワイヤフレームが官僚主義と受け取られていて,効率的開発の妨げになっている。

Booshtukka 氏は,現在の状況で 設計者がアジャイルのやり方を批判をするのは容易ではない,と指摘する。そのプロセスでは,くつべらの設計者にさえ漸進的設計の実行が求められる。それが創造性の発揮を困難にしているのだ。

おかしな話ですね – 設計はそれ自体,総体的な創作活動なのですから。家の絵を描く作業を想像してみてください。ただし,部分ごとに描くのです。最初に煙突。それから窓辺の植木箱。背後にある丘。次に玄関です。いらいらするでしょう。当然です。新たな部分を描くごとに毎回,それまで書いたものを修正して,全体のバランスを維持しなければならないのですから。

Sam 氏はこれと同じような 議論を Agile Usability グループで 始め,そこからワイヤフレームの妥当性と重要性を理解しようとしている。これに対して William Pietri 氏は,ワイヤフレームの必要の有無,あるいは必要な詳細度のレベルを決定するのは 主として個人とチームの役割である,と返答している。氏によれば,

これらの問題に一般解というものが存在するとは思えません。あなたが求めているのは個人の差,チームの差,そして最小の浪費,この3つの共通解なのです。私にとってそれを見つける唯一の方法は,最小の負担で仕事の成果を上げ続けられるように,プロセスに手を加え続けることなのです。

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 を行う最大の理由 として,開発を開始して更新し続ける前に全体イメージを明確にしておくことにある,とコメントしている。さらに,ワイヤフレームを開発よりも1イテレーションだけ前に作成できるならばそれも有効だ,とも言っている。Yoni 氏はこれに加えて,

対話的なプロトタイプ (の持つ,様々なレベルでの忠実性)が,アジャイル環境(とその他でも同様)における最も有効な成果物であることが分かってきました。開発者に馴染み深いことばで表現された成果物を提供することで,コミュニケーションギャップは暗黙的に削減され,提供後の説明(と対応作業の手間)を少なくすることができます。

Willam 氏は,チームに対する ワイヤフレームの価値と重要性 を評価するための興味深いアプローチを提案している。氏の主張によれは,一般的にワイヤフレームに対する受け取り方には,開発者と設計者とでは違いがある。そして設計者に対しては,ワイヤフレームの価値をデモンストレーションすることが効果的だ。

そのアプローチの価値を設計者に納得させるには,いくつかのストーリーをそれぞれの方法で試して,その結果を遡って議論する必要があるかも知れません。何か実行できないことがあれば,それをデモする方法を見つけるのです。

Jérôme Gravel-Niquet 氏が その方法 について付け加えている。その内容は次のとおりだ。

  • ユーザストーリーの基本的な説明を元に,ワイヤフレームを迅速に作り上げる;
  • 用意ができ次第,エンドユーザ向けのプレゼンを実施してインタビューとフィードバックを取得し,それに従ってワイヤフレームを調整する;
  • 基本部分が十分に固まった (ユーザと組織の承認を得られた) と確信できたなら,すぐにインターフェース設計に取り掛かる
  • 並行して,相互関係と機能の差異について説明するドキュメントを作成する
  • さらに統合に関しても有能な UX 設計者であるためには,開発チームがそのストーリーに従って作業を始める前に,インターフェースと相互関係の可能な限りの統合作業を行っておく。

このようにワイヤフレームは,チーム内部およびステークホルダーとのコミュニケーションを改善する手段として,その重要性の部分での一般的な同意は得られている。重要なのは過不足なく実施すること,負荷を低く保つこと,の2つだ。ワイヤフレームが十分な品質を保持することもまた重要である。Alex Jones 氏の弁を借りれば,大雑把なワイヤフレームは UX の comic sans フォント であるからだ。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。