ワイヤーフレームコミュニケーション研究会

前回に引き続き、ワイヤーフレームコミュニケーション勉強会@大阪議事録その2をお届けします。

今回はワイヤーフレームとはなんでしょう？というフリーディスカッションです。

下記に3Sさんのブログに掲載された記事の転載をさせていただきます。

---

ワイヤーフレームとはなんでしょう？(フリーディスカッション)

• デザイナーにしてもらう為にしやすい配置を指示する為のものという意識が強い。
• システム開発だと「外部設計書」と読んでいるもの
• 用件定義を画面にのせる行程
• サイト作成＝画面にどう表すかということでワイヤーフレームと近い意図
• 考え方はウェブアプリケーションを作成する行程と一緒

• 3Dでの骨組み＝ワイヤーフレーム
• 動的なものを静的に表現する為のもの
• メモ的なものを付箋使用し、貼りながらUIを考え、情報を整理する

• ワイヤーフレームは考えを出しやすい、交換しやすい、コストが少ない、時間を少なく。
• 他者とコミュニケーションする為のツール（プランニング用に、構造的にクライアントと確認できる）
• 初期の段階でワイヤーフレームで問題を確認、最終的なゴールに向かう為に為にワイヤーフレームを使った方がよい。（上記がなければデザインはスタイルだけになってしまう）

• カンプを示すというのとワイヤーフレームを作って画面に情報を落とす行程は後先という考えはない
• デザイン力を示す為のカンプ（クオリティを示す）と設計は切り離して考える、最終的にはマージ
• デザイン的に納得しなければ、クライアントは納得しない。
• 画面を通したコミュニケーションには、インターフェイスを使用するものはワイヤーフレームを使用した設計はフェーズとして必要。

• 考え方には２パターンある。
• デザイン発からどの様な骨組み作って行ってどう設計するかというパターン
• 設計発からどのような機能が重要なのかを考え、どうデザインに落とし込むかというパターンもちろん両方必要。

• お客さんとやりとり、エンジニア、デザイナとの落とし込みどころのコミュニケーションとしてのワイヤーフレーム

• 認識的な問題：制作側が「ワイヤーフレーム」と意識して使っているかという問題もある。
• 肉付けしているものもワイヤーフレームと呼んだりする場合もあるし、ほんとに構造中身要素を中心に設計ているものをワイヤーフレームと呼ぶ場合もある。
• 文字だけだとはワイヤーフレームではない。これだけだと目次的な要素だけ。
• ワイヤーフレームを使ってどの時点（段階）でどの情報をどの画面で整理するのか。
• ワイヤーフレームの認識の差は結構大きい。
• ワイヤーフレームの定義っていうのがふわっとしていて分かりにくい。

• フローチャート、動作案内設計図 ＝ 機能的な説明
• ビジュアル的なものは ＝ どちらかというと内部資料

• 手ラフ＝デザイナーがオペレーターに指示をだすもの、クライアントにはみせない

• 映像業界：コンテ・台本。　ビジュアルと文字（情報）は分割されている状態
• 建築：設計図とイメージボード
• 出版：つかみ本とイメージボード

• いまでは情報とビジュアルを分けて提出していたのが、この「分ける」作業が失われてモックの様なものをクライアントに見せるという事になってしまった。→設計図なのか、イメージボードなのかよく分からない曖昧なものという定義が後から付加されてしまった。
• 現在「ワイヤーフレーム」はこの曖昧なものが含まれてしまっているのではないか。

• 絵コンテ＝画面設計・・・多くの人間に画面に落とす上でどこに何を作るべきかの指示する上での設計書
• 請負の場合、それをクライアントと共有しなければならない。

• クライアントがどこなのか。
• サイトの所有者に対してワイヤーフレームや仕様書が必要？
• 所有者から請け負った人がクライアントに対してはワイヤーフレームや仕様書が必要。

• 自分でワイヤーフレームを作って自分でデザインをする場合と、他者に頼む時がある。
• 自分でデザインをする時でもデザインをしながら情報の配置を決めてしまうとややこしくなったり不具合がでたり、デザインに都合のよい様に変えてしまうので、
• 最初にデザインとは完全に切り離して構成を決めて、自分で作ったり、人に頼んだりしているので情報のみを意識したレイアウト表として使用している

• ワイヤーフレームは打ち合わせの為のもの。
  • 下絵、絵コンテみたいなもの。
  • 社内：色とか一切入れない。デザインの要素は一切いれない。
  • クライアント：もうこれデザイン案なんちゃうんくらいのクオリティのものを見せたりもする。

• 脈略を伝える為のツール、優先順位をはっきりさせるもの
• クライアントの意図、ディレクターの意図をくんでもらう為のツール
• 意図を、何を継承してデザインしてほしいのかを汲み取ってもらうためのツール

• Web業界に携わっている人は色々な業種（違う業種）から来た人が多い感じがする。
• そのためコミュニケーションコストが非常にかかりやすい
• ワイヤーフレームで効率的に、目的をはっきり、脈略をコミュニケーションではっきりとっていく。
• ワイヤーフレームにはビジュアル要素は全くなく、ビジネスインパクトを出す為にどうすればいいのか、コミュニケーションエラーをなくす、そうすればコストがかからない。
• ワイヤーフレームをだし、クライアントと話あうと抜けていたコンテンツが見つかったりするケースもある。
• ストラクチャーで固めたつもりなのに、ユーザー的に分かりにくい導線があった場合には、それが分かるように変更しなければいけないという気づきが生まれる。→どのようにそのユーザーにアプローチして行けばいいかという指針（ラベリング等）や、コンテンツをストラクチャー上に追加したりできる。
• クライアントとデザイナーとのコミュニケーションツール

• ワイヤーフレーム自体は大体こういものですよねというふんわりした大まかな形で作っている。
• クライアントには大まかなワイヤーフレームを提出して確認しているが、これにひっぱられないようにと制作側には釘はさす。
• クライアントが考えている想いを重点的に伝えて、もし提示したワイヤーフレームではない形でよいワイヤーフレームが考えられるならば、それを制作サイドで進めてもらってもかまわないというスタンス。

• ワイヤーフレームは画面フローを確認する上でクライアントと意思を疎通する上で非常に重要なツール。
• 過去にクライアントによってワイヤーフレームを理解できないと思われる場合があり、制作サイドから提出しなかった事があった。
• その場合、クライアントが画面遷移などのフロー自体が分からなくなり、トラブルになりかけた。
• 結果としてやっぱりワイヤーフレームを提出して、同時に画面フローを確認しておくべきだった。

• 案件の規模によって出さない場合もあるかもしれないが、画面でクリックできるもの（モックアップ等）をもっていったほうがいい。
• ワイヤーフレームは画面にどう情報が落ちるかという事を確認するもの。これは書類として整理しやすい。
• ユーザビリティ込みでこのワイヤーフレームでokかという確認をする場合は、最終的には動くものを持って行った方がいい。そうしないとひっくり返る場合もある。

• この場には業種が結構違う人間が集まっているのでワイヤーフレームの定義がそれぞれ違う。
• クライアントがワイヤーフレームを読めるか読めないかというスキル差の問題もある。
• ウェブサイトでどれだけ収益性を求めているクライアントではしなければならない対応が違う。
• クライアントと制作サイドがワイヤーフレームを使いながらサイトの構造についての問題点などつめていける場合には非常に効果的。

• ワイヤーフレーム自体がそもそもサイト内の関係性を表すもの、画面にどう情報を載せるかというものを示したもの
• フローチャート的なものはワイヤーフレームに含まれている
• どの様に情報が移り変わるのかを意味表すのがワイヤーフレームでもある

• 色んな書類の一部としてワイヤーフレームを使う場合と核の軸の部分としてワイヤーフレームを使う場合の２パターンある。

• 「ワイヤーフレーム」という言葉が一人歩きしている印象は受ける
• じゃぁ何？といった時と言った時に明確な言葉が帰ってこない。
• それ自体が設計図なのか、レイアウト指示書なのか。→でも設計図とレイアウト指示書は明確に違うということを意識しないといけない。

• レイアウト指示書はワイヤーフレーム完成後に発生するもの
• レイアウト指示書はデザイナーとコミュニケーションするもの