こんにちは。rootの岸です。

デザイナーの皆さんはプロジェクトを進めていく中で、自分が懸命に考え抜いたデザインの過程がうまく伝わりきらなかったり、表現の一部だけが議論の対象になってしまってモヤモヤすることはありませんか？

組織におけるデザインの相互理解が不十分なことによる不幸なすれ違いが、様々なプロダクト開発の現場で起こっています。今回は、こうしたすれ違いをなくすために思考したことを共有できればと思います。

デザインに対する相互理解が不十分な状況で起きる課題

まず、私が経験したエピソードを共有します。ある新規サービスのLPの制作において、良かれと思って行ったワークショップや分析がうまく相手に響かず、デザインの価値を伝えきるには至らなかったという経験があります。

このプロジェクトで、私はサービスのもつ特性や雰囲気をワークショップによって明らかにし、情報設計、ワーディング、トンマナの方向性を丁寧に決めていきました。もちろん、私たちはデザイナーなので、これらが成果に結びつくものであり、LPの公開後も運用されるべきものでもあると考えていました。

もちろん、それぞれの工程が、最終的な成果に対しどのような影響を与え得るのかを伝える努力はしました。しかしこれらの中間成果物は、サービス運用の上では価値を出せていません。制作の上での論理や考え方は、クライアントに本質的には受け入れられていなかったのかもしれません。

つまり、デザインに対する相互理解を形成する土壌ができ上がらないままことを進めてしまい、最終的にサービスの主体者たる事業責任者や担当者、開発者に対して、デザイナー側の価値観や視点がほとんど何の影響も与えられていなかったということです。

このような出来事は、デザインを引き受ける人にとって、決して珍しいことではないように思います。

デザインの理解を妨げている3つの要因

私は同じ問題意識をもつチームメンバーと、プロジェクトの振り返りを行い、この問題を引き起こしている3つの要因を見出しました。

1.事業責任者や担当者、開発者との共通言語を持てていなかった。
制作の過程をデザイナーにしか通用しない言葉だけで説明してしまっていました。これにより、私たちがサービスのために何を大切にしたのか、事業責任者や担当者、開発者が何を大切にしているのかについて、お互いの理解が曖昧な部分を抱えたままとなってしまいました。

2.相手の期待値を超える成果物の提示が出来ていなかった
例えば、成果を重視する相手に対しては、まず「相手の考える成果」をもって応えるべきです。本質的な問題と目先に見えている成果物が異なる前提であったとしても、まず目先に見える成果物を示すことで期待値を超え、本質的な問題へアプローチする、という手順が妥当でしょう。

3.議論すべき内容、提供する情報やその共有方法が、事業責任者や担当者、開発者の性質とはずれていた
プロジェクトにおいては、デザイナーがよく利用するソフトウェアやフレームワークを用いて説明を行いましたが、それらはそもそも理解のハードルが高く、まして自分たちで使うことなど通常は出来ないものです。内容も方法も、相手の理解の形に合わせるのがより良い選択肢でした。

組織にデザインを浸透させる第一歩を踏み出すために

振り返りを通じて得られた、これらの要因についてメンバーと議論を重ねました。その結果、「組織」と「成果」そして「プロジェクトの進め方」という3つの要素と、それぞれの性質を考慮した関係性のあり方について気を配ることが、組織にデザインを浸透させる第一歩なのではないかという洞察を得ました。

ここでの言葉のイメージは、以下の通りです。

組織：デザインの対象となるサービスを運用する事業責任者や担当者、開発者のことです。

成果：最終的な成果目標や成果物、あるいはプロジェクトの過程において達成したい目標を指します。

プロジェクトの進め方：開発手法のような大きなものから、ドキュメントの体裁に至るまで、どのような形式で物事を進め、情報をどう共有するかということです。

それぞれの要素には、各事業ごとに特徴的な性質のようなものを見出せるはずです。例えば、組織が大切にしているのがスピード感なのか、チームの和なのか、といった具合です。

こうした性質を考慮にいれることで、相互理解をスムーズに進めるための土台をより作りやすくなります。ここで、それぞれの関係を例にとって考えてみます。

1.組織の性質と、成果の性質の関係
例：スピードを重視する、成長の最中にある組織が、根本的なサービスのリニューアルを行う場合、成果を適切に分解するのと合わせて、まずスピード感や開発までのイメージをすり合わせることをプロセス上の目標する。

2.組織の性質とプロジェクトの進め方の性質
例：成果を重視する、タテの関係が強い組織に対しては、デザインを決定するための抽象的な議論は程々に「結局何が生まれ、それがどう活きるのか」という議論を軸に行い、多少工数がかかったとしても、資料は先方が内部で提案しやすいようなドキュメントにまとめる。

3.成果の性質とプロジェクトの進め方の性質
例：問い合わせの数を重要指標としたLPの制作において、問い合わせ数に寄与する要素の把握や再現、検証をあらかじめプランに組み込んでおく。
※この関係は当たり前のことであり、また組織の性質とは直接的に関係しませんが、プロジェクトにおいて相互理解を育むための拠り所となる部分なので、強く噛み合っている必要があります。

これらの3つがしっかりと噛み合う提案が行えれば、プロジェクトが終わるまでに「どのようにサービスにデザインが活用できるのか」について、相手とこちらの意識をすり合わせられ、デザインに対する相互理解も深まります。

そしてデザインに対する相互理解が深まれば、それだけ組織におけるデザインの前提知識が豊かになり、結果的に事業課題とデザインの強い紐付きを示唆できることでしょう。