表層デザインを作り込むときに頭の中で起きていることを整理してみる

はじめに

本記事では、表層のブラッシュアップの工程を大きく３段階に分けてそれぞれの議論対象を明らかにしたことで、こんなことへの理解が深まったという話をまとめています。

・デザインの議論/フィードバックの場でも目的とアジェンダ（見て欲しい観点）を共有したほうがいい
・議論対象に応じた有効な言語化がある
・インプットした情報が記憶としてストックされる過程を意識するとスキル成長に役立ちそう

デザインは、言語化が大事と言われますが、それはなぜ重要で、どう活かされてくるのかを、自身の体験の振り返りから明らかにしてみたいと思います。

議論/フィードバックが発散しすぎないための事前準備

プロダクト開発におけるデザインのブラッシュアップは、アウトプットに対する議論/フィードバックが重要なインプットとなっています。

そのため、議論/フィードバックの場において、効果的な意見やフィードバックをもらうためにも、アウトプットしたデザインの意図が適切に言語化されていることが必要です。ただどうも自分の場合、言語化がうまくいくときと、うまくいかないときがありました。

そこでいろいろと整理していくうちに、デザインというやつは完成形に向かっていくプロセスの中で、かなり曖昧に議論対象が変わっていくものであり、その曖昧さが言語化対象の齟齬を生んでいる、もしくは、言語化の難易度を上げているのではないか、と考えました。

（画像引用元：https://developer.apple.com/design/resources/）

UIデザインは、完成形に向かっていく過程で、画面内の情報量が増えていきます。作りはじめは、構造（ナビゲーションや画面遷移など）の情報だけだったところから、表層（色や形、文言など）の情報が付与されていきます。

目に見える情報が増えてくれば見る観点も増えるので、あれもこれもと気になってくるのが人の性だと思います。

では、あれもこれもとならないように着実に議論を積み上げながら前進するためにはどうすればいいか。個人的な解としては、事前準備の段階で、

・ 議論対象を明確にする
・ 議論対象に応じた適切な言語化をする

このあたりが大事そうということが実践を通じてわかってきました。

文字に起こすと当たり前な感じがしますが、リアルな対面の場で、「（このシチュエーションのときはどうするんだっけ・・・？）」といちいち何かを参照したり、思い出したりしながら進めることはできません。

事前準備の段階で、この２点を明らかにしておき、議論/フィードバックの場にアウトプットを展開することは、着実に議論を推し進める上で重要なことだと思います。

仕様と表層の曖昧な関係

先程、デザインというやつは完成形に向かっていくプロセスの中で、かなり曖昧に議論対象が変わっていくと書きました。ここではその曖昧さの発生原因について深堀りたいと思います。

（画像引用元：Apple Design Resources）

いま、目の前にUIデザインが現れました。この画面は、ざっくりどんな要素で構成されているでしょうか。一旦、このような要素分解をして話を進めてみたいと思います。

UIデザイン ＝ 仕様 ＋ 表層

「仕様」と「表層」で分解してみましたが、この２つは非常に厄介な関係性を持っています。どちらも、どちらか単体では機能することができず、２つでひとつの形が成り立つような依存関係にあります。

そのため、事前準備なしに（議論対象を明確にしないまま）UIデザインのアウトプットを議論/フィードバックの場に展開すると、見る人によってその指摘対象が違ってしまうということが発生します。ある人は仕様について指摘し、ある人は表層について指摘するといった具合です。

仕様と表層の曖昧な関係
（混沌と曖昧に混じり合う関係にあるため、仕様が表層に影響を与えるし、
表層が強くなることで仕様に影響を与えることもある、という関係性を持っている。）

UIデザインを作成する過程で、仕様が表層に影響を与えた。表層が立ち現れてきたところで改めて見直したほうがいい仕様が出てきた。という現象は、もちろん起こり得ます。

ただ、大きな手戻りはなるべく減らしたいというのが心情ですし、実際そのほうがプロジェクトとしては滞りなく進むはずです（互いの影響で変更が起こらないことが絶対に良いというわけではないのと、あくまで理想論ですが...。）。

ところが、この「仕様」と「表層」は、表裏一体、２つでひとつのため、
基本的にはひとつのUIデザインとして議論/フィードバックの場に展開せざるを得ません。

では、そのことを踏まえて、どう展開するのが効率的なのかの検討を進めてみたいと思います。

議論対象ごとに有効な言語化を探る

まず、表層のブラッシュアップの工程を３段階に分けることにしました。

（３段階に分けた意図としては、自分の経験値から大体３回くらいの議論/ディスカッションである程度の方向性や要素確定が定まる傾向を感じていたからなのと、３つくらいに分けるのが説明しやすかったからです。なので、状況に寄ってはこの回数が増えたり減ったりすることは全然あると思います。）

次に、その３段階の工程の内訳である議論対象と、その割合いを定めていきたいと思います。ざっくりこんな感じでしょうか。

ちょっと微妙な表現ではありますが、UIデザインが完成形へ向かうときは、

❶ 仕様から先に定まっていき、表層は後工程で決まっていく
❷ 表層の割合が大きくなるに連れて仕様が影響を受けることもある

というイメージを可視化してみました。
（実際はこんなに綺麗に明確なわけではありませんが。。）

これによってアウトプットに対する議論対象を明らかになり、議論対象ごとに必要な言語化も変わってくるのではないかということが見えてきました。

議論対象が「仕様」の場合（１段階目の状況）
UIデザインに載せる情報やレイアウトによってユーザーに達成してほしいことが実現できるかそうでないかの議論や判断のため、メリットとデメリットを並べるという言語化をすることで、意思決定がしやすくなる。

例
・Ａ案のメリット・デメリット
・Ｂ案のメリット・デメリット
・Ｃ案のメリット・デメリット

明確にこの案が良いとなるケースもあると思うし、方針としてはA案で行きたいが、B案のこの部分は取り込みたい。といった風に、議論が次の段階へ進みやすくなることがありました。

案の数は、たくさん出てきてしまう場合や頑張って絞り出さないと出てこない場合もありますが、３つの提示が意思決定にはちょうどよい数であるということを先輩デザイナーからの意見や経験値から感じています。

議論対象が「表層」の場合（３段階目の状況）
メリデメではなく、なぜそのデザイン表現にしたのか、なぜそのデザイン表現である必要があるのか、根拠が明確に言語化されていると、納得感や必要性が判断しやすいので、良し悪しを意思決定しやすくなる。

例
・ 今回は、ユーザーに柔らかい印象を持ってもらいたいので、角丸の大きさを〇〇pxに設定しています。（角丸で異なる印象になることがわかる比較できる画像を用意したり、心理学的には〜など普遍的な法則として参照できる文献などがあれば、それを引用してもいいかもしれません。）
・（ iPhoneアプリの場合、）Appleの策定するデザインガイドライン（Human Interface Guideline）に則っとりながら、このような意図で、このラベルのフォントサイズを設定しこの位置に配置しました。
・この余白は、...。なので、目立たせたい情報を際立たせるために作っています。

プレゼンされる側も納得感を持ってデザインを受け入れることができるようになると思います。

ただ現実問題として、現場でUIデザインのアウトプットを展開するとき、このあたりはかなり曖昧ですし、仕様と表層が何度も行ったり来たりしてしまう状況が起こることがあると思います。

このやり方で進めることを推しているというよりは、UIのアウトプットを展開する際に、自分は何を対象とした議論/フィードバックをその場に求めているのかを明確にしておき、事前にそれを伝えるための、ひとつの参考になれればと思います。

（たぶん、この辺りの仕様と表層が必要以上に行ったり来たりしてしまう問題については、UIデザインの進め方に対する認識の一致または合意を取る働きかけをステークホルダー内で行う必要があり、そこはいろんなアプローチの方法があるはずなので、また別スキルとして扱ったほうがよさそうです。）

表層の作り込みプロセスをさらに詳細に考えてみる

ここでは、表層の作り込みプロセスの３段階目に着目し、そのときに頭の中で考えていることを整理してみます。

表層の作り込みプロセスの３段階目を行うときに、自分の場合は、主に２つの思考プロセスを経てデザインを組み立てていくことが多い気がしています。

❶ 経験値を使って表現を探すパターン
目的（仕様）の確認　→　根拠作り　→　表現収集

❷ 大量の表現のインプットからヒントを得るパターン
目的（仕様）の確認　→　表現収集　→　根拠の後付け

❶ 目的（仕様）の確認　→　根拠作り　→　表現収集
このプロセスでは、ユーザーに達成してもらいたい目的（仕様）を確認し、目的達成のためのデザイン根拠を、経験値などを使ってある程度頭の中で言語化しながら、それに沿う表現を組み立てていきます。

（経験値による）根拠ベースで表現の収集を行います。

❷ 目的（仕様）の確認　→　表現収集　→　根拠の後付け
一方こっちのプロセスでは、ユーザーに達成させたい目的（仕様）を確認するところは同じですが、自分の中に表現の引き出しが不足しているなどの理由で先に根拠を組むことが難しいため、まずインスピレーションとしての大量の表現を探すということを行います。（かなり悩んで迷走するフェーズ。）

そのなかで見えてきた有効そうな要素から根拠をあぶり出したり精度を上げたりして、実際の画面に当て込んでいくという作業を行います。

この❷のプロセスは、実際にうまく表現として導き出せると、今後❶のプロセスで再利用可能な記憶のパターンとしてストックされます。

（このへんの思考プロセスって、他の方はどんな感じなんでしょうか。。自分の場合はだいたいこんな感じだと思いますが、、、。これから変わっていったりする部分もあるのかな。）

ここで興味深いのは、❷のプロセスは、一度経験すると❶のプロセスで再利用可能な記憶としてストックされる点だと思います。いわゆる経験値というやつと同義、つまり表現の引き出しが増えるということだと考えられます。

自分はそうなんだけど、特に経験の少ないジュニアデザイナーでは、この❷のプロセスを多く踏む機会が多いのではないか。と思っています。

なので、（❷の回数をこなして）経験を積んでいくと、❶で処理するときに使える記憶のストック（引き出し）が多くなってくるので、❶で処理できることが多くなり、❷のように悩む機会は比較的減っていくのではないか？と考えました。

記憶のストックが再利用される脳の仕組みに踏み込む

（ここからは、自分の経験としてまだ未知の領域で完全に個人的な興味による独自解釈です。）

❷のプロセスは、一度実行されると頭の中に記憶のパターンとしてストックされます。そしてそのストックされたパターンは、❶のプロセス実行時に再利用が可能です。

つまり、デザイナーとしての経験値が貯まってレベルが上がっていくと、記憶されたパターンを使って❶のプロセスで処理できる場面が増えていく。それは、アウトプットが安定してくるとも言えるんじゃないか（研ぎ澄まされるとデザイナーの作家性とも言える状態が生まれるのかな）と思いました。

なので、先輩の良いパターンは可能な限り盗むほうがいい。
良いパターンをたくさんストックする。

ただ別の観点としてネガティブに捉えるとアウトプットがパターン化してきてしまう懸念もあるんじゃないか、とも考えました。

たくさん良いものを見たほうがいいとシニアレベルが口を酸っぱくして言うのは、記憶のストックが貯まってきてパターン化してきてしまうことを避ける意味合いもあって、意図的に❷のプロセスを実行するということなのではないか。と思いました。

仕事以外の領域で❷のプロセスを実行することで得た記憶のストックは、❶で再利用されるため、それが自分の表現を狭めないということに繋がるのではないか。と考えることができるようになりました。

こんなことを通して見えてきた自分の課題

ここで、自分の中の課題も見えてきました。僕の場合は、表現の根拠を示すための言語化ができていないことが多く弱い部分です。

根拠の言語化をすっ飛ばして、表現のパズルをするという思考の癖を持ってしまっているため、思考の習慣から切り替えていく必要性を感じています。

思考の癖なので、繰り返しの訓練で直していく必要があるので、その解決案として下記を実行することにしました。

表層の作り込みのときに踏む手順

ポモドーロタイマーを使ったイメージ収集の方法

①ポモドーロタイマーを起動する
②25分間インスピレーション（イメージ）を集める
⇒ 25分経ったら、集めたイメージの根拠を言語化する

→足りてる場合③へ
→足りていない場合②に戻る
（足りているか足りていないかは、言語化した根拠で、目的（ユースケースなど）を達成できそうかで判断。）

③形をつくる
⇒ 形を作りながら、目的を達成できそうかを確認する

一旦これをやってみる。

追記：
これ、やってみた結果、課題も出てきていて近いうちにまた記事にまとめようと思います。