前回に引き続き、ワイヤーフレームと完成サイトの比較みたいな記事をピックアップしてみます。
LEVEL STUDIOSという代理店で働く傍ら、個人事業主としてUXコンサルタントをしているAlexis氏のサイトにも制作したサイトとのワイヤーフレームが対で掲載されています。
Alexis Antonelli | User Experience Consulting | Activision.com

他にも
のプロジェクトの簡単な説明とワイヤーフレームなどがあります。
こういったワイヤーフレームもポートフォリオに掲載しているケースはあまりないので、もっと出てくるといいのになあと思いました。
掲載されているワイヤーフレームは、合番と共に詳細なコメントもついており、こういった補足説明のつけかたによっては混乱のないワイヤーフレームが実現できそうですね。
Apt Mediaというアメリカメリーランド州にあるインタラクティブデザインのコンサルタント会社が、ワイヤーフレームの状態と完成したWebサイトを交互に挙げつつ、潜在的な落とし穴3つについて語った、
“Designers who wireframe: pros and cons”
というエントリーがあがっています。(1年近く前の記事ですが。でも公開時にかかわらず良い記事をいろいろ紹介していこうと思っています)

これによると、潜在的な落とし穴は、
- デザインされ過ぎたワイヤーフレーム
- 着色されたワイヤーフレームに似てしまう
- ワイヤーフレーム作成とデザイン作業のスイッチング
だそうで、上記ポイントは、第1回目の研究会@東京でもあがったポイントでした。
様々な経験則から導き出された結論は、参考になるところが多いです。
今日はワイヤーフレームのガイドラインに関するネタです。
シアトルにあるSchool of Visual Concepts という学校で行なわれているPRINT2WEBというクラスでJohn Rice氏が教えている内容がWebで公開されており、この中にワイヤーフレームガイドというページがあります。

ここでは、CS2用のデータやPDFをダウンロードすることが出来ます。
自分で使うためにワイヤーフレームの仕様を整理しているという人には参考になるかもしれません。
kara_dです
ワイヤーフレームという言葉は、いろいろな業界でいろいろな用途で使われています。
僕はワイヤーフレームというと90年代に一世を風靡したwireframe studioを思い浮かべてしまいます。当時Flashを使っていた人間にとって、羨望の的だったのはないでしょうか。2000年以降にWebデザインを始めた人にはあまりなじみがないかもしれません。当時、いわゆる「Cool」なWebデザインを扱った輸入版の書籍にしょっちゅう取り上げられていた記憶があります。

そのwireframe studioですが、実はまだ続いていて、最も長く続いているWebデザインエージェンシーの一つとなっています。
最近の仕事もabout_usページで見る事が出来ます。
皆さんはワイヤーフレームというと何を思い浮かべますか?
第2回目のワイヤーフレームコミュニケーション研究会の構成を検討中なkara_dです
知っている方は今更というかもしれませんが、国内にはWebSig24/7という団体があります。WebSig24/7は、mixiをメインに活動してきたWeb制作に関わる方には特になじみのある団体で、イベントをこれまで30回近く開催してきている他、様々な分科会が存在し、国内の大きなコミュニティとして知られています。
そのWebSig24/7が、『サイトマップ標準書式制定プロジェクト』というプロジェクトを発足しました。

http://smp.websig247.jp/index.php?title =%E3%83%A1%E3%82%A4%E3%83%B3%E 3%83%9A%E3%83%BC%E3%82%B8
サイトマップというのは、Webサイトから見れるナビゲーションのことではなく、主にWebサイトの設計時にやりとりされる検討資料のことで、制作に携わらない人にはあまりなじみがないものといえるでしょう。
ワイヤーフレームが各ページに関する構造をまとめたものとすれば、サイトマップは、Webサイト全体の構造をまとめたものと言う事ができます。これはプロジェクト内で作成されるものであるため、なかなか外部にノウハウが漏れることがなく、従って各制作会社ごとに独自の描き方をしているのが現状です。
これら複雑化したサイト構造の表現方法はドキュメント作成者により異なり、毎回ドキュメントの書式と記載ルールを学習する必要があるため、クライアント、制作者、それぞれのコミュニケーションを非効率なものとしています。例えばUMLはその記述法が制定されているために、誰もが学ぶことが出来ますが、サイトマップに関してはまだその段階にありません。
このプロジェクトにおいても上記のように現状が書かれており、書式を統一することでコミュニケーションロスを減らそうというのが狙いの一つだそうです。
標準書式に関しては、本研究会でも少し議論がされており、例えば標準書式が出来る事によりWebサイトのありかたを狭める可能性がある旨が指摘されていますが、そういったデメリットがあると同時に、仕様があることで標準書式を出力可能なツールを作りやすくなるというメリットも考えられます。
ワイヤーフレーム研究会も表記方法や記述メソッドに関する研究をつづけていく予定なので、大いに共感するところがあります。本研究会からもいずれは、皆が自由に使えるガイドラインのようなものを提示できたらと思います。
ご無沙汰していますkara_dです。
第1回のワイヤーフレームコミュニケーション研究会以来すっかり間が空いてしまいましたが、また活動を再開していきたいと思います。
第2回目のワイヤーフレームコミュニケーション研究会@東京はワイヤーフレームに関するライトニングトークをする会にしたいと考えています。ライトニングトークというのは、5分ほどの時間でプレゼンテーションをする小さなセミナーのことで、だいたい1回に数人から十人程度の発表が行なわれます。
ワイヤーフレームはWebサイトの制作において決して主役ではありませんが、それぞれ様々なノウハウを持っていると思うので、ライトニングトークみたいな形式がピッタリだと思いました。(発表する人は会へ優先的に参加できるようにする予定です)
まだ細かな内容は決まっていないので、それまで国内外のワイヤーフレームに関する今の話題や過去のアーカイブなどをまとめてみるということをやってみます。
まずは、オンラインでワイヤーフレームを作ることもできるドローツールサービス「Cacoo」https://cacoo.com/を紹介します。
Cacooは、決してワイヤーフレームのためのツールというわけではなく、Visioなどで普段書いているような作図からUMLに至まで様々な図が書けるサービスです。おまけに、単に作図をするだけでなく、ユーザー同士でコラボレーションして作図したりといったソーシャル的な機能もついています。
もちろんワイヤーフレームも描くことが出来ます。適当に描いてみましたが、こんな図もすぐに作れます。

しかも普通のワイヤーフレームだけでなく手書き形式のワイヤーフレームも描く事が出来ます。手書き用の部品も用意されています。

このCacoo、インスペクタパネルを使って図の要素に細かな設定を行なう事ができるので、かなり自分好みの図を描く事ができます。

小規模なプロジェクトでのメンバー同士のさくっとした情報共有にはピッタリなツールと思いました。
前回に引き続き、ワイヤーフレームコミュニケーション勉強会@大阪議事録その2をお届けします。
今回はワイヤーフレームとはなんでしょう?というフリーディスカッションです。
下記に3Sさんのブログに掲載された記事の転載をさせていただきます。
ワイヤーフレームとはなんでしょう?(フリーディスカッション)
- デザイナーにしてもらう為にしやすい配置を指示する為のものという意識が強い。
- システム開発だと「外部設計書」と読んでいるもの
- 用件定義を画面にのせる行程
- サイト作成=画面にどう表すかということでワイヤーフレームと近い意図
- 考え方はウェブアプリケーションを作成する行程と一緒
- 3Dでの骨組み=ワイヤーフレーム
- 動的なものを静的に表現する為のもの
- メモ的なものを付箋使用し、貼りながらUIを考え、情報を整理する
- ワイヤーフレームは考えを出しやすい、交換しやすい、コストが少ない、時間を少なく。
- 他者とコミュニケーションする為のツール(プランニング用に、構造的にクライアントと確認できる)
- 初期の段階でワイヤーフレームで問題を確認、最終的なゴールに向かう為に為にワイヤーフレームを使った方がよい。(上記がなければデザインはスタイルだけになってしまう)
- カンプを示すというのとワイヤーフレームを作って画面に情報を落とす行程は後先という考えはない
- デザイン力を示す為のカンプ(クオリティを示す)と設計は切り離して考える、最終的にはマージ
- デザイン的に納得しなければ、クライアントは納得しない。
- 画面を通したコミュニケーションには、インターフェイスを使用するものはワイヤーフレームを使用した設計はフェーズとして必要。
- 考え方には2パターンある。
- デザイン発からどの様な骨組み作って行ってどう設計するかというパターン
- 設計発からどのような機能が重要なのかを考え、どうデザインに落とし込むかというパターンもちろん両方必要。
- お客さんとやりとり、エンジニア、デザイナとの落とし込みどころのコミュニケーションとしてのワイヤーフレーム
- 認識的な問題:制作側が「ワイヤーフレーム」と意識して使っているかという問題もある。
- 肉付けしているものもワイヤーフレームと呼んだりする場合もあるし、ほんとに構造中身要素を中心に設計ているものをワイヤーフレームと呼ぶ場合もある。
- 文字だけだとはワイヤーフレームではない。これだけだと目次的な要素だけ。
- ワイヤーフレームを使ってどの時点(段階)でどの情報をどの画面で整理するのか。
- ワイヤーフレームの認識の差は結構大きい。
- ワイヤーフレームの定義っていうのがふわっとしていて分かりにくい。
- フローチャート、動作案内設計図 = 機能的な説明
- ビジュアル的なものは = どちらかというと内部資料
- 手ラフ=デザイナーがオペレーターに指示をだすもの、クライアントにはみせない
- 映像業界:コンテ・台本。 ビジュアルと文字(情報)は分割されている状態
- 建築:設計図とイメージボード
- 出版:つかみ本とイメージボード
- いまでは情報とビジュアルを分けて提出していたのが、この「分ける」作業が失われてモックの様なものをクライアントに見せるという事になってしまった。→設計図なのか、イメージボードなのかよく分からない曖昧なものという定義が後から付加されてしまった。
- 現在「ワイヤーフレーム」はこの曖昧なものが含まれてしまっているのではないか。
- 絵コンテ=画面設計・・・多くの人間に画面に落とす上でどこに何を作るべきかの指示する上での設計書
- 請負の場合、それをクライアントと共有しなければならない。
- クライアントがどこなのか。
- サイトの所有者に対してワイヤーフレームや仕様書が必要?
- 所有者から請け負った人がクライアントに対してはワイヤーフレームや仕様書が必要。
- 自分でワイヤーフレームを作って自分でデザインをする場合と、他者に頼む時がある。
- 自分でデザインをする時でもデザインをしながら情報の配置を決めてしまうとややこしくなったり不具合がでたり、デザインに都合のよい様に変えてしまうので、
- 最初にデザインとは完全に切り離して構成を決めて、自分で作ったり、人に頼んだりしているので情報のみを意識したレイアウト表として使用している
- ワイヤーフレームは打ち合わせの為のもの。
- 下絵、絵コンテみたいなもの。
- 社内:色とか一切入れない。デザインの要素は一切いれない。
- クライアント:もうこれデザイン案なんちゃうんくらいのクオリティのものを見せたりもする。
- 脈略を伝える為のツール、優先順位をはっきりさせるもの
- クライアントの意図、ディレクターの意図をくんでもらう為のツール
- 意図を、何を継承してデザインしてほしいのかを汲み取ってもらうためのツール
- Web業界に携わっている人は色々な業種(違う業種)から来た人が多い感じがする。
- そのためコミュニケーションコストが非常にかかりやすい
- ワイヤーフレームで効率的に、目的をはっきり、脈略をコミュニケーションではっきりとっていく。
- ワイヤーフレームにはビジュアル要素は全くなく、ビジネスインパクトを出す為にどうすればいいのか、コミュニケーションエラーをなくす、そうすればコストがかからない。
- ワイヤーフレームをだし、クライアントと話あうと抜けていたコンテンツが見つかったりするケースもある。
- ストラクチャーで固めたつもりなのに、ユーザー的に分かりにくい導線があった場合には、それが分かるように変更しなければいけないという気づきが生まれる。→どのようにそのユーザーにアプローチして行けばいいかという指針(ラベリング等)や、コンテンツをストラクチャー上に追加したりできる。
- クライアントとデザイナーとのコミュニケーションツール
- ワイヤーフレーム自体は大体こういものですよねというふんわりした大まかな形で作っている。
- クライアントには大まかなワイヤーフレームを提出して確認しているが、これにひっぱられないようにと制作側には釘はさす。
- クライアントが考えている想いを重点的に伝えて、もし提示したワイヤーフレームではない形でよいワイヤーフレームが考えられるならば、それを制作サイドで進めてもらってもかまわないというスタンス。
- ワイヤーフレームは画面フローを確認する上でクライアントと意思を疎通する上で非常に重要なツール。
- 過去にクライアントによってワイヤーフレームを理解できないと思われる場合があり、制作サイドから提出しなかった事があった。
- その場合、クライアントが画面遷移などのフロー自体が分からなくなり、トラブルになりかけた。
- 結果としてやっぱりワイヤーフレームを提出して、同時に画面フローを確認しておくべきだった。
- 案件の規模によって出さない場合もあるかもしれないが、画面でクリックできるもの(モックアップ等)をもっていったほうがいい。
- ワイヤーフレームは画面にどう情報が落ちるかという事を確認するもの。これは書類として整理しやすい。
- ユーザビリティ込みでこのワイヤーフレームでokかという確認をする場合は、最終的には動くものを持って行った方がいい。そうしないとひっくり返る場合もある。
- この場には業種が結構違う人間が集まっているのでワイヤーフレームの定義がそれぞれ違う。
- クライアントがワイヤーフレームを読めるか読めないかというスキル差の問題もある。
- ウェブサイトでどれだけ収益性を求めているクライアントではしなければならない対応が違う。
- クライアントと制作サイドがワイヤーフレームを使いながらサイトの構造についての問題点などつめていける場合には非常に効果的。
- ワイヤーフレーム自体がそもそもサイト内の関係性を表すもの、画面にどう情報を載せるかというものを示したもの
- フローチャート的なものはワイヤーフレームに含まれている
- どの様に情報が移り変わるのかを意味表すのがワイヤーフレームでもある
- 色んな書類の一部としてワイヤーフレームを使う場合と核の軸の部分としてワイヤーフレームを使う場合の2パターンある。
- 「ワイヤーフレーム」という言葉が一人歩きしている印象は受ける
- じゃぁ何?といった時と言った時に明確な言葉が帰ってこない。
- それ自体が設計図なのか、レイアウト指示書なのか。→でも設計図とレイアウト指示書は明確に違うということを意識しないといけない。
- レイアウト指示書はワイヤーフレーム完成後に発生するもの
- レイアウト指示書はデザイナーとコミュニケーションするもの
2009/09/18にワイヤーフレームコミュニケーション勉強会@大阪が行なわれました。
主催の3Sさんは、Twitter上でのワイヤーフレームコミュニケーション研究会のやりとりを見て、開催を思い立ったとのことです。何度かのやりとりを経て、実現となりました。
下記に3Sさんのブログに掲載された記事の転載をさせていただきます。
ワイヤーフレームコミュニケーション勉強会@大阪は2009/09/18に大阪で開かれた勉強会です。
そもそもの発端は2009/07/24に東京のSINAP様オフィスで株式会社エフエックスビイの原様が発起人となり開催されたワイヤーフレームコミュニケーション研究会の内容をふまえて、大阪でもワイヤーフレームコミュニケーションについて勉強しようという趣旨で開催しました。
この日は総勢11名の方があつまり、「ワイヤーフレームとはなにか?」をベースにフリーディズカッション形式で話し合いを行われました。
流れ自体は東京で行われたワイヤーフレームコミュニケーション研究会のトピックをベースでしたが、そもそもワイヤーフレームとはなにか?というトピックの部分での意見交換が非常に活発に行われ、参加者それぞれの考えているワイヤーフレームの認識の違いや、それに対する想い、現場でのワイヤーフレームを介した作用、問題点などを中心にディスカッションが行われました。
各人にそれぞれのトピックについてポストイットに記載して頂く事を当初は想定していましたが、ディスカッションを続けながらブレスト的に意見を出し合う結果になりました。それ自体は流れをとめるよりはよかったかなと感じています。また人数も少なかったので、face to faceのディカッションに向いている会になったと思います。
先に唯一ポストイットで回収した議事録を掲載いたしますが、現在参加者の話された内容をまとめていますので少々お待ち下さい!(現在約半分。残り鋭意書き起こし中)
ビジュアル
機能
- 見本
- 設計書
- 図的な要素分解ツール
- 概要
- ある意味ホワイトボード
- 見取り図
- 動的なものを静で表すもの
- 骨組み
- 自分にスケッチ(何回も)
- お客さんと話すもの
- モックアップ(HTML+CSS)
- クライアントから聞いた要望をラフに形にしたもの
- クライアントのイメージ作り
- レイアウト案
- デザイン要素の内ページ構成案
- コンテキストをUIに落とし込んだもの
- デザイナー&クライアントとのコミュニケーションツール
- デザイン作業前の情報ベースの画面構成案
- クライアントとの確認ツールの様なもの
- デザインを決める前にコンテンツの配置について考えるためのツール
- どんな素材が必要かはっきりさせる為のツール
- 画面要素の確認図
- 初期段階の設計図
- クライアントとデザイナーをつなぐビジュアルコミュニケーションツール
- 構造設計図
- コンテンツの確認図
- 基盤
- 情報を整理するもの
- 建築で例えると鉄骨的なもの
- デザイン前のデザイン
- 地図的なもの
Web制作におけるワイヤーフレームを使ったコミュニケーションについてあれこれ研究する会である「ワイヤーフレームコミュニケーション研究会」ですが、9月18日に大阪版が開催されることになりました。
twitterアカウントの3Sさんという方が発起人です。
大阪版の参加申し込みは次のリンクワイヤーフレームコミュニケーション勉強会@大阪より。
また、下記について意見募集をしているとのこと。参加できなくても記入しとくと皆で共有できるかもしれません。ATNDのほうのコメント欄にお気軽に書き込みをしてください。
『特にデザイナーさんにご意見を頂きたい部分で「ワイヤーフレームで理解しにくいところ、助けになるところは?」
またこの会の様子や話し合ったことなどもネット上で公開し、広く皆とシェアしていく予定です。
大阪の皆さん、もしよかったら告知協力よろしくお願いします!!!
第1回のワイヤーフレームコミュニケーション研究会にも参加いただいたbookslopeことネットイヤーの坂本さんが書いた感想が皆の参考になると思ったので取り上げます。
ワイヤーフレームコミュニケーション研究会 at bookslope blog
http://www.bookslope.jp/blog/2009/09/wireframecomwg.html
IAとして数多くの経験を持つ坂本さんが書いていることもあり、ワイヤーフレームで悪戦苦闘している人にずんと来る言葉が述べられています。特に
ただ、個人的に言えるのはどの状況においても共通して――
* ワイヤーフレーム作成の後工程をきちんと考慮すべき (誰が行い・どのように進めるのか)
これに尽きるかと思います。
という発言は同感です。ワイヤーフレームを作る人というのはディレクターだけでなく様々な人が作る場面があると思います。その思惑も様々ですが、ワイヤーフレームの後行程について考えていないケースはその後行程の人が苦労することになるのでしょう。
悩みの根本的なところはその後工程のことがわかっていないことに起因するように思います。もちろん後工程のことはわからなくて結構という意見もあるとは思いますが、結局のところ自分がやろうとしている方向性や実現性を担保するためには、実現する方法や手段を知識として身につけるということと、実現する人とのコミュニケーションが最も大事なことなのかも知れません。
会場でも話があったのですが、そもそもワイヤーフレームを作る目的というのが案件に応じて、人に応じて違ったりします。最終的なアウトプットはワイヤーフレームであっても、目的は企画用であったり、指示用であったり、ドキュメント用であったり、ビジュアルの骨組みだったりするわけです。
これら目的まで含めてワイヤーフレームの定義をそろえるのかどうかはいろいろ議論していきたいところですが、何に使うための物で、そこには何が含まれていなければいけないか、逆になにを含まなくてもいいのかを考える事で精度の高いワイヤーフレームの実現が出来そうです。
今回の会のタイトルの「デザイナーが引っ張られる〜」という点で考えてみれば、ワイヤーフレームに含まれている情報のとりちがいから発生しているケースがいくつかあったように感じます。
また、ブログでは下記の参考リンクがありました。これもチェックしておきたいですね。
ウェブサイトの設計図 ワイヤーフレームを活用しよう | DesignWalker
http://www.designwalker.com/2009/04/wireframe-2.html
第1回ワイヤーフレーム研究会のスライドを公開します。
下記リンクよりダウンロードください。
→第1回ワイヤーフレーム研究会のスライドをダウンロードする(PDF)