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

Icon

Wireframe Communication Working Group

ワイヤーフレームと完成サイトの比較

前回に引き続き、ワイヤーフレームと完成サイトの比較みたいな記事をピックアップしてみます。

LEVEL STUDIOSという代理店で働く傍ら、個人事業主としてUXコンサルタントをしているAlexis氏のサイトにも制作したサイトとのワイヤーフレームが対で掲載されています。


Alexis Antonelli | User Experience Consulting | Activision.com

他にも

のプロジェクトの簡単な説明とワイヤーフレームなどがあります。

こういったワイヤーフレームもポートフォリオに掲載しているケースはあまりないので、もっと出てくるといいのになあと思いました。

掲載されているワイヤーフレームは、合番と共に詳細なコメントもついており、こういった補足説明のつけかたによっては混乱のないワイヤーフレームが実現できそうですね。

誰がどんなワイヤーフレームを作るのがいいのか?

Apt Mediaというアメリカメリーランド州にあるインタラクティブデザインのコンサルタント会社が、ワイヤーフレームの状態と完成したWebサイトを交互に挙げつつ、潜在的な落とし穴3つについて語った、

“Designers who wireframe: pros and cons”

というエントリーがあがっています。(1年近く前の記事ですが。でも公開時にかかわらず良い記事をいろいろ紹介していこうと思っています)

これによると、潜在的な落とし穴は、

  • デザインされ過ぎたワイヤーフレーム
  • 着色されたワイヤーフレームに似てしまう
  • ワイヤーフレーム作成とデザイン作業のスイッチング

だそうで、上記ポイントは、第1回目の研究会@東京でもあがったポイントでした。

様々な経験則から導き出された結論は、参考になるところが多いです。

Wireframe Guide

今日はワイヤーフレームのガイドラインに関するネタです。

シアトルにあるSchool of Visual Concepts という学校で行なわれているPRINT2WEBというクラスでJohn Rice氏が教えている内容がWebで公開されており、この中にワイヤーフレームガイドというページがあります。

ここでは、CS2用のデータやPDFをダウンロードすることが出来ます。
自分で使うためにワイヤーフレームの仕様を整理しているという人には参考になるかもしれません。

閑話休題:Wireframeといえば、、、

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が、『サイトマップ標準書式制定プロジェクト』というプロジェクトを発足しました。

WebSig247 サイトマップ標準化プロジェクト

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サイトのありかたを狭める可能性がある旨が指摘されていますが、そういったデメリットがあると同時に、仕様があることで標準書式を出力可能なツールを作りやすくなるというメリットも考えられます。

ワイヤーフレーム研究会も表記方法や記述メソッドに関する研究をつづけていく予定なので、大いに共感するところがあります。本研究会からもいずれは、皆が自由に使えるガイドラインのようなものを提示できたらと思います。

オンラインでワイヤーフレームを作るサービス「Cacoo」

ご無沙汰していますkara_dです。
第1回のワイヤーフレームコミュニケーション研究会以来すっかり間が空いてしまいましたが、また活動を再開していきたいと思います。

第2回目のワイヤーフレームコミュニケーション研究会@東京はワイヤーフレームに関するライトニングトークをする会にしたいと考えています。ライトニングトークというのは、5分ほどの時間でプレゼンテーションをする小さなセミナーのことで、だいたい1回に数人から十人程度の発表が行なわれます。

ワイヤーフレームはWebサイトの制作において決して主役ではありませんが、それぞれ様々なノウハウを持っていると思うので、ライトニングトークみたいな形式がピッタリだと思いました。(発表する人は会へ優先的に参加できるようにする予定です)

まだ細かな内容は決まっていないので、それまで国内外のワイヤーフレームに関する今の話題や過去のアーカイブなどをまとめてみるということをやってみます。

まずは、オンラインでワイヤーフレームを作ることもできるドローツールサービス「Cacoo」https://cacoo.com/を紹介します。

Cacooは、決してワイヤーフレームのためのツールというわけではなく、Visioなどで普段書いているような作図からUMLに至まで様々な図が書けるサービスです。おまけに、単に作図をするだけでなく、ユーザー同士でコラボレーションして作図したりといったソーシャル的な機能もついています。

もちろんワイヤーフレームも描くことが出来ます。適当に描いてみましたが、こんな図もすぐに作れます。

ワイヤーフレーム

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

パネル

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

テキストインスペクタ

小規模なプロジェクトでのメンバー同士のさくっとした情報共有にはピッタリなツールと思いました。

ワイヤーフレームコミュニケーション勉強会@大阪議事録その2

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

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

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


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

  • デザイナーにしてもらう為にしやすい配置を指示する為のものという意識が強い。
  • システム開発だと「外部設計書」と読んでいるもの
  • 用件定義を画面にのせる行程
  • サイト作成=画面にどう表すかということでワイヤーフレームと近い意図
  • 考え方はウェブアプリケーションを作成する行程と一緒
  • 3Dでの骨組み=ワイヤーフレーム
  • 動的なものを静的に表現する為のもの
  • メモ的なものを付箋使用し、貼りながらUIを考え、情報を整理する
  • ワイヤーフレームは考えを出しやすい、交換しやすい、コストが少ない、時間を少なく。
  • 他者とコミュニケーションする為のツール(プランニング用に、構造的にクライアントと確認できる)
  • 初期の段階でワイヤーフレームで問題を確認、最終的なゴールに向かう為に為にワイヤーフレームを使った方がよい。(上記がなければデザインはスタイルだけになってしまう)
  • カンプを示すというのとワイヤーフレームを作って画面に情報を落とす行程は後先という考えはない
  • デザイン力を示す為のカンプ(クオリティを示す)と設計は切り離して考える、最終的にはマージ
  • デザイン的に納得しなければ、クライアントは納得しない。
  • 画面を通したコミュニケーションには、インターフェイスを使用するものはワイヤーフレームを使用した設計はフェーズとして必要。
  • 考え方には2パターンある。
  • デザイン発からどの様な骨組み作って行ってどう設計するかというパターン
  • 設計発からどのような機能が重要なのかを考え、どうデザインに落とし込むかというパターンもちろん両方必要。
  • お客さんとやりとり、エンジニア、デザイナとの落とし込みどころのコミュニケーションとしてのワイヤーフレーム
  • 認識的な問題:制作側が「ワイヤーフレーム」と意識して使っているかという問題もある。
  • 肉付けしているものもワイヤーフレームと呼んだりする場合もあるし、ほんとに構造中身要素を中心に設計ているものをワイヤーフレームと呼ぶ場合もある。
  • 文字だけだとはワイヤーフレームではない。これだけだと目次的な要素だけ。
  • ワイヤーフレームを使ってどの時点(段階)でどの情報をどの画面で整理するのか。
  • ワイヤーフレームの認識の差は結構大きい。
  • ワイヤーフレームの定義っていうのがふわっとしていて分かりにくい。
  • フローチャート、動作案内設計図 = 機能的な説明
  • ビジュアル的なものは = どちらかというと内部資料
  • 手ラフ=デザイナーがオペレーターに指示をだすもの、クライアントにはみせない
  • 映像業界:コンテ・台本。 ビジュアルと文字(情報)は分割されている状態
  • 建築:設計図とイメージボード
  • 出版:つかみ本とイメージボード
  • いまでは情報とビジュアルを分けて提出していたのが、この「分ける」作業が失われてモックの様なものをクライアントに見せるという事になってしまった。→設計図なのか、イメージボードなのかよく分からない曖昧なものという定義が後から付加されてしまった。
  • 現在「ワイヤーフレーム」はこの曖昧なものが含まれてしまっているのではないか。
  • 絵コンテ=画面設計・・・多くの人間に画面に落とす上でどこに何を作るべきかの指示する上での設計書
  • 請負の場合、それをクライアントと共有しなければならない。
  • クライアントがどこなのか。
  • サイトの所有者に対してワイヤーフレームや仕様書が必要?
  • 所有者から請け負った人がクライアントに対してはワイヤーフレームや仕様書が必要。
  • 自分でワイヤーフレームを作って自分でデザインをする場合と、他者に頼む時がある。
  • 自分でデザインをする時でもデザインをしながら情報の配置を決めてしまうとややこしくなったり不具合がでたり、デザインに都合のよい様に変えてしまうので、
  • 最初にデザインとは完全に切り離して構成を決めて、自分で作ったり、人に頼んだりしているので情報のみを意識したレイアウト表として使用している
  • ワイヤーフレームは打ち合わせの為のもの。
    • 下絵、絵コンテみたいなもの。
    • 社内:色とか一切入れない。デザインの要素は一切いれない。
    • クライアント:もうこれデザイン案なんちゃうんくらいのクオリティのものを見せたりもする。
  • 脈略を伝える為のツール、優先順位をはっきりさせるもの
  • クライアントの意図、ディレクターの意図をくんでもらう為のツール
  • 意図を、何を継承してデザインしてほしいのかを汲み取ってもらうためのツール
  • Web業界に携わっている人は色々な業種(違う業種)から来た人が多い感じがする。
  • そのためコミュニケーションコストが非常にかかりやすい
  • ワイヤーフレームで効率的に、目的をはっきり、脈略をコミュニケーションではっきりとっていく。
  • ワイヤーフレームにはビジュアル要素は全くなく、ビジネスインパクトを出す為にどうすればいいのか、コミュニケーションエラーをなくす、そうすればコストがかからない。
  • ワイヤーフレームをだし、クライアントと話あうと抜けていたコンテンツが見つかったりするケースもある。
  • ストラクチャーで固めたつもりなのに、ユーザー的に分かりにくい導線があった場合には、それが分かるように変更しなければいけないという気づきが生まれる。→どのようにそのユーザーにアプローチして行けばいいかという指針(ラベリング等)や、コンテンツをストラクチャー上に追加したりできる。
  • クライアントとデザイナーとのコミュニケーションツール
  • ワイヤーフレーム自体は大体こういものですよねというふんわりした大まかな形で作っている。
  • クライアントには大まかなワイヤーフレームを提出して確認しているが、これにひっぱられないようにと制作側には釘はさす。
  • クライアントが考えている想いを重点的に伝えて、もし提示したワイヤーフレームではない形でよいワイヤーフレームが考えられるならば、それを制作サイドで進めてもらってもかまわないというスタンス。
  • ワイヤーフレームは画面フローを確認する上でクライアントと意思を疎通する上で非常に重要なツール。
  • 過去にクライアントによってワイヤーフレームを理解できないと思われる場合があり、制作サイドから提出しなかった事があった。
  • その場合、クライアントが画面遷移などのフロー自体が分からなくなり、トラブルになりかけた。
  • 結果としてやっぱりワイヤーフレームを提出して、同時に画面フローを確認しておくべきだった。
  • 案件の規模によって出さない場合もあるかもしれないが、画面でクリックできるもの(モックアップ等)をもっていったほうがいい。
  • ワイヤーフレームは画面にどう情報が落ちるかという事を確認するもの。これは書類として整理しやすい。
  • ユーザビリティ込みでこのワイヤーフレームでokかという確認をする場合は、最終的には動くものを持って行った方がいい。そうしないとひっくり返る場合もある。
  • この場には業種が結構違う人間が集まっているのでワイヤーフレームの定義がそれぞれ違う。
  • クライアントがワイヤーフレームを読めるか読めないかというスキル差の問題もある。
  • ウェブサイトでどれだけ収益性を求めているクライアントではしなければならない対応が違う。
  • クライアントと制作サイドがワイヤーフレームを使いながらサイトの構造についての問題点などつめていける場合には非常に効果的。
  • ワイヤーフレーム自体がそもそもサイト内の関係性を表すもの、画面にどう情報を載せるかというものを示したもの
  • フローチャート的なものはワイヤーフレームに含まれている
  • どの様に情報が移り変わるのかを意味表すのがワイヤーフレームでもある
  • 色んな書類の一部としてワイヤーフレームを使う場合と核の軸の部分としてワイヤーフレームを使う場合の2パターンある。
  • 「ワイヤーフレーム」という言葉が一人歩きしている印象は受ける
  • じゃぁ何?といった時と言った時に明確な言葉が帰ってこない。
  • それ自体が設計図なのか、レイアウト指示書なのか。→でも設計図とレイアウト指示書は明確に違うということを意識しないといけない。
  • レイアウト指示書はワイヤーフレーム完成後に発生するもの
  • レイアウト指示書はデザイナーとコミュニケーションするもの

ワイヤーフレームコミュニケーション勉強会@大阪レポート&議事録その1

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さんにいただきました

    第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回ワイヤーフレーム研究会のスライドを公開します。
    下記リンクよりダウンロードください。

    第1回ワイヤーフレーム研究会のスライドをダウンロードする(PDF)

    [議事録]コミュニケーションとしてのワイヤーフレームとドキュメントとしてのワイヤーフレームがある?

    ワイヤーフレームを成果物(納品物に入れている?)
    ワイヤーフレームは途中で破棄される
    仕様書と違って最新版に更新はされない
    ワイヤーフレームは仕様書としては扱わない
    ワイヤーフレームはバージョンアップさせていく
    ワイヤーフレームをブラッシュアップしたものがビジュアルに下りていく事はない
    ワイヤーフレームといっても様々な目的がある
    ビジュアルデザインのための利用
    コンテンツ仕様書としての利用
    インタラクションの検討材料として
    クライアントによって、ドキュメントとして使うかどうか決める
    建築系で例えると
    建築の図面はJIS的なもので決まっているがワイヤーフレームにはない
    ビルと建物で情報の粒度は違うかもしれないからワイヤーフレームでも案件によって記載内容は違ってくる
    SIer業界では画面設計図がある
    ただし、レイアウトがいらない点がワイヤーフレームと違う
    機能単位での記載なのでページ単位ではないことがある

    [議事録]デザイナーが引っ張られないワイヤーフレームを作るにはどんな工夫が考えられるか?

    マークアップ
    ワイヤーフレームからビジュアルデザインに行かずマークアップへ行く
    現在しない理由はそこまでスキルがないから
    字コンテを書く
    見出しは黒丸など、wiki記号で似せて作っている
    広告はラフなしのほうが喜ばれる
    エディトリアルはラフありのほうが喜ばれる
    H1とかの識別記号をしっかり書く
    色分けもしっかり意味付けする
    ワイヤーフレームすら書かない
    ワイヤーフレームを画像データにする
    色分けはグレーを使う
    ワイヤーフレームで要件を決めてはいけない?
    インターフェース設計としてのみ使う
    反論:場所取りつまりゾーニングをどこで解決するか
    反論:サイトの構成手順によって異なるかもしれないビジネス側から作成するのかUIの専門家が作成するのか
    ワイヤーフレームをデザイナーが切りなおす
    渡されたワイヤーフレームを最適なワイヤーフレームに書きなおして提出
    ただし、ワイヤーフレームを渡す時はすでに要件が決まっているときもあり
    ワイヤーフレーム単体で評価するのではなく、ちゃんとコミュニケーションがあるかどうかが重要
    フルFlashサイトではあまりワイヤーフレームを作らない
    IA、D、ADもそれぞれワイヤーフレーム作成に参加する(両方がぶつけ合うのが大事)
    ワイヤーフレームは、画面のレイアウトを規定するものではない
    AD、マークアッパー同士でワイヤーフレームを組む
    キャンペーン系コンテンツではDとADの関係が逆転することもあり
    レイアウト指示書として確実なものを渡す
    ただし、変わる可能性があるものは伝える
    ハイレベルのワイヤーフレームなのか、ローレベルの詳細ワイヤーフレームなのかはっきりさせる
    ワイヤーはちょっと足りないくらいにしておき、クリエイティブ魂をゆさぶるようにする

    [議事録]ワイヤーフレームの共通ガイドラインはあったほうがいいと思いますか?

    あるほうがいい
    現状、ワイヤーフレームは作る人によってばらばらすぎる
    なんらかの決まりが必要ではないか?
    ワイヤーフレームのせいでコミュニケーションが阻害されているとよくない
    ボキャブラリーとしての統一ならあり。リンクの書き方一つにしても決まりがあるとよい
    ワイヤーフレームがコミュニケーションロスの原因になっていることもある
    無い方がいい
    ワイヤーフレームは共通できない
    ワイヤーフレームっていう言葉の定義はあったほうがいい
    ないほうがいい
    Webの未来を閉ざす可能性がある。ディレクターが引っ張られることもある
    あるほうがいい
    基準があったほうがいい。案件や会社の方針によってはそれらを無視すればいい
    あったほうがいい
    目的による粒度が異なっていい
    案件のタイプに応じて、仕様書による情報の粒度が異なるケースもある
    あったほうがいい
    ワイヤーフレーム作成で見積りが出せるくらいまであったほうがいい
    あってもなくてもいい
    ワイヤーフレームの作り手にはメリットはあるのでは?
    ワイヤーフレームの基準はデザイナーに分かりづらいかもしれない
    ワイヤーフレームのガイドラインをデザイナーに求めるのは酷。ガイドラインが読めない可能性がある
    どうだろう?
    システムが絡む要件があったときにワイヤーフレームの基準があると便利
    あってもいい?
    ワイヤーフレームはアジャイル性がメリット
    ワイヤーフレームによるコミュニケーションの仕方は案件サイズによる

    [議事録]ワイヤーフレームにデザイナーが引っ張られてしまった経験は?

    • リンクの時、左にブレットがあると、そのままデザインに取り込まる
    • 画像と文字の比率がワイヤーフレームのまま
    • 細かく作ってしまったワイヤーフレームのエリア別の優先度強弱の色がそのままビジュアル的な濃淡になってしまった
    • 色がついた線は、ワイヤーフレームに慣れていない人はそのままの色でビジュアルに反映
    • 比率もレイアウトもワイヤーフレームと同じになってしまった
    • ワイヤーフレーム通りに作って欲しかったのに作られなかった
    • 一案目のデザインはワイヤーフレームベースで、ワイヤーフレームを崩したデザインをもう一案にすることがある

    [議事録]ワイヤーフレームって何ですか?アンケート結果

    • 紙のみで構成されたレイアウトのラフを含む平面図
    • ワイヤー(線)で構成を表現したもの
    • 作業、使用の要素を抽出してシンプルに表現したもの
    • 一言で言えばサイトの「見取り図」
    • Webページのどこにどんな情報をのせるか簡単に記したもの
    • ヒアリングで聞いたことをWebページで表現するとどうなる?と言う提案図
    • お客さんには”レイアウト案”と言っています。
      (内部的には)ページの幅や要素などの情報を共有するもの
    • サイトの完成系を共有するための設計資料・設計図
    • Webページの構成要素とそのレイアウトを簡易的に表したもの
    • クライアントとの意識合わせを行うために必要なドキュメントの一つ
      (画面要素、機能について)
    • 構成要素のざっくりとしたレイアウト、重みづけや機能を書き込んだ書類
    • 画面の情報
      レイアウトの情報
      • どういうボタン配置にするか、ナビゲーションの情報
      • 全体のレイアウトの情報
      • 迷わないようにするやつ
      • 情報の整理も
    • ページを構成する要素を線とテキストで表現しレイアウトしたもの。
    • 画面内の要素群を定義し、クライアント、ビジュアルデザイナー、エンジニア等と確認を進めるためのドキュメント、レイアウトを規定する場合とそうでない場合がある
    • ページ内に配置する要素の役割を確認するもの
      どういう要素がページ内にあって、どういう働きをするのかを関係者内で確認する為のもの
    • サイトの「なんとなくな形」を共有するもの
      要素とプライオリティを示すもの。洗い出すもの。
      たたき
      案件の規模やフェーズによって使い方が変わってくる。
    • 動線設計
      情報設計
    • ページの設計図(建築的思想で)
      概念の集約?
      土台
    • 1.画面要素の整理:大きさ、場所(グーテンベルグダイヤグラム)
      2.画面遷移の整理、チェック:ペーパープロトタイプとして。画面別の整理チェック。ナビゲーションのチェック
      3.以上の共有、コミュニケーションツール
    • 要素定義時のサイトの設計書
      開発時の原稿
      デザイナーへのレイアウト指示書
    • 紙やEXCELなどを使用し、特定のWebページ上に存在する要素を配置したもの。
    • 画面単位での設計図
      「含む」:要素、配置
      「含まない」:視覚表現
      他のものはケースバイケースで
    • プロジェクトに関わる人達の、共通のコミュニケーションツール。
      主に表示要素の重要度を定義するもの。
    • Webサイトのゾーニングを決めるもの
      デザインの土台となるもの
      要素を確定するもの(ほぼ)
      デザイン前にサイトの構造を共有するもの
    • ページ(コンテンツ)に必要な項目、要素と、重要度などを視覚化するもの。それを共有するもの。
      大まかなレイアウトを検討するもの。
    • 配置すべき情報を、可能なかぎり抽象化したもの。
      その、表現方法においての呼び名。
      (目的から呼ぶときのストラクチャ、と場合によっては同じ意味となる)
    • サイトの構造、構成を共有するもの?

    ミニトピック

    フリーのワイヤーフレームアプリケーション10選

    10 Completely Free Wireframe and Mockup Applicationsというエントリーにフリーのワイヤーフレーム作成ツールが10個掲載されています。

    告知事項

    現在、第2回ワイヤーフレームコミュニケーション研究会@東京を企画中です。

    内容はワイヤーフレームに関するLL(ライトニングトーク:一人5分程度の持ち時間でプレゼンをする)を中心とした会にしようと考えています。プレゼン内容は、ツールの話から事例紹介、独自に行なっている取り組みや考え方まで自由です。

    LLのプレゼンターは優先的に当日の参加権を持てますので、kazuhiroh{at}gmail.comまで【氏名(会社名)】【どんな方向性の話をしたいか】をお送りください。

    プレゼンの練習にもなりますのでお気軽にどうぞ!

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

    「デザイナーがひっぱられないワイヤーを素早く作る研究会をしたい」というTwitterでのポストから始まった会です。

    デザイナーはたまに提示されたワイヤーフレームに引っ張られてしまい、ワイヤーとあまり変わらないようなものをあげたりしてしまいます。

    そういうことを防ぐにはどうしたらいいか、そもそもワイヤーフレームの存在の是非も含めて考えつつ、ワイヤーフレームおより周辺の情報をピックアップしたり考察したりしていきます。

    運営者情報

    原 一浩 ( / mx / / kr )

    株式会社エフエックスビイ代表取締役CVO
    DesignWedge編集長