Webディレクター解体アドベントカレンダー17日目の記事です。今日はユーザー体験の設計についてです。ディレクターがどこまで設計に関与するべきか、結構議論の別れるところだと思います。曰く、ユーザー体験の設計はデザイナーに任せてディレクターは口を挟むべきでないとか、ユーザー体験はプロダクトの根幹なのだからプロダクトの責任者は当然そこに責任を持つべきだとか。もちろんプロジェクトや開発メンバーによって違うから一概に何が正解とか無いでしょう。
個人的には、弊害が無ければどんどん踏み込んだらいいと思っています。弊害というのは、最初にディレクターの作ったワイヤーフレームに引っ張られ過ぎちゃって全然良く無いものができてしまうとかそういうやつです。この立場の人はこれに口を出すべきでは無いなんて、それこそ心理的安全性を脅かす言動ですし、画面の設計にもどんどん踏み込んだらいいんです。
でも必須のスキルでは無い。たまにワイヤーフレームの美しさを誇るディレクター（自己紹介）がいますけど、美しさなんてどうでもいいんです。意図が伝われば何だっていい。大事なのは、調査や分析の結果からユーザーニーズを一番汲み取っているべき立場のプロダクトマネージャーが、汲み取ったニーズを言語でも視覚的にでもどういう形でもいいからきちんとチームメンバーに伝えていいものを作ってもらうことです。
その伝える時の手段として、ペーパープロトタイプだったりワイヤーフレームだったりがある。だからここでも、伝えるべき意図が先にあるべきです。その次に手段があります。前置きが長くなりましたが、今日はその手段の例を紹介します。
紙に描く
最も手軽で、個人的にも一番よくやる方法です。クロッキー帳が好きで、そこにスタッドラーのサインペンでガシガシ描くのが気持ちいい。最近は格好つけてiPadにペーパーライクフィルム貼って、アップルペンシルで描いてます。アプリはコンセプトっていうやつをよく使います。
とにかく自由。こういう感じにしたいんだよねっていうフィーリングに従って描いて、こういうのどうよって言いながら開発メンバーのところに持っていきます。まだ設計初期の段階で、固め過ぎない状態でみんなとああでもないこうでもないと会話する時に良いです。
スマートフォンと同じくらいのサイズに紙を切って、スマホの画面みたいに握りながら触ってみるのもいいですね。画面内でUIが動いていく時のイメージは、画面のパーツをハサミで切り抜いて重ねたりしながらフローを試してみるのも楽しいです。図工の時間みたいで、とにかく楽しいのが最高です。
画面遷移図
よく画面遷移図と呼ばれる、作る画面を全て洗い出してフローに沿って矢印で繋げた図を作ることもあります。入力された情報ごとに分岐していくような複雑な遷移を表す状態遷移図とも似ています。一方で作る画面の抜け漏れを防ぐために網羅性を重視した画面一覧というのもあります。
- 状態遷移図
- 入力された情報に応じて遷移を出し分ける時など、複数の状態を遷移と共に洗い出しておきたいときに作る。
- 画面遷移図
- ユーザーがどの画面からどの画面に遷移していくか、その体験の順番に画面を並べた図。作るものの全体感を把握するときに作る。
- 画面一覧
- 作るべき画面を網羅するために作る一覧。遷移よりは階層構造を表現することが多い。
画面遷移や画面一覧を作って欲しいと要請されることもありますが、その場合相手が求めているのはどれなのか、何を把握したいのかを確認してから作るといいと思います。
画面構成図
画面構成図はいらないとよく言われます。ワイヤーフレームとも呼ばれるやつです。デザインの専門家でも無いディレクターが作る画面構成に大した意味なんてないと。まあ言わんとすることはわかります。でも、ディテールから生まれる企画もあるんです。
以前にあるコンテンツのビューワの企画をしたことがあったんですが、その時は一番最初にワイヤーフレームから作り始めました。もっとSNSで拡散されやすいようなビューワを作りたいということで始めた企画だったんですが、拡散されやくするにはもっとパーマリンク感が欲しいと思ったんですね。だけど「パーマリンク感を出す」とかテキストで企画書に書いてあってもわけわかんないじゃないですか。どういうことやねんと。画面のイメージがあるか無いかで、企画が成立するかどうかまで左右されることもあるわけです。ああなるほどこれならアリだよねと、デザイナーに発注する前に企画すら立ち上がらなかったら終わりですからね。
そういう意味でも、企画時点で前提となるイメージする画面があるのなら、汚くても綺麗でも何でもいいからとにかく描いたらいいと思っています。
意図に応じて
意図があって、それを開発メンバーやステークホルダーに伝えたい。そういう時にやっぱり、ビジュアルがあったほうが話が早いです。
自分のイメージを伝えて、それぞれの立場からのフィードバックをもらって、それを反映してブラッシュアップしてまたぶつける。そういうキャッチボールを通じてユーザー体験を磨き上げていくなら簡単に素早く描けるものがいいでしょう。チーム全員で最初に眺めて作るものの認識を揃えるためならとにかく網羅性が大事ですし、開発前に画面イメージをユーザーさんに見てもらって感想を聞いて不確実性を減らしたいならある程度デザインされたものが必要です。
設計する時に作るものの選択肢をいくつか持っていれば、意図に応じて使い分けられて便利です。
