デザイン思考で行こう!

Life will find a way, we'll find a way technology lives.

2014年04月

昨年7月に「これからデジタル(モバイル、ソーシャル、クラウド、ビッグデータ)のビジネス環境の中でマーケティングに取り組んでゆこうという人に示唆を与えてくれる」本として紹介したカナダのTwist Imageというマーケティング(コンサルタント)会社のミッチ・ジョエルという人の書いた本が翻訳され出版されていた。

原書"Ctrl Alt Delete: Reboot Your Business. Reboot Your Life. Your Future Depends on It. "は日本ではKindle版が購入できなかったが、この邦訳版は始めからKindle版が用意されている。このブログで紹介した「功利主義マーケティング」を提唱している本でもあり、特に前半はデジタルマーケティングを志す人にはお勧めしたい。この邦訳版をグーグルブックスで立ち読みしてみたが翻訳も自然でわかりやすそうだ。マーケティングに関する洋書はもともとの英文がまわりくどかったり表現が難しかったり、一文が長くて翻訳しにくかったりする傾向があり、訳者にマーケティングについての理解がないと邦訳版がさらに難解になるケースが多い。こちらはテンポよく読めそうだ。邦題よりは"Ctrl Alt Delete"の方がおしゃれだとは思うが。

さて前回の続きになる。
HCDのプロセスで用いられているペルソナ/シナリオ法を用いて「まだ存在しない未来の製品が提供されたときの人々の生活」というユーザーストーリーを文章で描く。そのLTF(Look to The Future: 未来をのぞいてみる)をいろいろな人に読んでもらってコメントをもらう。
concept disign

このコンセプトデザインのプロセス図に示したように、LTFアンケートの回答を分析し、理解力と想像力と柔軟性を発揮してインサイトを読み解く。そしてコンセプトに対するフィードバックによって戦略マップを評価し必要に応じて見直しをかける。そして、アンケートに対する回答の分析から、新しいサービスに対してユーザーが要求する機能を洗い出して要件マップを作成する。簡単に書いたが、この2つの作業は非常に重要であり慎重に行う必要がある。自分が考えたアイデアを正当化しようという潜在意識が働いてしまったり、ネガティブな意見に正面から向き合うのを避けてしまったりする。前回も書いたが、そのアイデアを守ろうとするのではなく育てようとする気持ちが重要だ。すべて、思い込みを気づかせてくれる貴重なコメントかもしれないと考えてみよう。

戦略マップとは、新しい製品やサービスのコンセプトを視覚化したもので、検索してみればわかるようにいろいろな描き方がある。僕が使っている下のような表現方法は、ブルーオーシャン戦略で戦略キャンパスと呼ばれるものと似ている。特にWebサービスやモバイルアプリケーションのコンセプトを視覚化するには、競合のサービスとの違いを明確にしなければならない。どこがユニークなのか、どこが同じなのか。ユニークな点はユーザーに受け入れられ評価されるのか。同じ点では競合に優ることができるのか。何しろユニークでなければサービスをつくる価値はない。ユニークであってもユーザーに受け入れられなければ提供する価値はない。
この戦略マップの比較項目を意識してLTF(ユーザーストーリー)を描く。その訴求部分に対する反応も冷静に分析しよう。
strategy map

実は、現在取り組んでいるプロジェクトで、最近LTFアンケートを実施した。4つのLTF(ユーザーストーリー)についての40名ほどの回答者からのコメントをプロジェクトで分析しながら、並行して実際のアンケート用紙のコメントを何度も読み返した。同じプロファイルの人(例えば子供がいる30代の女性だけなど)のコメントや、1つのストーリーだけについてとか、読み方や順序を変えるだけで違った印象になったりした。要件マップを作成するために「新しいサービスに対してユーザーが要求する機能」を洗い出す過程で、そのコメントのインサイトが読みとれたと感じたこともあった。そしてLTFを実現するために、まず解決しなければならないことを発見した。それは驚いたことに(笑)、自分自身が何年も取り組んでエキスパートになっているはずのドメインにおいて、そんな基本的なこと(問題)になぜ気づかなかったのかというべきものだった。
例えば、上のコンセプトデザインプロセスの"What"が「1000曲を持ち歩くことができる携帯ミュージックプレイヤー」だとして考えてみる。それまでのCD-Walkmanでは得られなかった新しい未来の体験のストーリーをLTFに描いてアンケートを実施したとしよう。「そんなに大量の音楽を持ち歩いてもしょうがない」といったネガティブなコメントを読んでエンジニアのあなたはどう思うだろうか。企画部門のビジネスピープルやデザイナーであるあなたはどう思うだろうか。その回答者はどんなシーンをイメージしてコメントしたのだろうと考えてみるだろうか。大量の音楽をどうやって整理するんだろうと考えてコメントしたのかもしれない。あるいはどうせ流行りの音楽しか聴かないからと思ったのかもしれない。そんな大量の音楽から検索するのは大変だと考えたのかもしれない。その人は実際に言っていないことかもしれないが、あなたが「1000曲を持ち歩くことができる携帯ミュージックプレイヤー」というコンセプトを考えた時、そういった課題をすべてイメージできていただろうか。実際にはAppleの優秀なデザイナーやエンジニアは、すでにクリックホイールやシャッフルやジーニアスなどのアイデアを持っていたと思うが、「大量の音楽を持ち歩ける」という機能には同時に大きな課題が伴う。それを解決しなければ新しいユーザー体験を提供することはできない。「大量の音楽を持ち歩ける」という画期的と思える発想をしてしまうと、そのメリットだけに目を奪われてしまい、解決すべき課題に気がつかないことも大いにあり得る(僕のように)。LTFアンケートを表面的に分類整理するだけでなく、いろいろな角度からインサイトを読み解くように心がけるべきだろう。この場合はプレイヤーの機能を考えるだけではなく、音楽というコンテンツ自体が持つ価値や力まで立ち戻ってみることも必要だと思う。

戦略マップとは、線と端子が入り組んだチャートやマインドマップといわれる神経細胞のようなものを指していることが多い。なんどか試してみたが僕にはどうも合わないようだ。脳の中のように複雑になってしまうのだ。そんな複雑なものを脳の中からそのままドロッと取り出したところでどう扱ったらいいのかわからない。そのままドロッと脳の中に戻すしかないのだ。脳の中の複雑なアイデアを断片的にいくつも二次元の紙の上に表現して記録し、それを言葉で補いながら人と共有したり、それを再度脳の中で組み立て直すという作業のほうがあっている。
単純化することはある意味危険を伴うが、自分で扱っている限りはその危険を回避できる。

記事の更新はTwitter (@kyosukek)でお知らせします。
このエントリーをはてなブックマークに追加

では、ここまでの人間不在デザインを人間中心デザインに転換しよう。
 
HCDでは、まず解決すべき問題を設定し、ユーザー調査とニーズ分析によってユーザーの行動と感情を理解し、設定した問題の原因やユーザーのニーズを発見してからデザインのコンセプトをまとめる。前回紹介したISOで規定されている「人間中心設計(HCD)プロセス」のステップ(とメソッド)は次のように図示できる。
hcd-step
この場合最初の取り組みは、現在の製品やサービスのユーザーの利用状況の理解と明示ということになる。
Tom Kelleyによる"The Art of Innovation: Success Through Innovation the IDEO Way"の中で、IDEOで実施されているデザイン思考のプロセスの5つのステップにおける「利用状況の理解と明示」に相当する取り組みは次のように説明されている。
現実の生活における人々を観察し、何が人々を行動させるのか、さらに何が人々を混乱させるのか、人々は何を好み何を嫌うのか、現在提供されている製品やサービスでは満たされていない潜在ニーズがどこにあるかを探し出す。
これらのアプローチに対して、ここまでのモノのリマスタリングでは、まず「モノに関する情報やコンテンツをインターネットで扱うことによって可能になる「新しいユーザー体験」を描くという、ドメインエキスパートや技術者の思い込みによる完全に人間不在の取り組みから始めている。
  1. モノに関連する情報やコンテンツをインターネットで扱うことによって可能になる「新しいユーザー体験」を描く
  2. バリュープロポジションを定義する
  3. それを実現する製品「ハード」「ソフト」「サービス」を再定義する 
この最初のステップは、さらに次のように細分化する。
dr-step
「コンテンツ・情報の流れの分析・検討」はすでに説明した。そしてFriskを噛んで新しいユーザー体験のアイデアを思いついたら、そのアイデアを視覚化する。
IDEOデザイン思考のプロセスの3番目のステップは次のように説明されている。
それまでになかった新しいコンセプトとそれを使うであろう顧客を視覚化する。 一部の人々は、このステップを未来を予測することだと考えている。そしてこのプロセスの中で最もブレインストーミングを必要とするフェーズである。視覚化はコンピュータを使った演出やシュミレーションの形式をとることが非常に多いが、IDEOでは毎年数千もの模型やプロトタイプも作成されている。新しい製品のカテゴリーの場合は、合成したキャラクターと、ストーリーボードに図で描いたシナリオを使ってユーザー体験を視覚化したりする。場合によっては、まだ存在しない未来の製品が提供されたときの生活をビデオにしたりもする。
ここではコンセプトを「戦略マップ」と「ユーザーストーリー」によって視覚化する(戦略マップについては次回以降に説明する)。
視覚化することは、プロジェクトチームにおいてコンセプトを共通の理解として共有しやすくするという狙いもあるが、IDEOの場合はコンセプトをクライアントに説明(プレゼン)するためのマテリアルであるとも考えられ、その目的に合った表現方法が採られているようだ。ここではまず、HCDのプロセスの「利用者と組織の要求事項の明示」という2番目のステップで用いられているペルソナ/シナリオ法を用いて「まだ存在しない未来の製品が提供されたときの生活」というユーザーストーリーを文章で描いてみよう。すでに製品の機能のイメージはできているかもしれないが、その機能を説明するのではなく、それによって可能になることを書く。たとえばiPodのクリックホイールを例にすると、「親指で円を描くだけでタイトルをスクロールさせて音楽を探すことができる」というのではなく、「片手だけで1000曲の中から好きな音楽をあっという間に選べる」という感じにだ。あるいは最初はクリックホイールというアイデアがまだないときは、「1000曲を持ち歩けばいつでも好きな音楽が聴ける」でいいかもしれない。
この最初のユーザーストーリーを文章で書く目的のひとつは「新しいユーザー体験を描くことの意義」で書いたように、プロジェクトのメンバーで最初に思いついたアイデアを、シナリオを描く過程での気づきで膨らませたり、いろいろなペルソナやユースケースにおいても価値があるかを確認することだ。

そして、この最初のユーザーストーリー、すなわち「まだ存在しない未来の製品が提供されたときの生活」について書いたストーリーをいろいろな人に読んでもらってコメントをもらう。
問題あるいはニーズには、それを解決する(満たす)モノが現れて初めて顕在化するものがある。それまで潜在的なニーズというものは存在しない。それまでになかった新しいコンセプトの製品(モノ)が現れてから、あたかも潜在していたニーズが顕在化したように見えるだけだ。このようなケースでは、「人間中心設計プロセス」のプロセスの「現在の製品やサービスのユーザーの利用状況の理解と明示」からという取り組みは難しい。
そこで、未来の製品やサービスのユーザーの利用状況を現在の人々に見てもらって、自分の「潜在ニーズ」に気づくかどうか試してみようということだ。以前の記事で「共感アンケート」と言ったが、LTF(ルック・トゥ・ザ・フューチャー)と呼ぶことにした。LTFアンケート、LTFインタビューなどと。
LTF
これはリーンスタートアップで提唱されているMVP(Minimum Viable Product:仮説の検証に必要な最低限の機能を持った製品)と同じようにも思えるがLTFはプロダクトではない。MVPもちゃんとした製品やサービスの形をとらなくてもその一部であったり、その機能を表す何か、たとえばペーパーモックやビデオであったりする。LTFは製品やサービスの説明をするものではない。それが提供されたときの人々の生活を表したものだ。そのストーリーを読んでもらい、そこからプロジェクトで狙いをつけた潜在的なニーズを顕在化させる製品やサービスについての気づきやヒントを得ようというのだ。アンケートやインタビューの方法は、HCDやリーンシリーズの書籍に書かれている方法と同様だ。製品やサービスに対する回答者の質問に答えたり、LTFに書いていない情報を提供したり、アイデアの弁護や誘導を行わないようにする。その人の現在の状況と比較してコメントや感想を自由に書いてもらう。

アンケートを前提にすると、模倣されると困るようなことを書くことはできない。しかし、読み手にとってあまりにも抽象的すぎたり理解しにくいものであると、価値のあるコメントが得られなくなりアンケートの意味がなくなってしまう。
インテルのフューチャリスト(未来研究員)によるSFプロトタイプも「その技術は未来にどのように具体的に用いられ、未来の生活として展開していくかを書く」というLTFと同様のものだが、これは社内の技術者が読むために書かれるので技術やアイデアが外部に漏れることはない。ストーリーを描く前にどのような人たちにアンケートに答えてもらうかも考えなければならない。アンケートのバージョンは「片手だけで1000曲の中から好きな音楽をあっという間に選べる」よりは「1000曲を持ち歩けばいつでも好きな音楽が聴ける」のほうがいいだろう。アンケートに「1000曲から音楽をどう探すんだ?」という疑問が帰ってくるかもしれない。あえて抽象化したつもりのない部分にも、同様の疑問や指摘がされるだろう。それらは、技術的に解決したりUX/UIで挑戦したりしなければならない課題なのかもしれない。どのようなコメントであれ、その奥に潜んでいる人々の思いに共感し、コンセプトや想定している機能などと照らし合わせてみる価値がある。この共感はHCDなどでも言われているように、Sympathy(同情)ではなくEmphathy(感情移入)のほうの意味で、アンケートに答えてくれた人になりきってなぜそのようなコメントをしたのかを考えようということだ。問題やニーズを引き出すためや、提供しようとしている体験に価値を感じるかどうかを知るために、とくにコメントをほしい部分に下線をひいたりしてもいい。しかし、そうでないところに多くのコメントが付いたりもする。
これは、実際にやってみると思った以上に面白いはずだ。

考えている製品やサービスによって、ユーザーストーリーのスケールが異なるだろうが、複数のペルソナについて異なったシナリオを描いたほうがいいだろう。1つの方法だが、4人のペルソナに登場してもらい、新しい製品やザービスの価値を伝えるための起承転結となるストーリー構成を考える。最初のペルソナには「問題提起」をしてもらう。もちろん、未来の世界ではその問題は解決されているのだから、その解決された生活を強調して描いて読み手の現在の生活とのギャップを感じて問題に気づいてもらうようにする。
例えば、なにかのきっかけで聴きたくなった曲をすぐに探して聴いているというシーンを描いて、数枚のCDを持ち歩いている現在とのギャップを感じてもらう。気持ちがすぐに変わってどんどん別の曲を探すなどの状況もいいかもしれない。次のペルソナには、1000曲あるはそれ以上の大量の音楽を持ち歩けることによって可能になる体験をいろいろな角度から描き、ペルソナの感じた気持ちすなわち価値を表現する。「転」では、シャッフルなどの機能をイメージして忘れていた音楽との思いがけない出会い、それによっていろいろなことを思い出して、その頃の曲をたどってしまう。要するにコンテンツ(音楽)自体が持つ価値を新しい製品やサービスで最大化することを考えればいいわけだ。そして最後のペルソナには、新しい体験の世界観を伝えてもらうか、さらにその先の展開を想像させるようなストーリーを語ってもらう。もちろん、誇張したり実現性のないことを描くことがナンセンスであることは言うまでもない。ストーリーのバリエーションがみつからないとしたら、まだそのアイデアは人々に問うところまで考えられていないのかもしれない。
このユーザーストーリーを読んで想像力を働かせた人は「そもそも購入していない曲が聴きたくなったらどうするのか?」とか「そんなにあっても何を聴いていいかわからない」とかのコメントをきっとしてくれる。起承転結の構成にしておくと、最初ネガティブなコメントを描いた人が、読み進んだ後半になって違った印象でコメントしてくれたりもする。その流れからインサイトを読み解くにはちょっと想像力と柔軟性が必要かもしれない。
自分が思いついたアイデアにたいするネガティブなコメントは、たとえば「この読者はターゲットじゃないな」などと自分で言い訳をして解決してしまったり無視してしまったりする。そのアイデアを守ろうとするのではなく育てようとする気持ちが重要だ。すべて、思い込みを気づかせてくれる貴重なコメントかもしれないと考えてみよう。

開発者の思い込みといえば、エリック・リースの「リーンスタートアップ〜思い込みを捨てて、顧客から学ぼう〜」というタイトルを思い出すだろう。上にも書いたように、LTFはそこで提案されているMVPと狙いは同じようなものだ。
さらにIDEOの文章をちょっと書き換えてみると、
未来の生活における人々を観察し、何が人々を行動させるのか、さらに何が人々を混乱させるのか、人々は何を好み何を嫌うのか、未来に提供される製品やサービスで満たすべき潜在ニーズがどこにあるかを探し出す。
というように時間が変わっただけ。そして実はHCDのステップと「調査」をするタイミングが変わっただけなのかもしれない。デザイン思考に基づいて考えられたいろいろなメソッドはどんどん活用し応用していこう。

記事の更新はTwitter (@kyosukek)でお知らせします。
このエントリーをはてなブックマークに追加

それはあなた自身だ。
HBR(ハーバード・ビジネス・レビュー)の記事に次のような記述があった。
"The only way out of this innovation gridlock is an expansion in founding team diversity. I believe the missing piece from the DNA in the founding teams of Transformational Companies is now the Domain Expert, who has deep insight into the industry they are trying to disrupt. Without a domain expert attempts at disruption are unimaginative and incremental at best.
There are so many industries ripe for technology startups to disrupt: Education, Health Care, Business, Art and Government just to name a few. But where are the domain experts ready to be paired with a team of rockstar engineers and superstar designers? "

イノベーションの停滞状況から抜け出す唯一の道は、創業者チームの多様性を拡大することだ。私は「変革型企業」の創業者チームのDNAに欠けているものは、彼らが変革を起こそうとしている産業分野に詳しいドメイン・エキスパートであると信じている。ドメイン・エキスパートなしでは変革の企ても想像力に乏しくなり大した成果も期待できない。
教育、ヘルスケア、ビジネス、アート、政府、その他にもテクノロジースタートアップの変革を待っている産業は数多く存在する。しかしロックスター・エンジニアやスーパースター・デザイナーとチームが組めるドメイン・エキスパートはどこにいるのだろうか?
新しい企業が既存の市場に変革を起こすためには“Founder Market Fit”(創業者と市場が適合していること)が必要であり、その創業者チームに必要な人材は時代とともに変わってきている。最初はHPやApple、Microsoftなどのように一人か二人のエンジニアと一人のセールスマンがいればよかったが、現在はデザイン思考などで語られているようにデザイナーの時代になった。しかし、それもすでに市場に適合しなくなっているという。



Tom Kelleyによるこの本の中で、IDEOにおいて実施されているデザイン思考のプロセスの5つのステップが紹介されている。
  1. その市場、クライアント、テクノロジーを理解し、そして与えられた問題に関して認識されている制約事項を理解 する。後でそれらの制約事項に挑戦することもあるが、まずは現状の認識を理解しておくことが重要だ。

  2. 現実の生活における人々を観察し、何が人々を行動させるのか、さらに何が人々を混乱させるのか、人々は何を好み何を嫌うのか、現在提供されている製品やサービスでは満たされていない潜在ニーズがどこにあるかを探し出す。

  3. それまでになかった新しいコンセプトとそれを使うであろう顧客を視覚化する。 一部の人々は、このステップを未来を予測することだと考えている。そしてこのプロセスの中で最もブレインストーミングを必要とするフェーズである。視覚化はコンピュータを使った演出やシュミレーションの形式をとることが非常に多いが、IDEOでは毎年数千もの模型やプロトタイプも作成されている。新しい製品のカテゴリーの場合は、合成したキャラクターと、ストーリーボードに図で描いたシナリオを使ってユーザー体験を視覚化したりする。場合によっては、まだ存在しない未来の製品が提供されたときの生活をビデオにしたりもする。

  4. プロトタイプを評価し洗練することを何回も素早く繰り返す。最初の頃のプロトタイプは変更することになるので、あまり執着しないようにしている。どんなアイデアでも改良しなければ大したものにはならないので一連の改良を加えることを前提としなければならない。社内のチーム、クライアントのチーム、プロジェクトに直接参加していない有識者、ターゲット市場を形成する人々などからのインプットを得るようにする。何が機能して何が機能していないのか、何が人々を戸惑わせているのか、人々はどのように感じているかなどを注意深く観察し、繰り返しの中で徐々に製品を改良してゆく。

  5. 新しいコンセプトを市場に出すために製品化する。このフェーズはしばしば長期間にわたり、開発プロセスの中でも技術的にもっともチャレンジングだ。しかし、IDEOのこれまでのすべての創造的な仕事は、IDEOが持つ製品化を成功させる力への信頼の証しだと信じている。
(原書"The Art of Innovation: Success Through Innovation the IDEO Way"からの訳)
1の「理解」について「市場、クライアント、技術などに関する制約事項を理解する」との解釈が見受けられるが、認識されている制約事項は「与えられた問題に関して」であり、クライアントや技術などの制約事項とするとちょっと意味がおかしくなってしまうように思う。

注意しなければならないのは、このプロセスはあくまでも多くの優秀なエンジニアとインダスリアルデザイナーを擁したIDEOで行われているということだ。心理学、建築学、経営学、言語学、生物学といった分野のバックグランドをもつメンバーも多いそうだ。IDEOはデザイン・コンサルティングファーム(会社)で、多くのクライアントは大企業であり、その経営層からの経営戦略に関わる案件を手掛けている。プロセスの1と5のステップは、それを前提としたものであるが、しかし1から5のすべてのステップとタレントが揃ってこそ、IDEOのこれまでのすべての創造的な仕事という成果をあげることができたのだ。

2008年6月のHarvard Business ReviewでTim Brownが次のように書いている。 
Put simply, design thinking is a discipline that uses the designer's sensibility and methods to match people's needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.

デザイン思考とは簡単に言えば、採り得る事業戦略によって顧客価値と市場機会に転換することができ、かつ技術的に実現可能である何かを、デザイナーの感性と手法を用いて人々のニーズに調和させる専門分野である。 
IDEOにおいては、インダスリアルデザイナーだけでなく、エンジニアあるいはそれ以外を専門とする人も含めてメンバーのすべてが、この「デザイナーの感性と手法」を備えてえいるということだろう。

IDEOのデザイン思考やそのプロセスは、 広く学ばれ実践されている。その中心にいるスタンフォード大学のデザインスクール「d.school(Institute of Design at Stanford)」 によるテキストの日本語翻訳版「デザイン思考家が知っておくべき39のメソッド -the d.school bootcamp bootleg-」が一般社団法人デザイン思考研究所から提供されている。そこではデザイン思考の5ステップが次のようになっている。
  1. Empathize:共感
  2. Define:問題定義
  3. Ideate:創造
  4. Prototype:プロトタイプ
  5. Test:テスト
このテキストでは、オリジナルのステップの1(理解)と5(製品化)が消えてしまっている。2(観察)が共感と問題提起に分割され、3(視覚化)が創造となり、4(プロトタイプ)がプロトタイプとテストに分割されている。一見するとオリジナルの1(理解)と共感が対応するように思えるが、1(理解)はコンサルタントから見てのクライアント、すなわち製品やサービスを提供する側の状況を理解するということであり、d.schoolのテキストにおける共感は製品やサービスを利用する人々の気持ちになりきって考えるためのステップである。デザインスクールのカリキュラムやワークショップのテキストとして、その2つが扱いにくいということは理解できるが、この消えてしまった2つはデザイン思考において非常に重要なステップだと思う。
コンサルティングとしてクライアントの経営課題に取り組む場合でも、自社のイノベーションに取り組む場合でも、その会社(自社)の事業の市場や関連するテクノロジーを理解し、そして直面する経営課題に関して認識されている制約事項を理解 することなくしては始まらない。

デザイン思考と人間中心のデザイン(HCD)とはどこが違うのかという質問を受けて、自分もその関係をちゃんと理解していないことに気付いた。イノベーションを起こすための3ステップ・ツールキット〜人間中心デザイン思考:Human-Centered Design Thinking〜 by IDEO.orgという資料が前出の一般社団法人デザイン思考研究所で提供されていることからも混乱してしまう。
実は人間中心のデザインプロセスはISOで規定されている(ISO 13407, JIS X 8530)。 それによると「人間中心設計プロセス」とは「製品(インタラクティブ・システム)のユーザビリティ改善について規定した プロセス規格」とかなり限定されている。そしてそのプロセスのステップ(とメソッド)は、
  1. 利用状況の理解と明示(コンテクスト調査法)
  2. 利用者と組織の要求事項の明示(ペルソナ/シナリオ法)
  3. 設計による解決策の作成(プロトタイプ作成)
  4. 要求事項に対する設計の評価(ユーザビリティ・テスト)
となっている。これはd.schoolのテキストのプロセスと同様だ。「HCDの手法はインクリメンタルなイノベーションに適している。ラディカルなイノベーションを導くことはできない。」とノーマンが言っている。ラディカルなイノベーションのためには、IDEOのオリジナルのデザイン思考のプロセスとそれに取り組むメンバーの高いスキルが必須となる。
勝手な解釈だが、デザイン思考とは考え方"Mindset"でありプロセスは規定していない。ISOで規定されているHCDやd.schoolのテキストのステップやメソッドは、デザイン思考に基づいて、インタラクティブ・システムやそのほかの製品やサービスのユーザビリティ改善のために考えられたプロセスであり、IDEOで用いられているプロセスも同様にデザイン思考に基づいて考えられたプロセスの1つだと考えるとしっくりする。

最初に戻ろう。

ドメイン・エキスパートはあなた自身だ。あなたは、あなたが変革を起こそうとしている自社の属する産業分野に詳しいはずだ。そしてさらに、その産業分野に関連する技術についてもおおよそ把握している。あなたはすでにIDEOのデザイン思考のオリジナルのステップの1(理解)はクリアしている。しかし、これまではあなたの顧客のことをあまり気にしていなかった。あなたがエンジニアであってもビジネスパーソンであっても、IDEOのスタッフのようにデザイン思考の考え方を身につけることによって、あなたはあなたの顧客になりきる(Empathize)ことができるようになる。
たったこれだけのことを言いたかっただけなのだが、例によって引用とその勝手な分析が長くなってしまった。

記事の更新はTwitter (@kyosukek)でお知らせします。
このエントリーをはてなブックマークに追加

このページのトップヘ