投稿

はじめに

イノベーションに関するイベントのタイムテーブルに目を通すと、約9割くらいの確率でデザイン思考という言葉を目にするようになりました。現在半額セール中の amazon のカテゴリ別(ビジネススキル)1位も、デザイン思考関連の書籍です。(2020年5月4日時点)

なぜ、このようにデザイン思考が注目されるようになったのでしょうか。歴史を振り返ってみると、IDEO と言う企業の存在は欠かせません。IDEO は、世の中への影響や貢献度の高い企業の内の一つとして知られています。

先ず、約20年前(もうそんなに経ったのか…)に発売された書籍『発送する会社!ー世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法』でその名を社会に広げ、『デザイン思考が世界を変える―イノベーションを導く新しい考え方』でデザイン思考がイノベーションを起こす起爆剤になり得るという風潮を作ったことが背景にあります。

今、改めて IDEO のサイトを見ているのですが、デザイン思考の専門サイトが開設されており、デザイン思考を学ぶための教育コンテンツが盛り沢山で驚いています。

Resources

Design thinking simultaneously considers what is desirable from a human point of view, what is technologically feasible, and what is economically viable. It also allows people who aren’t trained as designers to use creative tools to address a vast range of challenges.

私も実は、この中で紹介されている IDEO U というビジネスマン向けのオンラインコースを受講したことがあります。IDEO の中の人がメンターとしてサポートしてくれるので、心強かったです。オススメ。

さて、デザイン思考というと、下記のような図を一度は見たことがあると思います。これは、IDEO の創設者であるデビッド・ケリー氏が創設した Standford 大学の d.school が提唱する5つのステップであり、デザイン思考を説明する際に最も参照されている図と言っても過言ではありません。

このように、デザインのプロセスが公式化されたことで、結果として非デザイナーをプロセスに迎え入れることができるようになりました。この功績は、非常に大きいと思います。デザイン思考は、普遍的なプロセスとしてイノベーションを実現するための鍵となる問題発見&問題解決に適用できると今日まで考えられてきました。

ただし、実際のところ蓋を開けてみると、デザイン思考で説明される言葉と、実際にデザイナーが用いる言葉を並べてみると、そこにギャップがあることが伺えます。

例)予算、社内政治、マイルストーン、工数、組織文化など

「Design Thinking is Bullshit」という衝撃的なトークをぜひ見てください。デザイン思考に対する彼女の批判はこれからのデザイン思考を語る上では欠かせないはずです。

ここで言うギャップは、私は「デザイン思考の実践で陥りやすい誤解」と理解しています。この記事では、デザイン思考の如く取り組む際の誤解を紹介するとともに、回避策についても述べたいと思います。

デザイン思考で陥りやすい3つの誤解

誤解その壱:ユーザーの声を反映すれば、うまくいく

単純過ぎますが、ここで注意すべきは、誰の声(WHO)か、何を(WHAT)拾うか、そしてどのように(HOW)ユーザーの声を拾うのか、と言う問いに対する答えを持ち合わせているかどうかです。

一言にユーザーの声と言っても、ユーザーは大勢いるが?どうすればユーザーの声を拾えるのだろうか?そして、どのような形式を採用すれば的確なニーズを抽出できるのだろうか?この答え無くして、ユーザーの意見を反映すれば失敗はしないという保証はできないはずです。なぜなら、ユーザーリサーチで大切なのは、優先度付けだからです。それでは、それぞれの問いを詳しく見ていきます。

誰の声を拾うか(WHO):ユーザー像を明確にする際には、ターゲットとなるセグメントの中でも、特に集中したい人物像のペルソナを設定する必要があります。そうすることで、従来のセグメンテーションとは異なり、より深く、そしてより実感が湧くようになります。

ペルソナで思い出したのですが、atama+ という企業ではペルソナの擬人化を徹底するあまりに、3D 化してしまったのだとか。ここまでする必要はないと思いますが、一度オフィスに遊びに行かせていただいたときに、大変興味深い光景を見ました。打ち合わせ中の社員が、ユーザーを名前で呼びながら、会話をしていたのです。ここまで浸透していると、効果は絶大です。

AI先生『atama+』開発におけるユーザー像「ペルソナ」を公開

atama plusは、「教育に、人に、社会に、次の可能性を。」というMissionのもと、生徒が「基礎学力を最短で身につける」ことを目指してAI先生『atama+』を全国の塾・予備校に提供しています。 プロダクト開発において、Valuesとして掲げている「Wow students …

何を拾うか(WHAT):リサーチの中身のことです。ここからは、イメージがしやすいインタビューに話を絞っていきたいと思います。この記事を読んでいるみなさんは、普段のインタビューではどのようなことを聞いていますか?また、インタビューに至るまでどのような過程を得ていますか?

インタビューは、学びを得る場です。そのようにインタビューを位置付けることで、チームで次のインタビューに向けて話し合う場で、学びを最大化するための質問内容が自然と絞られていきます。発散し過ぎてしまうと、あれもこれも聞きたい内容が多すぎで、インタビュー時間が超過してしまったりします。また、急ぎすぎて試合終了後の選手インタビューのようなテンポの Q&A になってしまいがちです。ユーザーインタビューは、時間が限られている。そうならないようにするためには、優先度をつけることです。優先度付けは、インタビュー設計の時から始まっています。

どのように拾うか(HOW):ユーザーの声を抽出するための方法は様々です。そのため、どれが一番ベストな選択なのか、悩んでいる人も多いはず。そこで推奨したいのは、2軸を用いた整理です。以前、2軸を使ったプロダクトデザインにおける意思決定の方法「2×2」について紹介しましたが、今回も同様な取り組みが可能です。私が過去に取り入れた軸に以下があります:

  • コスト
  • 時間
  • 母数

この軸で整理することができれば、どの手法が今の状況におけるベストな選択肢なのか自信を持って判断することができます。ユーザーの声を可能な限り、なるべく取りこぼさないようにしたいから、と言う理由で安易に母数が多い手法を選択しても、プロダクトのためにならないこともあるため、注意が必要です。

誤解その弐: アイディアは多数決で決めたほうが、失敗するリスクは下がる

デザイン思考といえば、ポストイットが壁一面に貼られていて、その前に大勢の人が集まっているシーンを思い浮かべる人が多いと思います。

これは、参加しているメンバーのアイディアを発散し、収束させる過程の内のひとつですが、ここので注意すべきは、「お任せ民主主義状態」にならないことです。自身の書籍『サル化する世界』で内田樹氏はこう述べています。

民主主義は多数決ではなく、多様な意見に対する合意形成の上で成り立つもの。できるだけ多様な立場の人を合意形成の当事者に組み込む必要がある。

大切なのは、公正性です。それはつまり、全てのアイディアにチャンスを与えることです。誰が発言したか、誰のアイディアかで判断を任せるのではなく、アイディアが優れているかどうかで判断するための発想です。公正なプロセスとは、お互いの意見を尊重し、一人が主張するものであれば、多数が主張するものであれ、最高のアイディアを求め続けること。もう一度言いますが、この人が言ったから、とか少数の意見だから、と言う不公平な扱いをしないことです。それでは、「自分の意見が受け入れられる、または受け入れてもらえる」と言う心理的安全性の環境を作り出すことができません。

アドバイスの一つは、その場で改善案を出さないようにすることです。最初に、理解のための質問をします。アイディアの一つ一つに目を通し、全員の理解が揃っている前提を作ってください。決して価値観を押し付けない、いいところも指摘してください。その後、上でも紹介したような2軸の意思決定方法を用いることができれば理想的です。

誤解その参:プロトタイプで問題がなければ、使ってもらえる

プロトタイピングツールはここ数年で劇的な進化を遂げました。過去の記事「最低なユーザーリサーチ:リモートのリスクを減らすためのアプローチ」でも述べた通り、リモート環境下でも円滑にプロトタイプを使ってインタビューすることができる時代にいます。昔は紙芝居程度ではあったのに比べて、あたかも本番稼働しているかのようなインタラクションや画面遷移を実現できたりします。本当に凄い。

最低なユーザーリサーチ:リモートのリスクを減らすためのアプローチ | mariosakata.com

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

だた、ここで注意すべきはアイディアを忠実に再現することができるが故の甘えです。プロトタイプの目的は、上で述べた「何を」が明確にならなければ、ただ単に確認のためのチェックになってしまいます。ユーザーのニーズを無視してしまいがちです。この機能はあったら使いたいと思うか?使いやすいか?このような誘導的な質問をする場を何度も目撃したことがあります。こちら側が求めている答えをユーザーから引き出す、なんとも都合がいいインタビューなのでしょう。

その場で問題がなく、期待通りの回答がユーザーが得られたなら、リリースしても問題はさほどないだろうという甘い考えは、捨てた方がいいと思います。将来のことはユーザーにだってわかりません。現時点で例え「欲しい」と言及していたとしても、実際のところはその場にいないとわからないもの。成功の確率はもしかしたら上がるかもしれないが、決して保証するものではありません。

最後にもう一つ

もう一つ誤解を招きやすいのが、デザイン思考は順を追って進めていく段階的なアプローチで、リリースしたらプロセスは終了、と考えてしまいがちなところです。しかし、ソフトウェアはずっと生き続けます。ユーザーも、使い続けます。では、作り手は手を休めていいのでしょうか?

リリースした後も、その壱で挙げたように何を学びたいか、何を検証したいのかを再度整理することで、その先につなげることができます。仮説も、よりシャープになっていきます。向かうべきプロダクトの方向性も明確になっていきます。チームの自信につながっていきます。イノベーションにグッと近づいていきます。直ぐに答えを求めてしまいがちな我々ですが、一度のサイクルでうまく行ったのなら、こんなに苦労はしないでしょう。

そういえば、この記事では「デザイン思考」と言う言葉を20回以上も使いました。くどい記事になってしまいました。最後まで読んでいただき、感謝です。

はじめに

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

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

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

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

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

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