デザインと言語化

2022年4月15日 17:39

言語化、してますか？

と聞かれて全くしてない人はまず居ないと思います。
日記、LINE、ツイートなど、意図を言語化した結果のアウトプットは少なからず誰もがしているはずです。

仕事面に関して言えば報告・連絡・相談のような基本的なコミュニケーション、目標設定のような自分を見つめ直すような言語化もあります。
もしTODOリストを管理しているとすればタスクを言語化しているし、議事録は議論内容を言語化したドキュメントです。

他にも、エンジニアの実装という作業はロジック（思考）をプログラミング言語という言語に起こすことそのものを指しているし、コードレビューではそのコードのどういった特徴がどう良い/良くないかを伝えてより良い成果をチームで作るものです。

言語化するメリット

言語化する事によって得られるメリットは大きく以下の３つに分けられます。

思考を客観視して判断の精度を上げる
思考を確定させて判断の基準にする
伝えたい相手に情報を伝えて反応をもらう

1は考えるための言語化、2は基準を作るための言語化、3は伝えるための言語化です。

整理してみると言語化はデザイナーにとって非常に重要なスキルであることがわかります。
では、僕がデザインを作るにあたって行っている言語化について紹介します。

デザインを作るにあたって行っている言語化

ターゲットユーザーイメージ

ターゲットユーザーイメージはサービスを使うユーザーがどんなユーザーなのかをまとめたドキュメントです。
仮想のユーザーではなく下記のゴールを定めたりサービスのコンセプトを検討するための指標として言語化します。

・氏名
・性別
・年齢
・家族
・職業
・住所
・人物像
・1日の行動イメージ

さっくりテンプレ

ゴール

ターゲットユーザーイメージを言語化したら、次にユーザーがサービスを通してどういった体験ができると良いかを言語化します。
サービスを触っているユーザーにどんな感情を与えたいか、ユーザーは（サービスを度外視して）どうなりたいのかなど、ユーザーのゴールをいくつかの段階で言語化します。
デザインで迷ったときにはこのゴールを見直して「どちらのほうがゴールに近づけるだろうか？」と検討できるようになります。

サービスを触っているユーザーにどんな感情を与えたいか
・仕事に集中する環境を整えたいときに頼りになると感じる

ユーザーがサービスを使ってどんな状態になりたいか
・今いる場所の近くにある、ワーキングスペースを見付けられる
・これから行く予定の場所ですぐ利用できるワーキングスペースを見つけられる
・リモートワークに関する知識やノウハウを得られる
・リモートワークで働く環境の選択肢が広がる

ユーザーはどうなりたいのか
・どんな状況でも仕事に集中して効率的にこなせる
・自分自身のスキルや価値が高まり、プライベートにも余裕が出る

例（リモートワークのくふう）

シナリオ・マップ

ターゲットユーザーがゴールに達成するまでの道筋の言語化です。
シナリオは文章、マップはSPRINTの記事で紹介したチャートのような形での言語化です。
何をどう操作するかを言語化し、それを元にどこでどのような事を考えながら何をしたいのかを整理していきます。
単に情報を並べるだけならいくらでもやり方がありますが、その情報をどう視るかを言語化すると選択肢を大幅に絞れます。

　3日後に訪問での作業が決まった。少し遅めの時間なので、家に帰ってから仕事をするのではなく近場でコワーキングスペースを利用して仕事したい。このサービスを使い、訪問先周辺のエリアでスペースを探した。数時間の利用なのでドロップインでの利用を前提に検討し、スペースを発見した。スペースの詳細な情報を確認し、良さそうだったのでそのスペースを利用予定リストに入れて当日開くことにした。当日、利用予定リストからスペース周辺の地図を即座に呼び出せたので迷わずコワーキングスペースを利用できた。

例（リモートワークのくふう　のシナリオから抜粋）

構造化シナリオ

構造化シナリオはターゲットユーザーイメージ・ゴール・シナリオを一気に検討できる面白い言語化のフレームワークです。
非常に強力なフレームワークで、それぞれを埋めていくと最終的にサービスが何を提供し、ユーザーがどんな操作をするのかが見えてきます。
ある程度全容が見えているプロジェクトで最初から採用したり、そうでないプロジェクトではターゲットユーザーイメージ・ゴール・シナリオを整理してから構造化シナリオに整理したりしています。

デザインレビュー依頼・デザインレビュー

具体的にデザインを作ったあと、他のデザイナーにレビューをもらうために自分のデザインの意図を言語化します。
なぜそれをそう作ったのかというデザインの意図ともらいたいレビューの粒度を言語化しておくことで、もらえるレビューの精度が格段に上がります。

また、デザインレビューをする際にはレビュー対象となるデザインがどういった意図でデザインされたかを把握した上で意図とアウトプットを照らし合わせながら新たな視点を提供できるよう自分の意図を言語化します。
自分の好き嫌いではなくどの要素がユーザーにとってどう作用しそうかを言語化するように気をつけています。

余談：CSS

CSSはデザインの表層を言語化するプログラミング言語だと考えています。
デザインはデザイナーの頭の中にある一定の意図を元に作られているものです。
例えば「この要素とこの要素は並列だから余白はこれくらい、この要素は別の要素だから余白は広めに」といった感じです。
CSSを書くということはこういった意図を具体的な数値に起こすことです。

問題はこの意図を正しく把握してもらうためのアウトプットを作るとなると時間が大量に溶けるということです。
デザイナーはこのあたりの意図をなんとなく読めるんですが、デザイナーじゃない人で読める人は非常にまれな気がします。

デザインの意図を都度言語化するというよりはデザインの読み方を言語化したい…

そんなことを考える僕なのでした。

読んでくださりありがとうございました。
この記事は株式会社Da Vinci Studio で毎月行われている全社会で社員全員の持ち回りで発表しているLTを記事の形に起こしたものです。
そんな Da Vinci Studio ではデザイナー、エンジニアともに積極採用中です。
よろしくお願いします！

この記事が気に入ったらサポートをしてみませんか？