企画とチームプレーでUIデザインする方法 3/4
よくある企画の人の働き方
ガントチャートと課題リスト：よくある企画の人の働き方
いままで見たことのある企画メンバーは、プロダクト開発の局面だけに限るとこんな作業をしていました。「課題リスト」とガントチャート作りです。
1. どこかから持ってきた要望を似たもの同士にまとめて表にする
2. ガントチャートを書く
3. 並行作業に分解して予定を詰め込む
ガントチャートは、たいてい「機能」という単位で細分化されていきます。この「機能」とは、ユーザーに提供される最小の価値でもなく、プログラミング上のモジュールなどとも特に一致しません。このため、1工程が終わってもプロダクトとしてのUXがどうなっているか最後までわからない状態になりがちです。後から良いアイデアを思いついても、最初に伝えた要件の撤回は簡単ではありません。なぜなら、細分化して途中まで作った成果物が無駄になるからです。
🤔 「機能」とは、一体どんな概念なのでしょうか…
🤔 「どこかから持ってきた要望」は本当に「似たもの同士」でしょうか…
🤔 並列作業は本当にスケジュール通りに進むのでしょうか…
予実管理が中心になってプロダクトから疎外された状態
この場合、企画がプロダクトに対して実質的に管理できるものは何でしょうか。
上記のように、プロダクトづくりの外部要因を直接調整できても、プロダクトの全貌や課題解決からは疎外されています。今回はこの状況を「他人事なのに、管理している」と表現します。
プロダクトの良し悪しを気にしそうな職域なのに：
・終わるまでずっと待たされる
・エンジニアやデザイナーが何してるのかわからん
・終わったか終わってないか曖昧だから、気になっていじりたくなる
・他人事のような…でも責任あるからなんか言いたい…
今回は企画チームのメンバーでしたが、開発や決済者など、プロダクトの良し悪しを気にしそう人、プロダクトの在り方に課題感がある人は既に周りにいるはずです。
1. ハンドリング感を得る
以下のような取り決めをして「私達がプロダクトの良し悪しをハンドリングしてるんだ」と実感を得られる環境作りをしました。
取り決め
・ 一度にあれもこれもやらず、常にひとつのUIデザインに集中
・ 1つ終わらないと次に行けない
・ 代わりに小刻みにレビュー
作る前と作ったあとに必ずレビューし、OKなら次に進みます。このようにして、シングルタスクを徹底しました。
2. デザインの一貫性を守る
最初は手数が物を言う
あやふやなものを具現化するデザイナーの職能をフルに発揮し、超初期フェーズではプロトタイピングしまくります。
代表的な画面の色合いやレイアウトを数パターン・数十個つくって、どの見た目だとどう感じるか話し合います。
「ミッキーマウスっぽい」って何？
このような力まかせな認識合わせ作業をしているとき、企画が言っていたコメントです。最初は冗談かと思いましたが、実際にはその後の方向性に影響を及ぼすキーとなるフィードバックでした。
たしかにそう言われると、それらしいですね。。
「ミッキーマウスっぽい」からわかったこと
・ プロダクトの性質や使われてきた文脈を加味せず理屈だけで作ってもフィーリングがマッチしなそう
・ デザイナーが考えてもいない事を画面から感じている
・ デザイナーでなくても「なんか違う」は大抵正しい
この辺りの話をしていると、「クールな雰囲気」というキーワードが出てきました。じゃあクールな雰囲気ってどんなものでしょうか？
クールな雰囲気を模索する
ここからは、具体的なUIのプロトを沢山作って、会話の内容をグラフィックの法則として具現化していきました。1つ作って、気づいた事があればほかも直してという、実装段階では「手戻り」となる作業をあえて繰り返しています。だいたい下記のような法則性が生み出されました。
プロトを見ながら会話の内容を具現化した例：
画面にパッと出てくるものは角を尖らせる
・ ダイアログ
・ 通知
・ メニューリスト
ユーザーが押せるものは角を丸める
・ ボタン
・ ラジオボタン
・ セレクトメニュー
丸っこさはクールな雰囲気とは少し遠いですが、一般的なUIに見慣れたユーザーのメンタルモデルに配慮しました。こういった調整も会話ベースで引き出して、ルールとして具現化していきました。
トランジションのルール
・ 大きさ
・ UIのタイプごとのスピード
・ 遷移が始まる位置
ブランドの赤ってどれ？
マンセルを使用したカラーパレットがとんでもなく不評で、UIのキーカラーとカラーパレットの設計方法に手こずりました。
予想以上に利害関係者のこだわりが強く、1週間くらいかけて調整したと思います。
このように、初期は手を動かしまくって、目先の生産性やスピードはほとんど無視して、共通のフィーリングを発見することに注力しました。
プロトタイピングという関数に、企画の思うプロダクトの理想像を与えると、具現化されたデザインの法則が指し示されるイメージです。この取り組みによって下記のような成果を得ました。
👉 共通のフィーリングから全体の法則を生み出す
👉 双方で知恵を絞って決めることで、二人でデザインを守る理由をつくる
3. 実現方法の追求
「なんのため」に作るか明文化し、共通認識を得る
UIの1つずつに対して、そのUIは「なんのため」に存在して、ユーザーにどんな値打ちがあるか明文化していきました。実際にはTrelloのカードにして用意しています。
○ やること
アイコン付きのボタンを見ただけで、送信が押せる。
○ 何のため？
・文字をよく読まずとも確信をもって操作できる。
・アイコンに固有の意味をもたせ、どこでも同じ言葉として使う。
何のため？がUIの指標
企画と一緒に、UIの「何のため？」を決めます。それをデザイナーが具現化することを1セットの作業にしました。UIを作るたびに、この指標に合致しているか企画と話して、もっと作り込むか、次に進むか決めていきます。
事実に基づくスケジュール
UIごとに作業のコストを割り出します。それを週ごとに簡単に集計して、その週の見積として使います。
先の通り、シングルタスクを徹底しているので、実績を元にその週でできる量を決め、どの順でやったら一番ユーザーに値打ちがある組み合わせになるか一緒に考えました。
無駄な手戻りを防ぐための工夫
ここまでで、「ほかの利害関係者は？」と思った方がいるかもしれません。企画とデザイナーの話しかしてきませんでした。他の利害関係者との折衝は企画が活躍します。
企画メンバーとイメージを擦り合わせたら、2、3枚の画面イメージを用意して、BO（事業長）や他の利害関係者とどのデザインで進めるか合意をとっておきました。
これで、デザイナーは価値の実現方法に集中できます。
一見、合意形成の場から退いて企画に依存しているようですが、そうではありません。デザインの基準もUIそのものも、汗水たらして二人三脚で一緒に作っています。企画の意向はデザイナーの共感と合意があり、デザイナーのUIは企画の意思を具現化したものです。
それによって、企画と話し合った「何のため？」だけを信じてデザインすれば良くなり、デザイン作業に自身の作業コストをフル投入できます。
以上が企画メンバーにプロダクトの当事者になってもらうための取り組みでした。長くなったので、デザイン作業のマネジメント方法は最終回に触れます。