どうやって自分のデザインを伝える?「デザインの伝え方・話し方講座」CSS Nite in KOBE, Vol.27

CSS Nite in KOBE, Vol.27の「デザインの伝え方・話し方講座」に参加してきました。デザイナーとして自分のデザインを人に伝えるのって難しいですよね。デザイナー同士ならまだ自分の考えを汲み取ってくれますが、基本は非デザイナーに伝える方が基本です。
 今回の講座では相手の潜在的ニーズを考慮した上でのデザイン提案をするための方法を聞いた後に実際にグループに分かれてワークショップを行い、架空の相手にデザインの重要性をどう伝えるのか考えました。
今回の登壇者
今回の登壇者は長谷川 恭久さんです。長谷川さんはデザインに関する記事を発信するブログ(http://www.yasuhisa.com/could/)を運営していたり、OVSERVERというYouTubeチャンネルでデザインに関する動画を配信していたりする方です。
セミナー内容
デザインの伝え方や話し方というセミナーってなかなか無いですよね。基本的にデザインのセミナーって作り方だったり考え方だったり、制作に関する事がほとんどです。しかし今回はどうやってデザインを伝えるのか?話すのか?制作の後の話です。更にただ聞くだけでなくワークショップとして実際に自分で考えます。
デザインは言語化されてきている
本編前に最近はデザインのドキュメンテーション(言語化)がされていますというお話からスタートしました。どういった影を作ればいいのか?タイポグラフィはどのようにすれば良いのか?今まで感覚的に作っていたものが、どんな人が作ってもある程度の品質を保って作成できるようにするのが今の時代は大切になってきています。
この例として出されたのがNetFlixです。赤と黒を貴重とした特徴のあるデザインですね。

Webデザインだけでなく、最近はアイコンのデザインもドキュメンテーションされてきているようです。今までは個人のデザイナーの感覚によって作成されていたのですが、そのデザイナーの人がいなくなってしまった時に困りますし、そのデザイナーの感覚が変わってしまうと一貫性が失われてしまいます。
誰が作っても一貫性が失われないためにも、デザインのドキュメンテーション(言語化)が必要になってきています。
欧米と日本のデザイナーはここが違う
さて、次は欧米のデザイナーと日本のデザイナーの違いについてですが、そもそもデザインのプロセスにおいてどのタイミングで何をするのかという事をきちんと把握していないと、想定していないフィードバックが来てしまいます。
下の図は「ダブルダイヤモンド」という制作を行うプロセスをまとめたフレームワークですが、この図は制作で物事を発散するフェーズと集約するフェーズを表しています。

まず、「調査」のフェーズで「市場調査・インタビュー・エスノグラフィ」等の手法を用いて物事を発散させます。このままでは選択肢が多すぎるので、次の「定義」のフェーズで「ペルソナ・カスタマージャーニーマップ」等の手法で問題定義・課題定義を行い、集約させます。
そして次の「模索」のフェーズでまた発散させます。この際に利用するのが「プロトタイプ・イテレーション・ワイヤーフレーム」といった手法です。ここで可能性の模索を行うわけです。
最後の「実装」フェーズで完成に向けて集約させていきます。「ビジュアル設計・コーディング・テスト」を行って制作物が出来上がります。
こうやって見てみると部分部分では行っていたり、セミナーや書籍で学んでいたり、実際に行っている人もいるかもしれませんが、この流れを全てきちんとできている所は少ないですよね。
 スケジュールや予算が取れなくて、上から「とりあえず作ってよ」と言われ仕方なく制作してしまったり、一発で良いものを作らないといけないワークフローだと色んな可能性を模索できなかったり。
それに、製作者の場合は最後の「実装」のフェーズから関わる場合もありますよね。「そもそも」が共有されなくてその結果様々な「しわ寄せ」を背負う事もありますし、問題定義が分からないまま作ってしまうから作ってる最中に逆提案して後戻りなんてもことも…
制作会社が全てを行う必要はありませんが、クライアントと制作チームがきちんと連携が取れているかどうかが重要です。
プロセスの課題
実装しか関われない場合があって、何も定義付けがされていないのに制作をするのは辛いですが、体制としてそれを打開するのは難しいです。
 制作に関しても手段から入って空回り。結局カスタマージャーニーマップやプロトタイプ等、やり方は分かっても仕事にどうやって導入していけばいいのか分からかったりします。
でも欧米はなぜかうまくいっている…
日本はそんなに駄目なのか?と思ってしまいそうですが、長谷川さんは「作れるスキルは同じ」「日本のほうが優れている部分もある」と仰っています。
 ただ代理店の立場が異なっているためやりやすいやりにくいの問題は多少あるが、「作れる」という面で言えばそこまで差はないそう。
ただ、「話せる」という点において圧倒的に違う。ここで負けているから全体的に日本が劣っているような印象を持ってしまうんだとか。
 欧米ではMediumというサイトでデザインとタグ付けしてみると、プロから学生から求職中の人までデザインに関する事を発信しています。

デザイナーが世間に対して意見を発するのは1960年代から続いている。Webに始まった事ではなくてグラフィックデザインの頃から、デザイナーが自ら情報発信して、良いものを世に出していこうという文化が続いています。
- 自ら説明するという事が当たり前
- 最適な手段を提案する
- 考え方を惜しみなく伝えていく(社内や同業者に向けて)
その上、アメリカの学校ではプレゼンテーションの授業があります。「作る」と同じように「話す」事も必須スキルとして授業のカリキュラムに組み込まれているのです。欧米はそれを50年以上続けています。
日本だと、今は変わってきていますが「黙って良いモノを作る」職人タイプの人が非常に多かったようです。僕もこの業界に入る前はデザイナーってあまり表に出て話したりするイメージを持っていませんでした。縁の下の力持ちで、黙って影から商品やサービスを支えているようなイメージを持っていました。
しかし「良いモノを見れば理解できる」時代はもうとっくに終わっていますし、それができるのは同業者や長年付き合っている友達だけです。これからは自分たちが持っている感覚とは違う感覚を持った人に対して説明する必要があります。
つまり「作れるスキル」と同じくらいに「話せるスキル」にも貪欲になっていく必要があります。相手の立場に立ってデザインを伝えるためにはどうすれば良いのでしょうか?その一つが批評を行うという事だと長谷川さんは仰っていました。
批評を行う
批評というとネガティブなイメージを持っている人がいるかもしれませんが、「批評」と「批判」を混同してしまっているのではないでしょうか?
 批判は確かにネガティブ且つただただ貶めるような内容です。「ちょっと、これはない」「かっこ悪い」「なんか違う」などなど。こういった発言はあまり耳を貸さない方が良いのですが、批評はより良いものにするために物事の良し悪しを議論する事を指します。
例えば、クライアントが「このボタンを大きくしてください」と言った時にそのまますぐにボタンを大きくするのではなく、クライアントが何を言いたかったのか?何を思ってそう発言したのかを考える必要があります。例えば、そのボタンが目立ってなくてクリックされないかもしれないと思ったから大きくしてくださいと言ったのかもしれません。
言葉をそのまま受け取るのではなく、その裏で何を思ったのかを考え、ときほぐす必要があります。
 もちろん考えた結果導き出した答えが「ボタンを大きくする」ならばそれで問題ありませんが、何も考えず言われた指示をそのまましてしまってはプロのデザイナーとしている意味がありませんよね。
このような意図を共有したり、課題解決のための会話が批評です。目的を定義した上でその上で会話を進めていく事が重要となってきます。
 そして人によって「良い」は違います。昨年Instagramがロゴを変更して当時炎上しました。しかし、今はもう皆慣れてしまっています。色んな人がそれぞれの価値観で意見を言ったり、感覚的な表現だけで発言したりしてしまうと批評は難しいです。
しかし、だからといって感覚的な表現が必要ないというわけではありません。データは大事ですがただデータだけで全てを反映するのはよくありません。ただ、データと感覚を共有するためには、まず前提としてデザイナーが批評ができる必要がありますし、自分たちのデザインについて論理的な説明ができるようになっておく必要があります。
批評する時のフレームワーク
さて、デザイナーは批判できる必要があるという事でしたが、いきなり批評といってもどうやってすればいいか分かりませんよね。そこで批評する時のフレームワークを紹介していただきました。
- デザインの目的- 改めて現在のデザインの目的をもう一度言います。
- 「この画面、ページはこのために作ってますよね?」
 
- 目的に関連している要素- 現在の状況を話します。
- 人によっては自分と同じように見えない場合があるので「自分にはこう見えています」という事を伝えます。
 
- なぜそう思うのか説明- 現在の状態だとどうなっているか話す。
- 解はそこで出さない。
 
ポイントは最終的に解を出さないという点ですね。解をデザイナー1人1人が考えるためのフレームワークです。例としては以下のような形です。
①お客様は気軽に製品を購入したいのに、
②長い製品情報の下にしか購入ボタンがないのは、
③他の情報によって埋もれるので効果的ではないと思う。
目的・現状・どうするべきかを確認する事ができますね。自分がデザインについて発言をする時にはこのフレームワークを意識するようにするとかなりまとまりのある意見になります。
いきなりデザインカンプで話し合わない
さて、クライアントと批評を行おうとした時にいきなりデザインカンプを見せて話し合っていないでしょうか?Photoshopなどで一見完成されたように見えるデザインカンプをクライアントに見せてしまうと、一度に「色・コピー・感覚・リズム・インタラクション・アニメーション・情報設計・操作性」など大量の要素を見てしまいます。
これだと、操作性の話をしているのに突然「ロゴ大きいよね」などビジュアルにどうしても引っ張られて議論が混乱してしまいます。
 そうならないためには、成果物に対して何を中心に持ってくるかを決めておく必要があります。聞き出したい内容にあった成果物を用意して議論を行うという事です。
| フローチャート | コンセプト・操作フロー | 
|---|---|
| ワイヤーフレーム | コンテンツのレイアウト・適切なUIが使われているか? | 
| デザインカンプ | バランス・リズム・色 | 
聞き出したい内容にあった成果物を用意した上で、自分のデザインを相手の立場に立って伝える必要があります。今回行うワークショップでは「相手の立場に立って伝える」という事について考えます。
ワークショップ
ステークホルダーにデザインに関わる課題を理解してもらい、それを解決するための解決策を採用する価値があることを伝えます。要は「こういう問題があって、それを解決するために、これがしたいからその分の予算がほしい!出してくれ!」って事を非デザイナーの方に如何に重要性を理解して貰い、予算を出して貰えるか相手の立場で考えるという事です。
ワークショップの目的
- 決済者の立場を考慮したアイデアの提案
- 様々な視点の共有
流れ
- チームでシナリオを選定
- 決済者の視点の理解と打ち合わせ内容を考える
- 最後に成果・感想を発表する
ワークショップの楽しみ方
- ワークなので若い・ベテランとか気にせず挑戦
- あえて誰かになりきるのもアリ(その方が言いたいことが言える人もいる)
- 想像力を活かして即興も大事(今回のワークでも私生活に関するところなど穴が空いている。きっとこの人ってこうだよねと想像して埋めていく。)
僕達のグループが選択した課題
僕達のグループが選択したステークホルダーは花岡さんという以下のような架空の人物です。
名前:花岡慶也さん(はなおかよしなり)
開発本部部署ジパング株式会社が運用するWebサイト、アプリの責任者で、彼がプロダクトの機能やデザインの決済権を持っています。サーバーサイドだけでなく、フロントエンドのコード変更も彼から決裁が下りなければデプロイすることができません。
花岡さんはジパング株式会社で働き始めて5年経ちます。彼がリーダーシップになってから、開発フローはウォーターフォール型からアジャイルへ移行し、早く物事が働くようになりました。より多くのプロダクトの開発と改善をしていくために、開発者、デザイナーの雇用も考えています。ジパング株式会社に入社する前は外資系企業でシステムエンジニアを10年経験しており、そのときの経験を活かして改革を続けています。
そしてその花岡さんに「ユーザー調査」をするための予算を出してもらうように交渉します。ユーザー調査を勧めたい理由としては以下の通りです。
1年以上の開発を経て、ジパング株式会社からついに新しいアプリがリリースされました。しかし、残念ながら期待通りの結果を得ていない状態です。リリース後に大々的なキャンペーンを行ったおかげで初期のダウンロード数は伸びましたが、ほとんどのユーザーは1度しかアプリを開いてくれません。この問題を解決すべく、新しい機能を追加していくプランはあるものの、具体的なところまでは決まっていないそうです。
機能を追加するなど幾つかの手段がありますが、次の一手が見えていない状態です。ジパング株式会社から相談が来たので、ユーザー調査の提案を考えています。アプリを使わない要因になっているユーザビリティの課題を洗い出し、プロジェクトチームで共有できるユーザー像を作ると方向性が明確になるかもしれません。今までユーザー調査をする文化がないジパング株式会社ですが、ユーザー調査の重要性と効果を伝えようと思います。
これらの大まかな内容は書かれていたのですが、細かい詳細はチーム内で考えながら進みました。
「花岡さんって何歳くらいだろう?」とか「そもそもジパング株式会社って何の会社かな?」みたいなのをチームで相談していきながら、イメージを膨らませていきました。
さて、今回のワークショップでは相手の立場に立ってデザインを伝えるというのが課題です。そのためには相手の事をよく考えなければなりません。そこで、「優先順位」「見返り」「圧力」という3つの観点から相手の事を考えます。

まずそもそも相手にとって優先順位が低い事を真正面から必死に伝えようとしていては重要度は伝わりませんし、相手との温度差が生まれてしまい「分かってもらえない!」となりかねません。相手にとっての優先順位は何か考えます。
そして、どんな見返りがあれば協力的になってくれるのか考えるのも重要ですよね。最後にどんな圧力(精神的負担)を受けているのかも考えます。
例えば、見返りが「社長からの信頼」の場合、圧力も「社長からの信頼」と被ってしまう場合もありますが、むしろ被った方が細かい部分まで考えられていたりします。

こうして人物像を固めて、最後にどのように提案するのか考えをまとめチームごとに発表をしました。
感想
デザインを伝える際にただただ自分の立場から話してしまっては相手にはうまく伝わりませんし、伝わらないからといって「相手がデザインについて全然分かってない」と言うだけではいつまで経っても進展はありません。
今回のワークショップでは相手がどんな立場で、何を求めていて、何を目標としているのかを考え、その上でそれも踏まえた提案を行いました。相手の立場で話すという事はデザイン制作を伝える時以外にも使える事ですし、何かしら専門的な事を行っている人には共通する事なのではないでしょうか?そしてそうする事によってより広い視野で物事を捉えられます。
何より論理的に組み立てて話をしていけるようになるのではないでしょうか?
[CSS-Nite]

 【前編】Sync & Liveで取り回す Illustrator でのデータ作り!!CSS Nite in KOBE, Vol.26
 【前編】Sync & Liveで取り回す Illustrator でのデータ作り!!CSS Nite in KOBE, Vol.26  CSS Nite in Kobe, vol.40「クライアントとのより良い関係性を築くためのコミュニケーション手法」に参加してきました
 CSS Nite in Kobe, vol.40「クライアントとのより良い関係性を築くためのコミュニケーション手法」に参加してきました  CSS Nite in Kobe, vol.41「最新ネット広告の打ち手を学ぶ1dayレッスン 〜レスポンシブ検索広告からAmazon広告、ストーリーまで」に参加してきました
 CSS Nite in Kobe, vol.41「最新ネット広告の打ち手を学ぶ1dayレッスン 〜レスポンシブ検索広告からAmazon広告、ストーリーまで」に参加してきました  CSS Nite in Kobe, vol.53「XDで作るワイヤーフレーム・プロトタイプとサイト制作時のコミュニケーション」に参加してきました
 CSS Nite in Kobe, vol.53「XDで作るワイヤーフレーム・プロトタイプとサイト制作時のコミュニケーション」に参加してきました  神戸で開催される078を盛り上げるためのアイデアソンに参加してきました
 神戸で開催される078を盛り上げるためのアイデアソンに参加してきました  CSS Nite in Kobe, vol.54「XDで作ったワイヤーフレームを元に制作するウェブビジュアルデザインと精度の高いプロトタイプをコーダーに渡すときのポイントのセミハンズオン」に参加してきました
 CSS Nite in Kobe, vol.54「XDで作ったワイヤーフレームを元に制作するウェブビジュアルデザインと精度の高いプロトタイプをコーダーに渡すときのポイントのセミハンズオン」に参加してきました  CSS Nite in Kobe, vol.52「ラクして毎日30分の時短! すぐにできるMacの作業効率化入門」に登壇してきました
 CSS Nite in Kobe, vol.52「ラクして毎日30分の時短! すぐにできるMacの作業効率化入門」に登壇してきました  CSS Nite in Kobe, vol.43「ウェブページを高速化してユーザーに価値を届けたい制作者のためのセミナー&ワークショップ」に参加してきました
 CSS Nite in Kobe, vol.43「ウェブページを高速化してユーザーに価値を届けたい制作者のためのセミナー&ワークショップ」に参加してきました  CSS Nite in KOBE, Vol.37  Adobe Creative Cloud 使い倒しテクニック集中講座に参加してきました
 CSS Nite in KOBE, Vol.37  Adobe Creative Cloud 使い倒しテクニック集中講座に参加してきました  あしたラボUNIVERSITY主催の学生限定ハッカソンに行ってきました
 あしたラボUNIVERSITY主催の学生限定ハッカソンに行ってきました  iTerm2で「Use System Window Restoration Setting」を設定しているとアラートが表示されて機能しない
 iTerm2で「Use System Window Restoration Setting」を設定しているとアラートが表示されて機能しない  Google Chromeのサイト内検索(カスタム検索)機能を別のプロファイルに移行する方法
 Google Chromeのサイト内検索(カスタム検索)機能を別のプロファイルに移行する方法  iPadで入力モードを切り替えずに数字や記号をすばやく入力する方法
 iPadで入力モードを切り替えずに数字や記号をすばやく入力する方法  iPhoneやiPadでYouTubeの再生速度を3倍速や4倍速にする方法
 iPhoneやiPadでYouTubeの再生速度を3倍速や4倍速にする方法  Keynoteで有効にしているはずのフォントが表示されない現象
 Keynoteで有効にしているはずのフォントが表示されない現象  MacのKeynoteにハイライトされた状態でコードを貼り付ける方法
 MacのKeynoteにハイライトされた状態でコードを貼り付ける方法  iTerm2でマウスやトラックパッドの操作を設定できる環境設定の「Pointer」タブ
 iTerm2でマウスやトラックパッドの操作を設定できる環境設定の「Pointer」タブ  AirPodsで片耳を外しても再生が止まらないようにする方法
 AirPodsで片耳を外しても再生が止まらないようにする方法  DeepLで「インターネット接続に問題があります」と表示されて翻訳できないときに確認すること
 DeepLで「インターネット接続に問題があります」と表示されて翻訳できないときに確認すること  Ulyssesの「第2のエディタ」表示を使って2つのシートを横並びに表示する
 Ulyssesの「第2のエディタ」表示を使って2つのシートを横並びに表示する  1つのノートアプリにすべて集約するのをやめた理由|2025年時点のノートアプリの使い分け
 1つのノートアプリにすべて集約するのをやめた理由|2025年時点のノートアプリの使い分け  Notionログイン時の「マジックリンク」「ログインコード」をやめて普通のパスワードを使う
 Notionログイン時の「マジックリンク」「ログインコード」をやめて普通のパスワードを使う  AlfredでNotion内の検索ができるようになるワークフロー「Notion Search」
 AlfredでNotion内の検索ができるようになるワークフロー「Notion Search」  Gitで1行しか変更していないはずのに全行変更した判定になってしまう
 Gitで1行しか変更していないはずのに全行変更した判定になってしまう  Macでアプリごとに音量を調節できるアプリ「Background Music」
 Macでアプリごとに音量を調節できるアプリ「Background Music」  Macのターミナルでパスワード付きのZIPファイルを作成する方法
 Macのターミナルでパスワード付きのZIPファイルを作成する方法  MacBook Proでディスプレイのサイズ調整をして作業スペースを広げる
 MacBook Proでディスプレイのサイズ調整をして作業スペースを広げる  SteerMouseの「自動移動」機能で保存ダイアログが表示されたら自動でデフォルトボタンへカーソルを移動させる
 SteerMouseの「自動移動」機能で保存ダイアログが表示されたら自動でデフォルトボタンへカーソルを移動させる  iPhoneでタッチが一切効かなくなった場合に強制再起動する方法
 iPhoneでタッチが一切効かなくなった場合に強制再起動する方法