これからのUIデザインのために、デザインカンプをやめてプロトタイプを作ろう（後編）
UIデザインの新しいワークフローを作るために長谷川恭久さんとの共同プロジェクトとしてスタートした“Patch Project”。導入部分として長谷川さんにお話頂いたワークフローの提案について「これからのUIデザインのために、デザインカンプをやめてプロトタイプを作ろう（前編）」として記事にしました。後編となる今回は、デザイナーがするべき雰囲気のデザイン、また具体的なワークフローについての話をまとめていきます。
目次
ルック＆フィールを考える
photo credit: Crossett Library Bennington College via photopin cc
ではHTMLプロトタイプを作っている間にデザイナーがするべきことは何なのか。それは雰囲気をデザインすること。レイアウト以外のデザイン、色やタイポグラフィ、写真や動画について考えていくのです。
具体的に言うと、スタイルガイドを作ること。今後どういった方向性でデザインをしていくのか決めていく作業です。カンプだと全体の秩序をどう保つか、ということまで頭が回りにくい。その結果、タイポグラフィや大きさが違っていたり、ページごとの一貫性がなかったりするんですよね。だからこの段階でデザイナーは全体の視覚言語を作ることに集中するべき。イメージに合ったタイポグラフィを探すだけでも大きな仕事ですからね。
ボタンやヘッダー、ボックスやリスト、写真、本文などパーツごとに考えて、ブランドにマッチした雰囲気はどういったものなのか、ということを検討していきます。これによってレイアウトから離れてブランディングについて考えることが出来ますし、全ページの見た目の統一を計ることもできます。あとから追加でページを作っても、スタイルガイドを参照すればブレることはありませんよね。
ただやはりある程度のWebの技術の知識は必要ですし、どれくらいフォーカスするかが鍵になってきます。プロトタイプの段階で全部作ると大変ですから、ディレクターやクライアントと話してどこまで作るか絞る必要があるでしょう。
使えるツールとしてはPinterestが便利ですよ。キーワードからユーザーがイメージするものが一覧で確認できます。例えばガーリーで検索してみると、ハートやピンクなどのイメージが並んでいます。これだと手軽にクライアントに見せられますし、ユーザーはこういうガーリーを求めている、と擦り合わせができるわけです。
想定 → 仮説 → プロトタイプ → 測定・評価
ユーザーの行動にヒントがある
photo credit: larskflem via photopin cc
今度は全体のワークフローについて見ていきましょう。まずは想定で、クライアントがどんな問題を抱えているのかを聞き、またユーザーが何を求めて何を必要としているかを考えていきます。利用者が使っているときの動きや行動にヒントがある。ユーザーテストやインタビューで意見を聞いても、それがマジョリティとは限らないし、その人がただ欲しいだけかもしれませんよね。だからユーザーが使っている様子をとにかく見るわけです。あとはアクセス解析も有効ですね。全てが数値化されているわけですから、そこを読み取っていく。
ユーザーの感情をマッピングする
その次が仮説です。ユーザーの行動やアクセス解析などを掛け合わせた上で仮説を立て、プロトタイプを作るための「設計図」を作っていきます。利用者が使う前から使った後までのタイムラインを作って、そこに細かく書き込んでいく。期待や前提、起動から使用中、終了とその後の反響までを実際に何が置きているかを図式化するんです。ユーザーの反応をポジティブ、ニュートラル、ネガティブに分けて感情のマッピングしていく。これで利用者視点での課題を洗い出し、それを見ながらネガティブをポジティブにするのが優先なのか、ポジティブな反応をもっと良くしていく方がいいのかを考えていきましょう。
例えばInstagramで考えてみましょうか。ユーザーは「写真が撮りたい」という期待を持ってアプリを立ち上げますが、最初に出るのは撮影画面ではなく、Instagramで撮られた写真です。「アプリを起動してからカメラで写真を撮るまでに時間が掛かる」と考えればネガティブですが、「撮るためのインスピレーションが得られる」という意味ではポジティブですよね。そういうことを全部タイムライン化して、何が起きているかを細かく見ていく。そうするとUIの改善提案がしやすくなるのではないでしょうか。
ディティールではなく、フローにフォーカスしてプロトタイプを作る
photo credit: IntelFreePress via photopin cc
ネガティブをポジティブにするために、実際にユーザーがどう使うかを見るために、今度はプロトタイプを作ります。仮説をいかに視覚かするか意見を出し合って、そこから決まったことを作っていく。こういうプロトタイプを作るんだ、っていうことをみんなで明確にしましょう。作品ではなくあくまでプロトタイプなので、可読性があればいいんです。完成度は求めなくていいし、伝わればいい。ここでディティールにこだわってしまうとどんどん時間が掛かっていく。ここではディティールより、フローにフォーカスします。
批判ではなく批評をする
photo credit: Peter Alfred Hess via photopin cc
出来上がったものを今度は評価する段階です。気を付けて欲しいのは、「〜に変えてください」「〜の方が良いです」「〜にしてください」と批判しないこと。批判と批評は違います。アイディアをジャンプさせるための土台になるのが批評。必要なのは批判ではなく批評です。だから「なぜ」を尋ねて、意図を聞いていく。線が太いとか細かい指示をするのではなく、課題にフォーカスした質問をしていきましょう。プロトタイプは特定のゴールのために作られていますから、それをベースにした話をするべきなんです。そうやって検証とプロトタイプを繰り返してプロダクションに入る。ワイワーフレーム→カンプ→エンジニア→マージして、出来上がったものを見たら変になった、ということがこのやり方だと起こりにくいと思います。
こういうやり方でなければ、未知のデバイスに対応した上でWebを作るのは難しいのではないでしょうか。今Google Glassに表示される準備が出来ているのかっていったら、ほとんど誰も出来ていないのが現状だと思います。
クライアントとの関係
photo credit: Baltic Development Forum via photopin cc
コンテンツ提案まで出来るかどうかで大きく変わるけれど、ビジネスモデルを変えてまでデザインを追求していきたくない人がほとんど。でもそこを考えていかないと良いデザインはできません。クライアントはこちらにデザインを任せて、お金を払ってまで僕たちのデザインが欲しいんですよね。なのにどうしてクライアント側の論理に合わせなきゃいけないの？っていう話です。そうするとコンペはまず来ませんし、ただ作って欲しいっていう依頼も来ません。数は減るけど、でもコントロールが効く仕事は来るようになる。
お客さんを教育しつつやる、っていうのは大事だと思います。クライアントはあれもこれも入れてくださいって言ってくるかもしれないけれど、例えばそれを全部入れたものをモバイルで作って、こんなにスクロールしなきゃいけないっていうのがお客さん自身で体感できるといいですね。触ってみてはじめてわかることもありますから。そうすればクライアントに情報のプライオリティと取捨選択をさせるのもやりやすくなるのではないでしょうか。
問題解決のためのデザイン提案を
photo credit: ekai via photopin cc
みんなでディスカッションするためのペーパープロトタイプがあって、役割分担のためのHTMLプロトタイプ、スタイルガイドがある。1日目はみんなで考えて、2日目にはそれを元にしてそれぞれが黙々と作っていく、といった流れでしょうか。このワークフローであれば、柔軟性のあるデザインシステムが構築できると思います。とはいえ、やはり慣れるまでには時間が掛かりますし、最初はどこから手を付けていいのかわからないと思うので、まずは数をこなすしかありません。慣れれば今までのやり方より早く作れるようになると思いますよ。
いかがでしたでしょうか？これからPatch Projectでは長谷川さんに提案して頂いた話を元にして、より良いUIデザインを作るためのフローを徹底的に見直していきます。まずはATMやサインアップ画面など身近なもののUIを実際に作ってみることになりました。まだどういう形でのご報告になるかはわかりませんが、その流れや出来上がったものはアップしていきますのでお楽しみに！