「なんとなく良い」を卒業するためのデザイン意図の言語化
デザインレビューで「なんか良さそう」や「しっくりこない」という言葉が飛び交って、議論が前に進まなかった経験はないでしょうか。あるいは、自分が作ったデザインに対して「もう少しちゃんと説明して」と言われたものの、何をどう説明すればいいのかわからず戸惑った経験はないでしょうか。
以前の記事で「みんなではじめるデザイン批評」を紹介した際にも触れましたが、感覚的なフィードバックに依存したレビューは、非生産的なサイクルを生みやすいです。
しかし、この問題はフィードバックする側だけに原因があるわけではありません。提案する側のデザイナー自身が、自分の意図を言葉にできていないケースも少なくないと感じています。
デザインを「作る力」と「説明する力」は、別のスキルです。この記事では、デザイン意図を言語化するための考え方と、レビューの場で実践できる伝え方について整理してみます。
この記事のターゲット
デザインレビューで自分の意図をうまく説明できないと感じているデザイナー
チームのデザインレビューの質を向上させたいデザインマネージャー
デザイナーのアウトプットにフィードバックする立場のPMやエ ンジニア
なぜ「なんとなく良い」が生まれるのか
デザイナーが言語化に苦しむ背景には、構造的な理由があると考えています。
デザインの判断には、暗黙知が多分に含まれます。経験を積むほど、配色の選び方、余白の取り方、情報の優先順位付けといった判断が非常に素早く、瞬時に意思決定されるようになります。
これは熟達の証でもあるのですが、はたから見ると意思決定の根拠が表出する前にアウトプットが出来上がっていく様子は「感覚的に選んでいる」ように映ります。さらに、言語化するよりも緊急度の高いタスクがどんどん積み上がっていくため、言語化する機会そのものも失われていきます。
つまり、経験豊富なデザイナーほど「なぜそうしたのか」を説明しなくなる（しにくくなる）という逆説が起こります。イメージとしては、「歩くためにどうしていますか？」と聞かれた場合を想像してみてください。「まず左足に重心を寄せて浮いた右足を膝から持ち上げ、少し前の地面に着地させるのと同時に重心を右足に移し…」のように説明できる人はなかなかいないと思います。身体に染みついた判断は、言語化の対象から外れてしまうのです。
プロダクトデザインの現場でも同じことが起こります。例えば、画面設計で「多くの画面ではラジオボタンにデフォルト値があるのに、なぜこの画面だけデフォルト値が空なのか？」と尋ねられて、「なんとなくこうしたけどなんでだっけ？」となって即答できず、後から思い出して「最初から選択されていると誤解を与える選択肢（性別など）や、ユーザーが選択をクリアの状態で保留したい場合は、デフォルト値を持たせなかったりクリアボタンを配置している」などと説明する場面があると思います。少し考えれば説明できるのに、聞かれるまでは言語化されない。これが暗黙知の厄介なところです。
問題は、こうした意思決定の根拠が言語化されないまま開発が進んでしまうケースです。デザイナーが自分から説明せず、周囲からも質問されなければ、判断の理由はデザイナーの頭の中にとどまったまま他の開発者にコンテキストとして共有されません。そしてそのデザインがたまたまユーザーに受け入れられると、「なぜ良かったのか」が検証されないまま「良い画面だった」で終わってしまいます。
こうした暗黙知への依存がチームの習慣として定着してしまうと、レビューの場でも「なんとなく良い」「しっくりくる」「バランスが悪い気がする」といった感覚的な表現が支配的になります。これはデザイナーのスキル不足ではなく、暗黙知を明示知に変換する訓練と機会が足りていないシグナルだと考えています。
デザイン意図を分解する3つの軸
では、どうすれば「なんとなく」を言葉にできるのか。私が意識しているのは、デザインの意図を3つの軸で分解するという方法です。
1つ目は「目的」です。 このデザインは、何を解決するためのものなのか。ユーザーのどんな課題やタスクに応えようとしているのか。そして、ビジネス上のゴールとどう接続しているのか。
以前「なぜあなたのデザイン案は却下されるのか」という記事でも述べましたが、デザイン提案が通らない原因の多くは、デザインの品質ではなく、目的との接続が不明確なことにあります。「このボタ ンを目立たせました」ではなく、「ユーザーが次のアクションを迷わずに選べるようにするために、このボタンの視認性を上げました」と言い換えるだけで、目的が明示されます。
2つ目は「根拠」です。 なぜその表現を選んだのか。判断を支える情報源は何か。
根拠はユーザーリサーチの結果かもしれませんし、既存のヒューリスティクス（経験則による主観的な判断）かもしれません。認知科学的な知見が裏付けになることもあります。例えば、「近接の法則に基づいて関連する要素をグルーピングしました」とか、「ユーザーが既存のツールで慣れている操作パターンに合わせました」といった説明です。根拠を添えることで、「個人の好み」と「設計判断」の区別が明確になります。
3つ目 は「オプションとトレードオフ」です。 何を捨てたのか。他にどんな選択肢があり、なぜこちらを採ったのか。
デザインは常に制約のなかでの意思決定です。技術的な制約、スケジュール、既存UIとの一貫性、アクセシビリティ要件など、様々な制約が存在します。「タブUIも検討しましたが、項目数が2つしかなく今後も増えないことから、切り替えコストのほうが高いと判断し、２カラムレイアウトで横並びにしました」のように、採用しなかった選択肢を明示することで、デザインの意図が逆説的に浮かび上がります。
レビューの場で伝わる話し方
フレームワークを持っていても、伝え方次第で伝わらないことがあります。レビューの場で意識したい実践的なポイントをいくつか挙げてみます。
事実と主観を分ける
「事実と主観は分けて伝えてほしい」という記事で述べた原則は、フィードバックする側だけでなく、提案する側にも当てはまります。
「このレイアウトが良いと思います」は主観です。一方で、「ユーザビリティテストで視線が左上から右下に流れる傾向が確認されたため、主要なCTAを右下に配置しました」は、事実に基づいた判断の説明です。事実→判断→結論の順で話すだけで、聞き手の納得感は大きく変わります。
「なぜやらなかったか」を語る
レビューでは「なぜそうしたか」だけでなく、「なぜそうしなかったか」を語ることも効果的です。検討したけれど採用しなかった選択肢を共有することで、思考の奥行きが伝わります。意図的に棄却した選択肢を示すことで、レビュー参加者が「この案はどう？」とゼロから提案する手間が減り、議論の土台を共有した状態で始められます。
実務では、複数の選択肢を提示する方法として大きく2つのアプローチがあると思います。
1つ目は、ボリュームの段階で分ける方法です。特盛・中盛・小盛のように、同じ方向性のデザインに対して機能の盛り込み具合を変えたプランを提示します。例えば、従業員一覧画面の設計で、絞り込み機能とCSVエクスポート機能を含んだ特盛プランが最も理想的だが、CSVエクスポートは実装工数が大きくエッジケースでもあり、後から追加もできるため、絞り込み機能だけを盛り込んだ中盛にする——といった判断です。このアプローチは、トレードオフを具体的に示しながら要件を満たすラインを選びやすくし、折衷案を導き出すための材料になります。
2つ目は、コンセプトの方向性で分ける方法です。松・竹・梅のように、設計思想自体が異なるUIパターンを提示して、それぞれのメリットとデメリットを添えてプレゼンテーションします。例えば、あるデータを親子関係で持たせるか、独立したエンティティとして関連付けで紐付きを表現するかといった選択は、後から変更しにくい不可逆な意思決定を伴います。こうした場合は、それぞれのプランの影響範囲を慎重に一つずつ判断してクリアにしていくことが重要になってきます。
いずれのアプローチでも、「他の選択肢を検討した上でこれを選んだ」という過程が可視化されることで、レビューの議論の質が上がります。
相手の言葉で語る
同じデザインでも、伝える 相手によって使うべき言葉は変わります。開発サイドには「状態」「条件分岐」「デフォルト値」の言葉で語り、ビジネスサイドには「ユーザー価値」「コンバージョン」「業務効率」の言葉で語る。相手のメンタルモデルに合わせた翻訳が必要です。
デザインにおける同期・非同期の意思決定について述べた記事でも触れましたが、コミュニケーションの質はデザインの質に直結します。同じ内容でも、相手に届く言葉を選ぶことで、提案の通りやすさは大きく変わります。
言語化は「説得」ではなく「共有」である
ここまで言語化のテクニックを述べてきましたが、一つ補足しておきたいことがあります。言語化の目的は、自分の案を通すことではありません。
チームがより良い判断をするための材料や事実情報を揃えること。それが言語化の本質だと考えています。
デザインの意図が暗黙知のままでは、他のメンバーはそこに関与する術を持ちません。一方で、目的・根拠・トレードオフが言語化されていれば、それを土台にして改善案が出てきたり、見落としていた観点を指摘してもらえたりします。つまり、言語化は完成したデザインを「説得」するためではなく、デザインが完成に向かう過程をチームに「共有」するための手段です。
私の場合は、プロダクトの兼務によって開発チームとモブデザインなどの同期的なコミュニケーションが取りにくい場面が増えたことをきっかけに、Slackのスレッドで自分の検討プロセスを実況するようになりました。「このパターンだとこの操作ができないなぁ」とか「こっちの方が良さそうだけど、こういうトレードオフがありそう」といった、頭の中で考えた言葉を独り言のように書き込みながらUIを作成していきます。
すると、スレッドにどこからともなく開発者が現れて「良さそう〜」とか「これだとこの場合を救えないかも」のようなツッコミをもらえたり、「なぜこうなっているのですか？」のような質問が自然と誘発されたりします。検討過程がスレッドに残っているので、UIのアウトプットとスレッドを合わせて要約すれば、パターンの提示資料も効率的に作りやすくなりました。
完璧に整理された説明を後から用意するよりも、思考の途中経過をリアルタイムで開示するほうが、チームの関与を引き出しやすいと実感しています。
「みんなではじめるデザイン批評」でも述べられていたように、批評は協働の中核をなすものです。言語化されたデザイン意図は、デザイナーの自己弁護のためではなく、チームがプロダクトの質を一緒に上げていくための共通言語になります。
言語化は筋力に近いものだと思います。最初は一つの判断を説明するのにも時間がかかるかもしれません。しかし、繰り返すうちに「なぜこうしたのか」を問い続ける習慣が身につき、デザインを考える過程そのものの解像度も上がっていきます。大切なのは、完璧な説明を用意することではなく、まず言葉にしてみることです。
次のデザインレビューで、自分の判断をどこまで言葉にできるでしょうか。まずは一つの選択について、目的と根拠とオプション（トレードオフ）を書き出すところから始めてみてください。
