投稿

背景

4年ほど前に、オライリーより出版された『デザインの伝え方』という書籍の監訳を担当させていただいたことがあります。

デザインの伝え方

AmazonでTom Greever, 坂田 一倫, 武舎 広幸, 武舎 るみのデザインの伝え方。アマゾンならポイント還元本が多数。Tom Greever, 坂田 一倫, 武舎 広幸, 武舎 るみ作品ほか、お急ぎ便対象商品は当日お届けも可能。またデザインの伝え方もアマゾン配送商品なら通常配送無料。

組織におけるコミュニケーション術という副題で、デザインを他者に伝える際に注意すべきギャップや、必要な心構え、そして効率的に合意形成を進めていくためのテクニックが書かれています。

なぜ、今ここで『デザインの伝え方』を取り上げるのか。私はかれこれフルリモート化により、2ヶ月弱、在宅で仕事をしています。そのため、チームはもちろん、ステークホルダーや他部署の関係者との会話は全てオンラインで完結しています。いや、完結するように工夫せざるを得ない、といった表現が正しいのかもしれません。

昨日(5月7日)にこんなツィートをしました。

フルリモートに完全移行すると、それまでのコミュニケーションに様々な変化が訪れます。例えば、相手が見えなくなる。オフィスにいる場合は、チームやステークホルダー、関係部署の人間は姿を探そうと思えば見えるのは当然のことです。しかし、オンラインでは誰が、何をしているのかが見えづらくなり不安を掻き立てます。そうなると、プロダクト開発の進め方にも影響が出てきます。その内の一つが、目に見える成果物を具体的に示さなければならなくなったことだと考えています。Before コロナは自分の成果を見える範囲で証明することができましたが、それが見えづらくなった今、自分から積極的に共有しなければならない状況にシフトしているように思います。

そのために、デザイナーはデザインをすること以上に、周囲にデザインを理解してもらうためのコミュニケーションに力を入れなければならないと考えています。

半分宣伝っぽくなってしまいますが、そこで参考になるのが『デザインの伝え方』です。

デザイン領域の特徴

専門家でもない人が専門家の仕事に意見する権限を持つーこれは現代の組織において、デザイン以外の分野ではほぼあり得ない現象です。

本書に書かれている一文です。ハッとさせられました。確かにそうかもしれません。デザイナーが手がけるインターフェースはいつの間にか組織全体の対ユーザーのインターフェースとなり、自然の成り行きとして非デザイナーとの接触機会は増えてきています。先日書いた「デザイン思考の如くー陥りやすい3つの誤解」という記事でも、創造活動としてのデザインに非デザイナーを迎え入れることができた背景について述べました。

結果として、デザインは他の分野に比べると、はるかに意見の対立しやすい分野になりました。

視覚的に目にするものであるが故に、デザインが主観的なものであると捉えられることが多く、我々の直感がデザイン上の問題をどう解決してくれているかを明確に説明できないでいます。そのため、ステークホルダーがデザイナーに注意を喚起する問題や懸念の大多数は、誤解や伝達の不備に起因しており、コミュニケーションが成立していないにも関わらず、成立したと思い込むことによって発生します。

これからのデザイナーに求められるスキルは、ステークホルダーや関係者の期待をうまく調整する能力なのです。

デザインを伝えるポイント

ステークホルダーや関係者の期待をうまく調整する能力は、素晴らしいデザインを生み出す能力よりも重要になってきます。大変ではありますが、プロダクトをデザイナーとしての視点だけではなく、ユーザーに共感するように、ステークホルダーの視点から見てみると、より良いデザイン(プロダクト)を生み出す可能性が広がってくることがわかります。

本書では、ユーザーに対する場合と同じ原理原則を紹介しており、組織におけるステークホルダーとのコミュニケーションにも適用する方法について述べています。デザインを理解してもらうためのコミュニケーションは、デザインそのものよりも重要であり、冒頭で述べた通り with コロナの今は尚更です。

ステークホルダーないしは関係者にデザインを伝える際のポイントは3つあります:

  1. このデザインはどのような問題を解決できるのか?
  2. このデザインはユーザーにどのような影響を与えるのか?
  3. このデザインが代替案よりも優れている理由は何か?

お気づきでしょうか。実はこれ、ユーザーにも同じことをデザインを通して伝えているはずなのです。

  • このデザイン(プロダクト)はあなたのこの問題を解決することができます
  • このような価値を提供することができます
  • 他のデザイン(プロダクト)よりも、こっちの方が優れている理由はこちらです

前述の通り、組織におけるステークホルダーや関係者とのコミュニケーションは、ユーザーに対する場合と同じ原理原則を当てはめていることがわかります。

悩んだら、相手の裏側を引き出す質問を準備しておくのも有効です。以下が本書で挙げられた例です。

  • どんな問題を解決しようとしているのか?
  • この方法で行なった場合、どのような利点があるのか?
  • これは、このプロジェクトの目標にどんな影響を与えるのか?

これらの質問は、ステークホルダーとのコミュニケーションにおいて実はマストだったりします。と言うのも、オンラインだとどうしても存在が薄れて声が小さくなってしまう人が出てきてしまい、気軽さも欠けてしまってフォローアップが困難だったりするからです。その場合は、ややくどいぐらいに明確にしておくとコンセンサスは取りやすいかもしれません。

偉大なデザイナーは、偉大なコミュニケーター

偉大なデザイナーは、偉大なコミュニケーターという章があります。デザイナーは、ユーザーとの接点を担う人です。そのため、多くの関係者と会話しなければいけないのは必然であり、それは理解しなければなりません。そのため、平等に意見を言ったり質問をすることに、躊躇してはならないと思います。私の経験からしても、上で紹介されているような質問を聞く権利は新卒だろうと、新しく入ってきた中途だろうと、誰でも聞く権利はあります。逆に耳を貸してもらえない組織は、おかしいと思います。

最後に、本書では、デザインの伝えるときの心構えとして、IDEAL というコンセプトを紹介しています。

  • Identify the problem:問題を特定すること
  • Describe your solution:解決策を説明すること
  • Empathize with the user:ユーザーの気持ちになること
  • Appeal to the business:組織にアピールすること
  • Lock in agreement:合意を確実に取り付けること

合意が得られれば単なる IDEA(アイディア)を持っている段階から、本当に理想的な(IDEAL)なプロダクトやサービスが生み出せる段階へ進むことができるのではないでしょうか。

非デザイナーの方へ

本書の最後の方に、デザイナーと仕事をよくする非デザイナーの方向けの言葉があります。デザイナーと仕事をするときに、ぜひ心掛けて欲しいと思います。そうすれば、今まで以上に共創できるはずです!

  • 焦点を当てるべきは「デザインの好き嫌い」ではなく「デザインの有効性」
  • 解決策の提案はせずに、理解のための質問をする(それもいくらでも)
  • 「自分もユーザー」という考え方は捨てる
  • デザイナーの説明をちゃんと聴く
  • デザイナーにも決定権を委ねる
  • 言葉使いを丁寧にし、フラットな関係を保つ
  • 裏付けとなるデータの有無を尋ねる
  • デザイナーが成果を上げるのに必要なものを漏れなく提供する

最後まで読んでいていただき、ありがとうございました。

はじめに

本記事は、ユーザーリサーチを批判することを目的に書いた記事ではないことをご理解ください。私自身の経験をもとに、ユーザーリサーチの可能性を広げるためのアプローチをご紹介し、リモートでユーザーリサーチを行っている、またはこれから行う人にとってお役に立てればと思っています。

私は今、フルリモートで仕事をしています。プロダクトマネージャーとして不慣れなところが多く、何が正解かわからないまま進めている状態ではありますが、完璧な正解を求めるのではなく、今のプロダクト開発に価値を届けられるかどうかで判断すべきだと最近は考えるようになりました。

イントロ:ユーザーリサーチとは?

さて、プロジェクトをフルリモートで進めていくにあって頭を悩ませている内のひとつが、ユーザーリサーチを実施するための「環境の構築」です。簡単なイントロとして、ユーザーリサーチには様々な目的があります:

  1. ユーザーと課題発見のため
  2. 価値探究と価値評価のため
  3. 使い勝手を検証するため

それぞれの目的に合わせて、ユーザーインタビューや定量調査、ユーザビリティテスト、A/B テストなどの手法を用いるのがユーザーリサーチです。

(1)では、想定しているユーザーはマーケットに存在するかどうか、そしてそのユーザーは想定していた課題を抱えているのかどうかを探るためにあります。

(2)は(1)の結果を踏まえて、課題を解決するためのアイディアを目に見える形に落とし込み、実際に触ってもらいながらソリューションの方向性を定めるために実施します。

あとは作るだけなのですが、同時にユーザビリティの検証をしながら「使いやすい」ソフトウェアに仕上げなくてはならないため、(3)も必要です。

例えば、新規でプロダクトを開発するシチュエーションにいると仮定しましょう。その場合、フルリモートでユーザーリサーチを実施するときのハードルになり得るのは、(2)と(3)です。なぜなら、実際のモノ(プロトタイプやソフトウェア)を被験者に触ってもらいながら、観察をする必要があるからです。

ペルソナと、解決すべき課題の特定がある程度できた状態で、プロトタイプをしながら(2)に進むことにしましょう。

リモートでユーザーリサーチを行うリスク

理想的なセットアップは、被験者の隣にインタビューワー(インタビューをする人)が座り、被験者がプロトタイプを触っている様子を観察しながら質問やガイドをし、仮説が正しかったのか or 間違っていたのかを検証するためのインサイトを抽出することです。

しかしそれは、「こちら」が用意した環境、例えば端末やネットワークを利用していることが前提にあります。被験者が在宅でリモートによるユーザーインタビューを行うときによく直面する問題は、被験者が持っている端末と自宅のネットワーク環境に左右される「被験者の環境に完全に依存してしまう問題」です。ちなみに、それぞれの物理的な距離はかなり遠い場合は、「では、近くのカフェでやりませんか?」なんてプランBはそもそも通用しません。では、どのようなことが起こるか。

「フルリモートではユーザーインタビューが成り立たない説」

水曜日のダウンタウンです。はい。被験者の方々に事前にご自身の環境について伺ったところ、驚きのニュースが多数寄せられました。

PC 端末が社用のため、申請していないツールが使えない

自宅のネットワークが遅く、テレビ電話の精度が悪い

なるほど。心の中では「まじかよ」状態です。このまま行けば、説が立証されてしまいます。なぜまずいかというと、プロトタイプを開くためにツールが必要なのであれば、そもそも見ることができないからです。ましてや、同業者でない限り私たちが利用するツールを申請してインストールしているとは思えません。つまり、インタビューで利用するプロトタイプが見れない可能性が高い。

そしてもう一つ。テレビ電話の精度が悪いと、発言が途切れ途切れになってしまうことが多く、向こうもこちらもストレスになり、要約されてしまったりして、諦めてしまうことが考えられます。それでは、ユーザーインタビューの目的が達成されず、形だけのインタビューになってしまいます。

リスクよりも、チャンスを見る

それぞれのリスクを低減するために、以下のようなアプローチを取りました:

  • プロトタイプを触ってもらえないリスク:figma のオブザベーションモードを使いながら Zoom のスクリーンシェア
  • テレビ電話の精度が悪くインタビューできないリスク:昔ながらの電話をする

私は最近まで知らなかったのですが、figma  の同じプロトタイプ URL を参照している人であれば、画面をミラーリングし、カーソルの動きと画面遷移を把握することができます。その動きに合わせて、電話でインタビューをするという戦術です。これがとてもいい。

Figma feature highlight: Observation Mode

At Figma we suspect some of our small (but mighty!) power features go unnoticed. In fact, after prodding our Twitter community this week, several users were surprised to learn we have a little something called “Observation Mode.” We’re going to highlight more of these semi-secret use cases on the blog and figured Observation Mode was a good place to start.

むしろ被験者の隣に座って観察しながらインタビューするよりも、画面内の行動や心理状況を的確に把握することができます。余談ですが、この仕掛けについて知っている被験者は数少ない。そのため、「え、私がやっていることがわかるんですか!?どうして?」と不思議がられることが多く、ちょっと自慢げになっています。

電話は言わずもがな。リモートの場合、これはマイナスではなくプラスに働くことが実は多いです。なぜなら、テレビ電話は正面を向いて話しているため、被験者は躊躇してしまって実は話にくかったりします。顔見知りだったら別ですが。電話の場合は普段から利用しているということもあり、発言も自然に出てきます。つい長電話してしまいましたね、という穏やかな雰囲気で終われるところがまたいい。

最低でなくても、最高は目指さなくてもいい

これを整えることができれば、ある程度(2)で辿り着きたいゴールに到達することができます。最低な環境でのユーザーリサーチですが、最低限のユーザーリサーチは実施することができることがわかりました。

(3)の使い勝手を検証するためのユーザーリサーチをどうするべきかはまだ考えてもいません。でも、シンプルにできることは何か、を念頭に置くことができれば、できるような気がしてきました。シンプルに考えるためには、とりあえずやってみること。上に書いたように、古典的なやり方でも成立はします。時間をかけて理想的な環境を整えるよりかは、プロダクト開発におけるメリットはより大きいかもしれません。

最後に、ユーザーリサーチを計画し、実施する際に意識していることは、良いユーザーリサーチは良い結果が出たから良いというものではないということです。良いユーザーリサーチは、ユーザーが求めていた価値(機能やデザイン)が提供できたかどうかで判断すべきだと考えます。

プロセスやツールよりも個人と対話を

アジャイルソフトウェア開発宣言の一文です。アジャイル開発を継続するための重要なファクターの一つに、コラボレーションがあります。同じ場所(環境)に身を置くことで、より高い生産性とより早い意思決定が可能になることは既に多くの研究や事例によって明らかになっています。私がいる会社でもそのようなモデルでクライアント・ワークをしていますが、私もそう思います。

ただし、それはオフラインに限った話であって、今回のようにコロナウイルス(COVID-19)の拡大に伴う在宅勤務の推奨によってオンライン環境を余儀なくされた場合はどうすればいいのでしょう?私自身も初めてだったため、戸惑いはありました。それは自分だけではないと思います。生産性も落ちました。ただ、それはある意味オンラインにおけるコラボレーションは本当に有効であることの裏返しでもあります。むしろ、視点を変えればリモートワークはアジャイルなチームと相性が良いのではないか、とも思うようになってきました。これは錯覚なのでしょうか?確かに外の空気をたまに吸いに出ないと頭がおかしくなりそうなときはありますが、そうではないと願いたい。

私の場合、リモートワークはプロジェクトの開始とほぼ同時に始めたため、幸いにもいろいろ試行錯誤をする余地がありました。結果、比較的効果が見込める取り組みがいくつか見えてきたので、参考になればと思い、いくつかご紹介したい。

何ごとも優先度をつける、徹底的につける

これは何もバックログに限った話ではなく、ユーザーリサーチのためのリクルーティングや日々のTodoまで、チームとして、または個人として今優先すべきことは何か?と問い続けることで、価値を見失わないでいられる効果があります。

リモートだとどうしても一定の距離ができてしまうため、ある種の「許し」が無意識に生まれてしまう。ペースを維持しようにも、心情が相手に伝わらないときがあります。そのときは、私が率先して「嫌な役」を演じ、優先度が徹底されているか、チームに問うようにしています。悪いことはしていない(と思う)。より悪くならないようにしているだけ。

小さなチームで柔軟に動く

現状、クライアントとのコミュニケーションは常に Zoom で接続しながら進めています。そんな働き方です。元々オフラインではコミュニケーションコストがかかるため、大勢の人を招いたミーティングを開催しないように調整はしていますが、オンラインになるとそれが途端に楽になります。MAX 8人までで、良く接続するメンバーは4人と抑えているため、必要であればプロジェクトのロードマップも変更しますし(これは最近あった)、アイディエーションもその場でやってしまうこともあります。

オンラインに移行したことで、多くの人は気付き始めたのではないでしょうか。メールって何でこんなに面倒なんだ。このミーティングって必要なのか?多くはなくても成立します。

先を見据えて計画立てて動く

これはプロダクトマネージャーとして気をつけていることなのですが、オンラインで繋ぎながら作業をしていると、オフラインよりも集中力を使うため、つい手元の作業に没頭してしまいがちです。

何のためにやっているのか?最終的なアウトプットは何か?ミーティングだろうが、作業だろうが、ゴールとアウトプットの認識が揃っていなければ、共通のビジョンに向かって歩むことはできません。それを常に頭に入れ、逆算して組み立てるようにしています。それができていないと、たださえ公私混同しがちなリモートワークでだらけてしまい、つい残業、なんて目に見えています。

チームメンバーに奇想天外な役割を与えてみる

役職や職種としての役割ではありません。どちらかと言えば、チームビルディングの一環として取り入れる文化的要素に近しいです。

私がいるチームでは、以下の役割をそれぞれに割り振り始めています。名前のセンスはさておき:

  • 仕分け人:チームが不必要な話題に時間を費やしている場合にカットインする人。「それ、あとにしましょう」な人。
  • タイムキーパー:そのままの意味で、チームで行う様々なアクティビティの時間を管理する人。時間を過ぎたら容赦なく切る人で「はい、タイムアーップ!」が口癖。
  • Zen マスター:チームメンバーの疲労具合を見て休憩するタイミングと時間を決める人。この人の発言には注目だ。「とりあえず、休憩しますか?(^ ^)」救われる。
  • エンターテイナー: 一番ハードルが高いのだが、チームの雰囲気を明るくするための取り組み(ゲームやソフト)を紹介する人。最近、私は Snap Camera をチームに導入して大ヒット中。

順調そうに思えるが、苦労するポイントはたくさんあります。最も難しいと思ったのは、メンバー間の Empathy(共感)です。リモートという環境要因もあると思いますが、オフラインのときとは違い、口数が少なくなったり、思うように聞こえなかったりすることでイライラしやすくなった人もいます。

私も場合によっては当てはまるかもしれませんが、相手が今どのような状況下にいて、どんな心境でこの話を聞いているのかを理解してあげなければ、伝わるものも伝わりません。

Transparency(透明性)の維持。これも難しい。オンラインだとどうしても構えてしまいます。正面を向いているからでしょうか。初対面の人との会話だと、面接のような空気を醸し出すときもあるし、無駄に緊張してしまうこともあります。その場合、思っていることや考えていることは発信しにくい。それを回避するために、どうでもいい話題を投げかけてみんなが参加できる安全地帯を作ってあげることが大事だったりしますl。

そう、リモートワークで大事なのは、1) 人を思いやる優しい心2) 安全地帯の確保なんだと思います。ハードよりも、ソフトだと思います。

僕がいるんだ、みんないるんだ、愛はここにある、君はどこへもいけない。

どうでもいいけど、リモートワークを8時間も続けていると、Zoom に接続する度にリンクスタート!している気分で、ある意味気持ちがいい。