カンプがなくなったときのデザイナーの役割

手段を再想像する

昨年末に開催された CSS Nite Shift 5 で「Reimagination（再想像する） 」の話をしました。人とコンピュータの関わり方が行動や価値観を再定義しているのと同じように、Webサイト制作にしても同様のことがいえます。今までの当たり前を疑い、未来に柔軟に対応できるワークフローが必要とされています。

例えば従来必須だと言われていたワイヤーフレームも考慮対象です。少し前に ASCII へ「柔軟性あるデザインプロセスへ移行するためのヒント」という記事を寄稿しました。ワイヤーフレームが果たそうとしているコミュニケーションの目的は間違っていませんが、つくるためのツールや手法に問題があるのではないかという疑問を投げかけた記事。絶対いると思い込んでいるものも、今の時代にマッチしなくなってきているものは少なくありません。

また、Photoshop や Fireworks で作られたカンプと呼ばれる静止画像を作るのも、これからの Web デザインにおいて足かせになりつつあります。この話題は昨年何度もセミナーで取り上げていますし、プロトタイプの重要性を���り上げた講義やワークショップも行っています。

ひとつのプロトタイプを作るのではなく、目的に応じて最適なツールを選んで作ります。

カンプもワイヤーフレームと同様、コミュニケーションの目的は正しいのですが、ツールや手法に問題があります。例えば、カンプひとつにしても以下のような項目を暗に提示しています。

• レイアウト
• タイポグラフィ
• 色
• コンテンツのトーン＆マナー
• 情報の優先度
• 情報構造
• 操作性
• 感触
• 導線
• 他ページとの一貫性

カンプは Web サイト制作の初期段階に必須といわれていた時期もありましたが、初期段階に提示するにはあまりにも高度なコミュニケーションツールです。これだけたくさんのことを一度にクライアントに見せると、議論が定まらない可能性がありますし見過ごすこともあります。また、不特定要素が多い中、あたかも完成したかのような絵を見せることは、勘違いを生むリスクもあります。それを埋めるために書類や会議を増やすのも非効率です。

カンプが成し遂げようとしている「ビジュアルを作り、提示する」という目的は間違っているとは思っていません。むしろ初期段階に見せていることは正しいわけです。しかし、この目的のためにカンプという静止画を用いるのは今後ますますコスト高の要因になると考えています。

デザイナーがコードを書けなくても良い

静止画カンプの問題点は 2011年くらいから頻繁に書いています が、その回答が Web ブラウザ上でデザインすることなのかというと、そうでもないかなと思っています。

人が実際触れる媒体で、制約も踏まえたリアリティのある提案と、テストをしながらきめ細かくデザインを積み上げることが できるのが Web ブラウザ上でのデザインのメリットです。この手法は レスポンシブ Web デザイン には大変有効で、今後ますますフラグメンテーションが進むスクリーンサイズへの対応を考慮すると無視することはできません。

Web ブラウザ上でデザインすることで、静止画カンプで成し遂げようとしていた、「操作性」「感触」「導線」「情報の優先度」といった課題に取り組むことが容易になります。しかし、カンプが本来成し遂げようとしていた「ビジュアルを作り、提示する」という部分を Web ブラウザ上で解決できるのかというと���うとは言い切れません。

その要因としてクリエイティブのタイムラグが挙げられます。

Gumbyのようにデザイナーフレンドリーを売りにしたフレームワークもありますが、グラフィックツールの直感性と即時性にはかないません。

LiveReload をはじめとした便利なツールを使って、書いたコードの結果を即時に見れるようになりました。また、小さなツールを駆使することで複雑なビジュアルのコードをすぐに生成することも可能です。しかし、それでも思考のアウトプットに若干のラグが生じます。Photoshop や Fireworks のように思いついたことが、そのままの形ですぐに表示されるわけではありません。

コーディングにも試行錯誤があるように、ビジュアルにも試行錯誤があります。様々なビジュアルをトライアル＆エラーを繰り返すには、ブラウザ上でデザインというのはタイムラグが大き過ぎるわけです（0.1秒くらいだったとしてもまだ遅い）。Photoshop や Fireworks は、プロダクトを作るためのツールとしても優れていますが、ビジュアルの試行錯誤を容易に行える点も無視できないわけです。

小さなチームであればコーディングができるデザイナーがいても不思議ではないですし、私の周りにも両方できる人は少なくありません。しかし、Webデザインするにおいてコードが書けることが必須なのかというと私はそうは思っていません。それがたとえ Web ブラウザ上でデザインするワークフローになったとしてもです。

HTML/CSS フレームワークを活用することで、即時に Web ブラウザ上でデザインできるようになりました。これによって、静止画カンプ以外の方法で「ビジュアルを作り、提示する」という目的を達成する機会を得たことになります。

高まる Web デザイナーの役割

それでは従来の静止画カンプを作っていた Web デザイナーが今度するべきこと、考えていきたい課題は何でしょうか。以下の 4 点があります。

レイアウトだけがデザインではない

レイアウトを考え作るのは楽しいです。しかし、レイアウトから入ると柔軟性・汎用性のきかないデザインになる可能性が高まりますし、レイアウトよりもっと重要なビジュアルデザインの課題が後回しになることもあります。また、Web という性質上、コードが分かる人とのコミュニケーションをなしにレイアウトを作ることは困難です。

すぐにレイアウトが作れないことで、自分がデザインしていないと考えることはないですし、先に解決しなければならない課題は山ほどあります。

雰囲気が伝わるシステムを作る

スタイルガイドのインスピレーションになるGEL。

画面ではなく部品から始めてみよう という記事に書かれているとおり、ページという概念はまず捨てて、様々なデバイスでブランドイメージを維持するためのシステムを構築する作業が必要になります。ページ単位でひとつひとつデザインしているだけでは見えてこない全体像を形作る仕事です。

システムというと堅苦しいですが、言い換えればスタイルガイドを作ることを意味しています。例えば BBC では GEL: Global Experience Lanuage と称して、様々な媒体を通して利用するトーン＆マナーを制定しています。また、Web 版のほうではタイポグラフィや色だけでなく、BBC の Web サイトで利用する UI コンポーネントも紹介されています。

こうしたスタイルガイドをいきなり HTML/CSS で記述するのも手段ですが、コードが書けなくても出来る仕事です。

Photoshop や Fireworks は間を埋めるツール

Photoshop や Fireworks は、プロダクションにおいて『間』を埋めるツールになります。例えば、CSS では表現できない UI 要素や写真・グラフィックをつくるために Photoshop や Fireworks を使います。また、レイアウトを考える段階にはいった際に、コーディングの前の大まかなスケッチを Photoshop や Fireworks で行うこともあります。

紙に描いたスケッチがあれば、すぐにコーディングができる場合もありますが、単純なグリッドの世界にはまらないレイアウトや、グラフィックとの組み合わせで生まれる表現を模索するにはコーディング環境より Photoshop や Fireworks のほうが適しています。ただし、従来のように作り込まず、ある程度アイデアが固まった状態でコーディングに入って実際どんな見た目になるのかを確認したほうが良いでしょう。

混沌を受け入れる

途中段階のものをチームメンバーに見せたり、細かいパーツを即時に作ったり、ブラウザ上での表現を確認した上で調整を行ったり・・・などなど明確なワークフローに沿って順序良く進むという工程ではなくなる可能性があります。ひとりで黙々と作業する時間もありますが、今まで以上に別の職域の方とコミュニケーションをとる必要がでてきます。

早い段階で自分がつくったデザインがチームメンバーが活用することで、見えてくる課題もでてきます。また、多くの方はデザインに対してコメントもしてくるでしょう。様々な意見や見解を、そのまま聞き入れて作業するのではなく、ビジョンを共有するためのファシリテーションをデザイナーがしていくことになるでしょう。

デザイナーが基本の情報構造のスタイルガイドを作りはじめた段階で、CSS として継承。それを基に大まかな情報フローを作る間に、デザイナーはレイアウトのスケッチをはじめたり、スタイルガイドの充実化を進めます。もちろん、その間にフィードバックをするといったコミュニケーションも発生します。

もちろん、これはひとつの『理想』なので、そのまま適当できる場は少ないでしょう。しかし、今までのやり方は今後ますます通用しなくなることを考えると、今あるツールや手法を見直して、組み合わせや使い方を変えて模索する時期には来ていると思います。