こんにちは、livedoor Blog 担当の飯田です。
ちょうど新機能のワイヤーフレームを描いている最中だったので、今回は正解があるようで無いディレクターのメイン業務の一つ、ワイヤーフレームについて自分なりにどう考えて作っているかを簡単にまとめてみました。
特にワイヤーフレームをこれから初めて作ってみるという人の参考になればと。
ウェブサイトを構成する要素・動作をまとめた資料になります。構成書・モック・スケルトン・青写真と呼び方は人それぞれです。
ということで、実際以下の感じでワイヤーフレームを作っていきます。
頭の中で考えていることをとにかく裏紙などを利用して紙に描いてみます。ワイヤーフレームと聞いてデジタルなイメージがありますが、こうした構想やアイデアベースの状態のときは、たくさん手を頭を動かして思いを出し切った方が整理がしやすくなります。
というのも、アプリケーション上で作業しようとすると図形のズレが気になってきたり、ビジュアル的にこだわり出してきたりと関係ない部分で気を取られることが多いので、あまりオススメしません。僕だけかもしれませんが。
MTG や合宿を利用してプロジェクトメンバーが集まって一気に描き上げることもありますが、ディレクターたるものあらかじめ出し切っておくのがベストです。
新機能追加の場合は状態の変化を遷移で表したりするので、データフロー図になることもあります。
便宜的に画面機能を補足を入れてみたり。
本来は先に考えておくべきかもしれませんが、構成を作ってると「この画面にユーザ情報を出すには別画面で入力させないと行けないかも」とどんどん思いつきます。なので別作業というよりは、構成を紙に描きながら同時に作って、最後に全体を俯瞰して画面に不足が無いか確認するために描いています。
オーソドックスなコーポレートサイトや静的サイトの場合は、ある程度アウトラインを固めてから各画面のワイヤーフレームを作っていった方が無駄なワイヤーフレーム作らなくて済んだりするので、コンテンツの性質を見たうえで、どちらから手を着けるかを考えてみましょう。
これから散らかった情報をまとめなければなりません。要素に抜け漏れが無いようにするのは大前提として、ワイヤーフレームを仕上げる前にいくつか気をつけているポイントがあります。
そう考えると、PowerPoint や Excel は環境を選ぶのでワイヤーフレームのフォーマットとしては厳しいのかもしれませんが、工夫次第 (メンバー間でコンセンサスをとるなど) でどうにかなると思います。でも、閲覧するのに逐一アプリケーション立ち上げるのも面倒ですねえ……。
# 受託サービスで開発過程で変更・修正があると、そもそも仕様の詰めが甘いのですが……。
エラー文言や画像テキストのデータも、一定のリファレンスからコピーできたほうがタイポによる差し戻しの可能性や、修正指示の手間も少なくなります。
ただ、全部デザイナーに丸投げして「設計意図を汲んでくれ！」というスタンスではなくて「ここは都道府県を選ばせたいからプルダウンで」や「ラジオボタンは label タグをつけたほうが選びやすい」のような細かい IA は、ディレクターがワイヤーフレームでフォローしてあげるようにしましょう。
結局のところ、ワイヤーフレームのは「コレだ！」というフォーマットがありません。
ワイヤーフレームは実際の開発に入る前にステークホルダー同士が意図を確認共有するためのツールなので、相手 (社内or社外) や状況 (納期が近い) によってカタチはさまざまです。
よく「三日前の自分は他人」と云います。三日前に作ったワイヤーフレームを三日後に見返してみて、2・3 度読み返さないと分からないような部分があれば、それはワイヤーフレームとして足りない部分があるということです。こうした足りない部分をなるべく作らないようにするのが、良いワイヤーフレームの近道だと思います。
そして先述の注意点を加味してあげれば皆が幸せになれるかもしれません。
たとえばライブドアでは、短時間で仕様をまとめて開発するケースが多いので、紙に描いたものがそのままワイヤーフレームになるケースがあります (あとでデジタル化して保存)。
さらに社内では Wiki をよく活用しているので、テキストデータは Wiki にまとめておいたりします。それでも足りない部分や不明点は IRC などで解決しながら進めていくことがほとんどです。自社ならではですね ;b
それはさておき、最近「ワイヤーフレームをマークアップしちゃおう」といった動きが活発のようです。僕も受託でウェブサイトを制作していたときは、ワイヤーフレームは全ページコーディングしていました。
第2回ワイヤーフレームコミュニケーション研究会@東京終了しました - ワイヤーフレームコミュニケーション研究会]
マークアップで表現する大きな理由は「ウェブサイトのワイヤーはウェブ (ブラウザ) で確認できるべき」というところにあると思います。たしかに PDF や PowerPoint で「ここをクリックしたら次のページへ (次のスライドへ)」みたいな記法よりは断然分かりやすいですよね。
それ以外にも、
ディレクターがコーディングという時点でかなりハードル高いですが、一度ベースが出来てしまえばあとの更新も楽になり、享受できるメリットが大きいのでコーディングが出来る人は結構オススメな手法です。ただ、作るまで時間が要すること・完全動的ページだと途端にハイレベルになるなど、まだマイナーな手法かなと思っています。Flash・Ajax のコンテンツだと多分合いません。
いくつかワイヤーフレームの作成を補助するツールがあるので、気になる方は検索してみて一度試してみるといいかもしれません。
ライブドアでは上手なワイヤーフレームが作れるディレクターを募集しています。
ちょうど新機能のワイヤーフレームを描いている最中だったので、今回は正解があるようで無いディレクターのメイン業務の一つ、ワイヤーフレームについて自分なりにどう考えて作っているかを簡単にまとめてみました。
特にワイヤーフレームをこれから初めて作ってみるという人の参考になればと。
ワイヤーフレームって？
ウェブサイトを構成する要素・動作をまとめた資料になります。構成書・モック・スケルトン・青写真と呼び方は人それぞれです。
ということで、実際以下の感じでワイヤーフレームを作っていきます。
とりあえず紙に描く
頭の中で考えていることをとにかく裏紙などを利用して紙に描いてみます。ワイヤーフレームと聞いてデジタルなイメージがありますが、こうした構想やアイデアベースの状態のときは、たくさん手を頭を動かして思いを出し切った方が整理がしやすくなります。
というのも、アプリケーション上で作業しようとすると図形のズレが気になってきたり、ビジュアル的にこだわり出してきたりと関係ない部分で気を取られることが多いので、あまりオススメしません。僕だけかもしれませんが。
MTG や合宿を利用してプロジェクトメンバーが集まって一気に描き上げることもありますが、ディレクターたるものあらかじめ出し切っておくのがベストです。
サイトストラクチャ (サイトマップ) を描く
新機能追加の場合は状態の変化を遷移で表したりするので、データフロー図になることもあります。
便宜的に画面機能を補足を入れてみたり。
本来は先に考えておくべきかもしれませんが、構成を作ってると「この画面にユーザ情報を出すには別画面で入力させないと行けないかも」とどんどん思いつきます。なので別作業というよりは、構成を紙に描きながら同時に作って、最後に全体を俯瞰して画面に不足が無いか確認するために描いています。
オーソドックスなコーポレートサイトや静的サイトの場合は、ある程度アウトラインを固めてから各画面のワイヤーフレームを作っていった方が無駄なワイヤーフレーム作らなくて済んだりするので、コンテンツの性質を見たうえで、どちらから手を着けるかを考えてみましょう。
ワイヤーフレームを仕上げる際の注意点
これから散らかった情報をまとめなければなりません。要素に抜け漏れが無いようにするのは大前提として、ワイヤーフレームを仕上げる前にいくつか気をつけているポイントがあります。
誰でも容易に閲覧できる
ワイヤーフレームは複数人で閲覧・共有するツールなので、自分だけしか閲覧できない (もしくは閲覧に OS 依存のアプリケーションが必要) なんてことは基本避けます。常に誰もが見ることができるフォーマットでワイヤーフレームを作成することを心がけましょう。そう考えると、PowerPoint や Excel は環境を選ぶのでワイヤーフレームのフォーマットとしては厳しいのかもしれませんが、工夫次第 (メンバー間でコンセンサスをとるなど) でどうにかなると思います。でも、閲覧するのに逐一アプリケーション立ち上げるのも面倒ですねえ……。
変更・修正が簡単にできる
ワイヤーフレーム仕上げた後も、開発の過程で変更や修正が入ることが良くあります。そういった場合にすぐに反映して、誰かがいつ見ても常に最新の状態であるようにしましょう。1 週間前に MTG して検討した内容が、ワイヤーフレームにまだ反映されてないという状態は良くありません。# 受託サービスで開発過程で変更・修正があると、そもそも仕様の詰めが甘いのですが……。
二次利用することができる
個人的にはデータを二次利用できるか・できないかがワイヤーフレームの善し悪しを分けると思います。エラー文言や画像テキストのデータも、一定のリファレンスからコピーできたほうがタイポによる差し戻しの可能性や、修正指示の手間も少なくなります。
デザイン・レイアウトを示す要素は極力省く
あくまでワイヤーフレームは画面を構成する要素・動きをまとめたものなので、ユーザーインターフェースや見た目は極力省き、デザイナーには余計な概念を捨ててもらってデザインをしてもらえるようにします。ただ、全部デザイナーに丸投げして「設計意図を汲んでくれ！」というスタンスではなくて「ここは都道府県を選ばせたいからプルダウンで」や「ラジオボタンは label タグをつけたほうが選びやすい」のような細かい IA は、ディレクターがワイヤーフレームでフォローしてあげるようにしましょう。
結局どうするのがいいの？
結局のところ、ワイヤーフレームのは「コレだ！」というフォーマットがありません。
ワイヤーフレームは実際の開発に入る前にステークホルダー同士が意図を確認共有するためのツールなので、相手 (社内or社外) や状況 (納期が近い) によってカタチはさまざまです。
よく「三日前の自分は他人」と云います。三日前に作ったワイヤーフレームを三日後に見返してみて、2・3 度読み返さないと分からないような部分があれば、それはワイヤーフレームとして足りない部分があるということです。こうした足りない部分をなるべく作らないようにするのが、良いワイヤーフレームの近道だと思います。
そして先述の注意点を加味してあげれば皆が幸せになれるかもしれません。
たとえばライブドアでは、短時間で仕様をまとめて開発するケースが多いので、紙に描いたものがそのままワイヤーフレームになるケースがあります (あとでデジタル化して保存)。
さらに社内では Wiki をよく活用しているので、テキストデータは Wiki にまとめておいたりします。それでも足りない部分や不明点は IRC などで解決しながら進めていくことがほとんどです。自社ならではですね ;b
余談
それはさておき、最近「ワイヤーフレームをマークアップしちゃおう」といった動きが活発のようです。僕も受託でウェブサイトを制作していたときは、ワイヤーフレームは全ページコーディングしていました。
第2回ワイヤーフレームコミュニケーション研究会@東京終了しました - ワイヤーフレームコミュニケーション研究会]
マークアップで表現する大きな理由は「ウェブサイトのワイヤーはウェブ (ブラウザ) で確認できるべき」というところにあると思います。たしかに PDF や PowerPoint で「ここをクリックしたら次のページへ (次のスライドへ)」みたいな記法よりは断然分かりやすいですよね。
それ以外にも、
- 環境 (OS・ブラウザ) を選ばない
- ローカルに落とせばオフラインでも見られる
- HTML なので変更・修正も容易
- A タグで実際のページ遷移をブラウザ上で体験させることができる
ディレクターがコーディングという時点でかなりハードル高いですが、一度ベースが出来てしまえばあとの更新も楽になり、享受できるメリットが大きいのでコーディングが出来る人は結構オススメな手法です。ただ、作るまで時間が要すること・完全動的ページだと途端にハイレベルになるなど、まだマイナーな手法かなと思っています。Flash・Ajax のコンテンツだと多分合いません。
いくつかワイヤーフレームの作成を補助するツールがあるので、気になる方は検索してみて一度試してみるといいかもしれません。
ライブドアでは上手なワイヤーフレームが作れるディレクターを募集しています。
コメント