以下はパワポでワイアフレームを作ることを正当化しようという試みである。ただし実際には、関係各者のあいだで特に問題ないならワイアフレームはパワポだろうがFireworksだろうが、台紙にワリバシ貼ろうが、どういう作り方でも構わないと思っている。何が正しいとかいうことはなく、どういう流れでディレクションしているかによって適・不適があるだけだ。
ちなみに、前回の記事で
さて、というわけで私はパワポでワイアフレームを作っている。他にワイアフレームを作る上で考えられるのがエクセル、画像、PDFだろうか。
考えてみるに、ワイアフレームの役割は二つある。
・クライアントや上司などの意思決定権者に「どういうページ構成になるか」を理解してもらう
・デザイナーに「どういうページ構成になるか」を理解してもらう
前者についてはおおまかであれカンプの段階からスタートする手もあるが、初回提出までに掛かる時間や出し戻しなど考えるとやや難がある。また、それを見る相手によってはカンプからスタートだと「UIとしてのデザイン」「装飾としてのデザイン」がごっちゃになってしまうこともある。まずはページ内の構成要素やその配置、導線の作りなどなど、UI的な部分から詰めた方がいいような気がする。
また私の場合はワイアフレームの脇に注釈を付ける作り方をしている。なので、画像で作るとなると上下なり左右なりに注釈を書き込むスペースを設ける必要が出てくる。
受け取る側にしても、画像なりPDFで受け取った場合、赤字を入れるのにひと手間必要になる。パワポで出してくれれば、開いてそこへダイレクトに赤字を入れることができる。文字修正も楽だ。これはエクセルでもいいのだが、エクセルの場合、パッと身でどこまでが1ページなのか把握しにくく、コメント入れたりすると例えば印刷などしたいときに再設定が必要だったりと、やや煩雑である。受け取ったものを刷り出して、手書きでコメント入れてFAXで戻すという人には関係ないことだが。
コメント戻しを受け取る側としても、画像なんかで出すと人によっては赤字に相当するものを別途、全部テキストで書いてくれたりして、それを照らし合わせつつ読む、あるいは参照箇所の行き違いなど、とかく面倒だ。
画像などで作る場合のメリットは以下だろうか。
・実物大でサイズなどキメ撃ちで作れる
・パワポでは小さくてゴチャつくレイアウトでもすっきり組める
「実物大で～」というのはデザイナーが参照する際に便利そうだが、実際に色を乗せたり形を作ったり、あるいは提供された画像やテキストを流し込んでみると収まりが悪いことも往々にしてあるので、結局「実物大」でキメ撃ちするメリットが失われてしまうこともある。
「ゴチャつくレイアウト～」についてだが、あくまで個人的にだが、パワポの1ページに入らないレイアウトというのはそもそも1ページの情報量として詰め込みすぎなんじゃないかと思う。また、リストなんかはワイアフレームのときは全部入れるのではなく、適宜省略して注釈に「実際にはコレコレが入る」のように書けばいいわけだし。
話が前後するが、ワイアフレームを画像で作って、注釈が必要なときはパワポに貼り込むという方法もある。しかし、これだと画質もアレだし、受け取る側はやはり赤入れ時に直接編集できない場合が出てくる。また、それに基づいて修正するときにまた画像で作った修正版をパワポに貼り込んで提出、という作業が出てきて、これもこれで地味に煩雑だ。
デザイナーにFIXしたワイアフレームを渡す際も、例えばデザイナー向けの注釈をつけるのにパワポは楽だし、必要なくてもちゃんと作ってあればクライアントなり上司なりに出したワイアフレームのパワポファイルをそのまま渡せば充分なことだって多い。それがサイト仕様書も兼ねていれば、直接は必要なくてもデザイナーに対してサイト構成やその他の情報が参考になることもあるだろう。
あとまあ、画像よりたいていファイルサイズが軽量だしね。ページ数が多いと如実に違ってくる。
赤入れ時に直接編集できるというのは、ともすればどこを編集したかパッと見で分からない場合があるので、それが難点といえば難点だが、補って余りあるメリットを持っていると思う。
というわけで、諸事情により急いで書いたので漏れもあるだろうけれど、言いたいこととしてはそんな感じ。
とはいえ、冒頭にも書いたけれどその正しさや他の手段に対する優位を主張しているわけではない。なんなら版木を彫って作ったって、それでスムーズに行くなら一向に構わないのである。
あと、こうやってブログに書くのでもなければ、ワイアフレームをパワポで作る意義なんて考えるのは瑣末なことでもある。
ちなみに、前回の記事で
と書いたけれど、特にそんなことはなかった。ワイアフレームについて考えたことを書こうと思っていたのだけれど、その前段階を一部兼ねて別の話を。
さて、というわけで私はパワポでワイアフレームを作っている。他にワイアフレームを作る上で考えられるのがエクセル、画像、PDFだろうか。
考えてみるに、ワイアフレームの役割は二つある。
・クライアントや上司などの意思決定権者に「どういうページ構成になるか」を理解してもらう
・デザイナーに「どういうページ構成になるか」を理解してもらう
前者についてはおおまかであれカンプの段階からスタートする手もあるが、初回提出までに掛かる時間や出し戻しなど考えるとやや難がある。また、それを見る相手によってはカンプからスタートだと「UIとしてのデザイン」「装飾としてのデザイン」がごっちゃになってしまうこともある。まずはページ内の構成要素やその配置、導線の作りなどなど、UI的な部分から詰めた方がいいような気がする。
また私の場合はワイアフレームの脇に注釈を付ける作り方をしている。なので、画像で作るとなると上下なり左右なりに注釈を書き込むスペースを設ける必要が出てくる。
受け取る側にしても、画像なりPDFで受け取った場合、赤字を入れるのにひと手間必要になる。パワポで出してくれれば、開いてそこへダイレクトに赤字を入れることができる。文字修正も楽だ。これはエクセルでもいいのだが、エクセルの場合、パッと身でどこまでが1ページなのか把握しにくく、コメント入れたりすると例えば印刷などしたいときに再設定が必要だったりと、やや煩雑である。受け取ったものを刷り出して、手書きでコメント入れてFAXで戻すという人には関係ないことだが。
コメント戻しを受け取る側としても、画像なんかで出すと人によっては赤字に相当するものを別途、全部テキストで書いてくれたりして、それを照らし合わせつつ読む、あるいは参照箇所の行き違いなど、とかく面倒だ。
画像などで作る場合のメリットは以下だろうか。
・実物大でサイズなどキメ撃ちで作れる
・パワポでは小さくてゴチャつくレイアウトでもすっきり組める
「実物大で～」というのはデザイナーが参照する際に便利そうだが、実際に色を乗せたり形を作ったり、あるいは提供された画像やテキストを流し込んでみると収まりが悪いことも往々にしてあるので、結局「実物大」でキメ撃ちするメリットが失われてしまうこともある。
「ゴチャつくレイアウト～」についてだが、あくまで個人的にだが、パワポの1ページに入らないレイアウトというのはそもそも1ページの情報量として詰め込みすぎなんじゃないかと思う。また、リストなんかはワイアフレームのときは全部入れるのではなく、適宜省略して注釈に「実際にはコレコレが入る」のように書けばいいわけだし。
話が前後するが、ワイアフレームを画像で作って、注釈が必要なときはパワポに貼り込むという方法もある。しかし、これだと画質もアレだし、受け取る側はやはり赤入れ時に直接編集できない場合が出てくる。また、それに基づいて修正するときにまた画像で作った修正版をパワポに貼り込んで提出、という作業が出てきて、これもこれで地味に煩雑だ。
デザイナーにFIXしたワイアフレームを渡す際も、例えばデザイナー向けの注釈をつけるのにパワポは楽だし、必要なくてもちゃんと作ってあればクライアントなり上司なりに出したワイアフレームのパワポファイルをそのまま渡せば充分なことだって多い。それがサイト仕様書も兼ねていれば、直接は必要なくてもデザイナーに対してサイト構成やその他の情報が参考になることもあるだろう。
あとまあ、画像よりたいていファイルサイズが軽量だしね。ページ数が多いと如実に違ってくる。
赤入れ時に直接編集できるというのは、ともすればどこを編集したかパッと見で分からない場合があるので、それが難点といえば難点だが、補って余りあるメリットを持っていると思う。
というわけで、諸事情により急いで書いたので漏れもあるだろうけれど、言いたいこととしてはそんな感じ。
とはいえ、冒頭にも書いたけれどその正しさや他の手段に対する優位を主張しているわけではない。なんなら版木を彫って作ったって、それでスムーズに行くなら一向に構わないのである。
あと、こうやってブログに書くのでもなければ、ワイアフレームをパワポで作る意義なんて考えるのは瑣末なことでもある。
ワイアフレームについて考えたことを書こうと思っていたのだけれど、その前段階を一部兼ねて別の話を。
ただのウェブデザイナーで終わらないため身に付けておきたい事
という記事を読んだ。論旨としては「デザイン＋αを身に付ける」というのが「ただのデザイナーで終わらない武器」であるという結論で、実際にはどういうことか?ということを書いている。箇条書きにすると
・コスト計算がしっかりできる
・しっかりとデザインの説明ができる
・作るを仕事としない
だそうな。
ところ変われば…で、このブログでもさんざん書いているけれど、内部制作なのか受託なのか、どういう人員構成なのか、どういう立場から見ているのか、などなど事情によって様相が一変するので、上記の話があてはまるケースもある。
けれど事情が変わればあてはまらない話になる。というわけで、上記記事ではどういう事情(状態)を想定して書かれたものか知らないけれど、「受託案件中心のチームでデザイナーとは別にディレクターがいる」という状態を想定して、そのディレクターの立場から(といっても私の主観だが)書いてみたい。何を? さあ? 何か。
1:そもそも論
デザイナーが「ただのデザイナーで終わりたくない」と思うのは自由で、好きにやって欲しい。向上心があって素晴らしいことだと思う。ただ、上記記事では
が、そうとも言えない。たとえば、すでに営業やら他の経緯での案件受注が主な流れになっている場合、ディレクターはその全体量を把握したうえで作業負荷をやりくりし、各クライアントに対して納期の話をしていたりする。
そんなときにイレギュラーにデザイナーが勝手に案件を取ってきてくれても「ありがたいけど…」ってな感じだったりする。引き合いが来た段階で事前に相談してくれるなら大変ありがたいけれど。
そもそもデザイナーを採用しようというときはデザインする人が欲しいのであって、案件が取ってこれる人が欲しいわけではない。「取ってこれる」という場合も豊富な人脈などであまり労せずして取れるならいいけど、それなりの営業活動が出来るって意味なら「そんなことより今は目の前のデザインに集中してください」という気持ちになることもあるだろう。
繰り返すがデザイナーを採用するってときはデザインする人の手が足りないのであって。
すでに居るデザイナーが案件取れるようになろうと思ってくれるのも大変ありがたいこと。だけど、やっぱりそれはデザインの仕事に影響ない範囲で、ということを忘れないで欲しい。もしクライアントなり案件なりを何らかのつながりで紹介できそうなら、自分で取りに行くのではなく営業担当者を先方へ紹介してやって欲しい。
とまあ、案件取る取らないに限らず、＋αを身に付けるならデザイナーは目先の仕事に影響ない形でやって欲しい。言うまでもないことだけど、デザイナーにこちらが求めているのはまずデザインできることであって、それ以外は「おまけ」みたいなもの。仮にプログラミングを身に付けてくれたとしても、案件にプログラマーとしてがっつりアサインしたりはしない。プログラミングしている際に他の案件が差込で入ったときに、デザインの工程が止まっても困るし、プログラミングの工程が止まっても困るし。他のデザイナーに振れるならいいけど。それはそれで本末転倒な気もする。
というわけで、ディレクターからすると無理に「デザイン＋αを身に付け」て欲しいと思っているわけではない。私だけかもしれないが。ともあれこれがまあ、今回で一番言いたかったこと。
2:コスト計算
オウフ。既に長くなってるな。まあいいか。「デザイン＋α」の中身として挙がっているのだが、
「これ、どれくらいでできそう？」→「わかりません」とか「いついつまでにできそう？」→「わかりません」ってことだ。これはさすがにお話にならないだろう。いや、事情にもよるか。たとえば複数のラインを掛け持ちしてて、他のラインからの仕事が微妙にどうなるか読めないときとか。ただ、そういう特段の事情がない限りは上のような事はできて当然だろう。…要求水準が高いとは思わないが。
3：デザインの説明
むしろ困るのはロジックで説明できないより何より、自分のデザイン、もしくは感覚やロジックに固執して聞き入れてくれない人。言われるままハイハイと従ってくれる必要はないのだけれど、それならそれで「クライアントを説得できる」もしくは「先方の要望と自分のやりたいことを上手く摺り合わせて昇華する」くらいはして欲しい。それができず闇雲に自分のデザインなり説なりをかたくなに繰り返されるのが一番困る。
4:作る仕事
とまあそんなわけで、「そもそも論」からして引用元の記事とは全然違う主張になっている。にしても、上記記事が説いている内容ってあまりにも初歩的で、身に付けたところで「ただのウェブデザイナーで終わらないため」にはならない気がする。それともそれって私のワガママであって、不当に要求水準が高いのかな…。まさかなあ。
ただのウェブデザイナーで終わらないため身に付けておきたい事
という記事を読んだ。論旨としては「デザイン＋αを身に付ける」というのが「ただのデザイナーで終わらない武器」であるという結論で、実際にはどういうことか?ということを書いている。箇条書きにすると
・コスト計算がしっかりできる
・しっかりとデザインの説明ができる
・作るを仕事としない
だそうな。
ところ変われば…で、このブログでもさんざん書いているけれど、内部制作なのか受託なのか、どういう人員構成なのか、どういう立場から見ているのか、などなど事情によって様相が一変するので、上記の話があてはまるケースもある。
けれど事情が変わればあてはまらない話になる。というわけで、上記記事ではどういう事情(状態)を想定して書かれたものか知らないけれど、「受託案件中心のチームでデザイナーとは別にディレクターがいる」という状態を想定して、そのディレクターの立場から(といっても私の主観だが)書いてみたい。何を? さあ? 何か。
1:そもそも論
デザイナーが「ただのデザイナーで終わりたくない」と思うのは自由で、好きにやって欲しい。向上心があって素晴らしいことだと思う。ただ、上記記事では
というのが「デザイン＋αを身に付ける事が重要」な例(理由なんじゃないかと思う)として挙げている。例えば、デザインだけができる人と、自ら案件を取ってきて、自分でデザインが出来る人、どちらを採用しますか？と聞かれて、誰しも後者と答えるはずです。
が、そうとも言えない。たとえば、すでに営業やら他の経緯での案件受注が主な流れになっている場合、ディレクターはその全体量を把握したうえで作業負荷をやりくりし、各クライアントに対して納期の話をしていたりする。
そんなときにイレギュラーにデザイナーが勝手に案件を取ってきてくれても「ありがたいけど…」ってな感じだったりする。引き合いが来た段階で事前に相談してくれるなら大変ありがたいけれど。
そもそもデザイナーを採用しようというときはデザインする人が欲しいのであって、案件が取ってこれる人が欲しいわけではない。「取ってこれる」という場合も豊富な人脈などであまり労せずして取れるならいいけど、それなりの営業活動が出来るって意味なら「そんなことより今は目の前のデザインに集中してください」という気持ちになることもあるだろう。
繰り返すがデザイナーを採用するってときはデザインする人の手が足りないのであって。
すでに居るデザイナーが案件取れるようになろうと思ってくれるのも大変ありがたいこと。だけど、やっぱりそれはデザインの仕事に影響ない範囲で、ということを忘れないで欲しい。もしクライアントなり案件なりを何らかのつながりで紹介できそうなら、自分で取りに行くのではなく営業担当者を先方へ紹介してやって欲しい。
とまあ、案件取る取らないに限らず、＋αを身に付けるならデザイナーは目先の仕事に影響ない形でやって欲しい。言うまでもないことだけど、デザイナーにこちらが求めているのはまずデザインできることであって、それ以外は「おまけ」みたいなもの。仮にプログラミングを身に付けてくれたとしても、案件にプログラマーとしてがっつりアサインしたりはしない。プログラミングしている際に他の案件が差込で入ったときに、デザインの工程が止まっても困るし、プログラミングの工程が止まっても困るし。他のデザイナーに振れるならいいけど。それはそれで本末転倒な気もする。
というわけで、ディレクターからすると無理に「デザイン＋αを身に付け」て欲しいと思っているわけではない。私だけかもしれないが。ともあれこれがまあ、今回で一番言いたかったこと。
2:コスト計算
オウフ。既に長くなってるな。まあいいか。「デザイン＋α」の中身として挙がっているのだが、
ってのはデザイナーが無理に判断しなくってもいい。アートディレクターだとか、デザイナーがディレクターを兼ねてるならともかく、他にディレクターが居れば、そいつが考えるべき。まあ、考えてくれてもいいけど、ディレクターだってその辺は勘案した上でそのデザイナーに「これこれをいつまでにして欲しい」とか相談しているわけであって。○○万円の案件だから、下請けなのか、直接なのか、それによって会社に入ってくるのはいくらになり、そこから諸々の販管費などを差し引いた場合、使える時間はどれくらいか。
この記事書いた人がどんな職域なのか知らないけれど、もしディレクターなら自分で納期を決めれる方はとてもやりやすいです。
「これ納期いつまでっすか？」なんて聞くデザイナーは失格ですね。
とか書くのはそれこそディレクター失格である。納期がいつまでか聞く聞かないなどという瑣末なことで合格も失格もクソもない。聞かれれば言えばいいし、聞かれなくても伝えればいい。それだけだ。記事の執筆者がディレクターじゃないならまあ私にはとやかく言えないけど。あと、納期が決まってる場合も多いので、求められてるならともかく、自分で勝手に納期決められても困る。「これ納期いつまでっすか？」なんて聞くデザイナーは失格ですね。
→最高じゃない。いや、できて欲しいんだが、できても普通って言うか。だって逆にこれができないってことは「計算したところ、○日がかけれる最大日数だと思いますので、○日にラフ案、○日に戻しで○日FIXでいきます。」みたいなデザイナーはディレクターからしてみれば最高じゃないでしょうか。
「これ、どれくらいでできそう？」→「わかりません」とか「いついつまでにできそう？」→「わかりません」ってことだ。これはさすがにお話にならないだろう。いや、事情にもよるか。たとえば複数のラインを掛け持ちしてて、他のラインからの仕事が微妙にどうなるか読めないときとか。ただ、そういう特段の事情がない限りは上のような事はできて当然だろう。…要求水準が高いとは思わないが。
3：デザインの説明
とのこと。自分はデザインを大きく「UI」「装飾」の二つに分けていて、「UI」でそれは確かにやや困る。ただデザイナーがそういう理由でデザインしたものでも、ロジックから考えて特に問題なくクライアントに説明できそうならそれでもいい。「装飾」についてはこれはもう上記記事にも書いてあるけど好みの問題も大きく、自分の経験ではいくらロジックで説明可能でもクライアントの好みに合致しないとダメだったりというのが往々にしてある。なんでこうなってるの？と聞かれて、だってキレイじゃないですか！というのは卒業しましょう。
むしろ困るのはロジックで説明できないより何より、自分のデザイン、もしくは感覚やロジックに固執して聞き入れてくれない人。言われるままハイハイと従ってくれる必要はないのだけれど、それならそれで「クライアントを説得できる」もしくは「先方の要望と自分のやりたいことを上手く摺り合わせて昇華する」くらいはして欲しい。それができず闇雲に自分のデザインなり説なりをかたくなに繰り返されるのが一番困る。
4:作る仕事
これはまあ、そうなんだけれど、これも＋αになり得るかというと微妙。最低限の認識じゃないかと思う。ディレクターとしては成果を挙げる手助けになるよう、役立ちそうな情報があればデザイナーに伝える感じ。デザイナーの仕事はデザインをする事。と思っている人がいますが、大きな間違いです。
アーティースト、趣味、個人的嗜好などでやっているのであればそれで問題ありませんが、クライアントがいる以上、デザイナーの仕事は効果のあるデザインをする事です。
つまり、成果をあげる。
そのためのデザインをする。という認識を持つことですね。
とまあそんなわけで、「そもそも論」からして引用元の記事とは全然違う主張になっている。にしても、上記記事が説いている内容ってあまりにも初歩的で、身に付けたところで「ただのウェブデザイナーで終わらないため」にはならない気がする。それともそれって私のワガママであって、不当に要求水準が高いのかな…。まさかなあ。
| ホーム |
Calendar
新着情報
