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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主催の3Sさんは、Twitter上でのワイヤーフレームコミュニケーション研究会のやりとりを見て、開催を思い立ったとのことです。何度かのやりとりを経て、実現となりました。

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

ワイヤーフレームコミュニケーション勉強会＠大阪は2009/09/18に大阪で開かれた勉強会です。

そもそもの発端は2009/07/24に東京のSINAP様オフィスで株式会社エフエックスビイの原様が発起人となり開催されたワイヤーフレームコミュニケーション研究会の内容をふまえて、大阪でもワイヤーフレームコミュニケーションについて勉強しようという趣旨で開催しました。

この日は総勢11名の方があつまり、「ワイヤーフレームとはなにか？」をベースにフリーディズカッション形式で話し合いを行われました。

流れ自体は東京で行われたワイヤーフレームコミュニケーション研究会のトピックをベースでしたが、そもそもワイヤーフレームとはなにか？というトピックの部分での意見交換が非常に活発に行われ、参加者それぞれの考えているワイヤーフレームの認識の違いや、それに対する想い、現場でのワイヤーフレームを介した作用、問題点などを中心にディスカッションが行われました。

各人にそれぞれのトピックについてポストイットに記載して頂く事を当初は想定していましたが、ディスカッションを続けながらブレスト的に意見を出し合う結果になりました。それ自体は流れをとめるよりはよかったかなと感じています。また人数も少なかったので、face to faceのディカッションに向いている会になったと思います。

先に唯一ポストイットで回収した議事録を掲載いたしますが、現在参加者の話された内容をまとめていますので少々お待ち下さい！（現在約半分。残り鋭意書き起こし中）

• 外部設計図

• 見本
• 設計書
• 図的な要素分解ツール
• 概要
• ある意味ホワイトボード
• 見取り図
• 動的なものを静で表すもの
• 骨組み

• 自分にスケッチ（何回も）
• お客さんと話すもの
• モックアップ（HTML+CSS）

• クライアントから聞いた要望をラフに形にしたもの
• クライアントのイメージ作り
• レイアウト案

• デザイン要素の内ページ構成案
• コンテキストをUIに落とし込んだもの
• デザイナー＆クライアントとのコミュニケーションツール

• デザイン作業前の情報ベースの画面構成案
• クライアントとの確認ツールの様なもの

• デザインを決める前にコンテンツの配置について考えるためのツール
• どんな素材が必要かはっきりさせる為のツール

• 画面要素の確認図
• 初期段階の設計図
• クライアントとデザイナーをつなぐビジュアルコミュニケーションツール
• 構造設計図
• コンテンツの確認図

• 要素を画面に落とす行程

• 基盤
• 情報を整理するもの
• 建築で例えると鉄骨的なもの
• デザイン前のデザイン
• 地図的なもの

twitterアカウントの3Sさんという方が発起人です。

大阪版の参加申し込みは次のリンクワイヤーフレームコミュニケーション勉強会@大阪より。

また、下記について意見募集をしているとのこと。参加できなくても記入しとくと皆で共有できるかもしれません。ATNDのほうのコメント欄にお気軽に書き込みをしてください。

『特にデザイナーさんにご意見を頂きたい部分で「ワイヤーフレームで理解しにくいところ、助けになるところは？」

またこの会の様子や話し合ったことなどもネット上で公開し、広く皆とシェアしていく予定です。
大阪の皆さん、もしよかったら告知協力よろしくお願いします！！！