大きく考えると言うこと

デザインの課題に取り組んでいる際に教授から言われる事のひとつに「Think Big」と言うものがあります。

我々の組織CIIDは、Copnhagen Institute of Interaction Designが正式名称でして、ようするにインタラクションデザインに関する研究機関なんですね。インタラクションデザインとは何かについては下記にも書きました。

ddcph.hatenablog.com

だけど、一般的にインタラクションデザインという単語から受けるイメージって、結構限られた範囲であるように思うんですよね。ユーザーインターフェースだったり、せいぜいプロダクトであったり。もちろんインタラクションデザインを説明した下記の有名な図があるように、人と、世界のインタラクションを設計すると言う意味では間違い無いのですが、実際問題、その境界面だけを考えれば良いと言う事は滅多になく、システム全体を捉えてデザインしていく必要があります。

そこで、教授達から言われるのが、Think Bigと言うこと。私達がデザインしようとしている対象は単にアプリや、インスタレーションではありません。それらは短期的に見ればユーザに何らかの価値をもたらすかも知れませんが、実世界の中でそれが長期的に動き価値をもたらさなければ、意味は無いのです。

例えばアプリのデザインでもそうですし、図書館等のサービスに関するデザインでもそうですが、ステークホルダーやユーザに提供する価値をいかにしてバランシングさせるかという事が重要であると言う事。そしてそれらに価値を提供したさらに外側でどのような事が起こるのかと言うところまでしっかり考える事が良いプロダクトやサービスを生み出すためにはきっと必要なのでしょう。

余談ではありますが、「目の前にあるフルーツを取るだけじゃだめなんだ」と言う表現を教授が使っていたのが少し印象的でもありました。

プロトタイピングの計画について

コンセプトマッピングを行いアイディアをある程度明確にしたら、プロトタイピングの計画づくりを行います。プロトタイピングについて、一般的にはモノ作りのことを指すように捉えがちだと思うのですが、これは少し異なり、下記の記事でも少し触れましたが、仮説検証のプロセスのことを言います。

ddcph.hatenablog.com

プロトタイピングはプロセスですので、ある程度の計画を行う事が可能です。もちろん行き当たりばったりプロトタイピングを行う事も可能でしょうが、ある程度の期間である程度の成果を出すためには計画を立てた上で効率良く仕事を進めて行く必要があります。

さて、プロトタイピングの計画作りで考えなければ行けない事は何かというと、下記のような項目かなと思います。

我々がわかっていないことは何か？

例えば下記のような内容になるでしょうか。

• ユーザはこのような情報を提示された時に、どういった反応を示すのだろうか。
• ユーザはこのようなインタラクションに抵抗を示さないだろうか。

コンセプトの基本となる仮説は何か？（もしこれが真実でないと証明された場合にコンセプトの修正が必要なものは？）

例えば下記のような内容になるでしょうか。

• このような情報はユーザーに取って有用なはずだ。
• このようなインタラクションがあればユーザの行動がポジティブなものになるはずだ。

プロトタイピングを行う際の登場人物は誰か。彼らをどのようにして見つけ出すか。

例えば下記のような内容になるでしょうか。

• ３歳前後の子供を持つ親
• 友人に連絡する。

プロトタイピングの手順はどうか。

ここではプロトタイピングをどのようにして行うかを検討しスコープと手順を明確にする。ここで重要な点は、まず初期の段階ではコンセプト全体ではなく、例えば不明な物を調べるための、もしくは仮説を検証するための最小限は何か？と言う点を考えるべきであると言う事です。

その他

上記に加えて、下記のような点を明確にしておくと良いのかなと思います。

• どのような結果を期待しますか。
• どのような状況になれば成功だと言えるか。
• 仮説が間違っていた事を、どうやって知りますか。
• 計画が適切ではなかった事をどうすれば知ることが出来ますか。
• 計画したプロトタイピングからどのような事を知る事ができるか。
• プロトタイピングの結果、十分な違いが出るようになっているか。
• 誰がやっても同じような結果にならないか。
• 複数の事を同時に検証可能か。

以上、わりと細かい話になってしまいましたが、仮説検証のステップと言うのは比較的多くの時間、コストが必要な部分でもあります。例えば、第三者に実験に協力して頂くとしても、それほど簡単に出来無い事が多いですし、準備やなんやかんやで数時間必要な場合も珍しくありません。

限られたリソースを使用して、いかに効率良くプロトタイピングと言う仮説検証を進めて行くかがデザインプロセスの中で非常に重要であり、そのためには綿密な計画が不可欠と言う事も出来るはずです。

アイディアのコンセプトマッピング

アイディア出し後は、コンセプトマッピングを行います。コンセプトマッピングは下記の記事のコンセプト作成でも少し触れて居ます。

ddcph.hatenablog.com

アイディア出しを行ったとは言え、それらのアイディア入ってみれば思いつきで作った素案のようなもので、とてもじゃないですがコンセプトと呼べるようなものではありません。

ですので、コンセプトマッピングと呼ばれる作業を行います。コンセプトマッピングの内容としては下記項目について考える事です。

• コンセプトの説明
• ターゲットユーザ
• ユーザの価値
• サービス提供者の役割
• ユーザのシナリオ
• ポジショニング

この中で、一番わかりやすいのは、ターゲットユーザについてでしょうか。そもそも最初の段階で決まっている事が多いですから、これは簡単に書けるのではないかと思います。図書館を利用する８歳〜１２歳程度の子供だとか、５歳未満の子供を持つ親御さんとか、そういうのですね。実際にはもっと細かい条件付けを行う場合もあるでしょうが。

次にわかりやすいのはユーザの価値でしょうか。How Might We Questionを元にアイディア出しをしているわけですから、解決したい課題と言うのはある程度明確です。ただ、それだけでなく、副次的な価値についても書いておくと良いかも知れません。

サービス提供者の役割に関しては少し考えないと行けないかもしれません。どれだけ素晴らしいアイディアであっても多大なコストがかかるアイディアだと実行されにくいでしょうから、どのような活動をサービス提供者に期待しているかを明確にしておきます。

そしてシナリオに関しては、ユーザとサービスのタッチポイントを説明します。どういう状況でユーザはサービスの事を知るのか。そしてそれをどうやってつかうのかなどなどを考えつつ可視化してきます。

そして最後に、ポジショニング。これはアイディアの種類でしょうか。例えば、各々のユーザを対象にしたサービスなのか、それともグループなどの集団を対象にしたアイディアなのか。これまでの延長線上にあるアイディアなのか、それともそもそもこれまでとは違う別アングルからのアイディアなのかなど。他の軸としては、今あるインフラを何らかの形で利用するアイディアなのか、それとも独立したアイディアなのかなどが挙げられるでしょうか。これらはコンセプトの説明を読めばわかるといえばわかるのでしょうが、他のアイディアとの違いをひと目で分かるようにするという意味で重要なのかなと思います。

これらを整理してA3程度の紙にまとめる事によって自分たちのアイディアがどのようなものかを説明します。冒頭の写真は我々のHow might questionとそれに対するアイディアをコンセプトマッピングしたものなのですが、このように壁に貼ってわかりやすくしておくと、チームの進捗や方向を容易に確認出来るので良いと思います。

How Might Weの設定からアイディア出しまで

下記記事の続きです。

ddcph.hatenablog.com

オポチュニティの抽出までを行い、How Might We Questionの作成までを行いました。なお、How Might We Questionに関しては下記で詳しく書いているので、こちらを読んで頂ければと思います。

ddcph.hatenablog.com

なお、今回のプロジェクトではインサイトを6つ作成して、そこから３つを選びオポチュニティを設定し、そのそれぞれにHow Might We Questionを設定しました。How Might We Questionの作成に関しては、ブレインストーミングを行いながら、こんなのはどうだ？いやこっちのほうが良いのでは？などとそれぞれが案を出しながら決めて行く感じです。

そしてここから３つのHow MIght We Questionのそれぞれにアイディアを出して行くのかなと思ったのですが、その前に選択を行いました。出揃った3つのHow MIght We Questionの中から２つを選びだし、そこからそれに対するアイディアを出して行きます。

なお、アイディア出しに関しては、ポストイットではなく、A4サイズの紙を使用しました。A4サイズの紙を横向きに置いて、左半分上部にタイトルを、下部に簡単な説明を、そして右半分にイラストを書いていきます。

アイディア出しですので質より量で、時間を区切るわけですがその時間内で、とにかく考えつく限りのアイディアを紙に書いていきます。例えば５分あれば５個ぐらいはアイディアが出るのかな。場合によってはもっとかも。アイディア出しが終わるとそれぞれが自分のアイディアを説明します。

５分間の作業＋アイディアの説明を１セットとして、これを何セットかしていくと、色々面白いアイディアも出てくるわけです。もちろんここは他人のアイディアの借用や、自分自身のアイディアのブラッシュアップもOK。

そして出てきたアイディアはどんどん壁に貼っていき、ある程度出揃ったかなと思ったところで、幾つかのアイディアを選びます。我々の場合は、多く出たアイディアの中から３種類のアイディアを選択し、これらをベースにブラッシュアップをしていくこととなりました。

なお、アイディアを選択する場合ですが、それぞれのHow Might Weから等しくアイディアを選ばなくても良いという点も面白い。例えば２つのHow Might Weに対してアイディア出しを行ったけれども、片方のHow Might Weに対しては全然良いアイディアが出てこないという場合も当然あり得るわけです。そういう場合であっても、面白そうなアイディアをしっかり選ぶというのが重要なのだろうなぁと思います。

また、アイディアの選び方について、我々はアイディアが書かれた紙にシールを貼って投票する形式でしたが、出たアイディアの中には似たようなアイディア、コンセプトというのももちろんあるわけです。こういった場合、機会的に投票数が多いものからN個を選択して云々というよりは、これとこれはほぼ同様のコンセプトだからまとめようとか、ある程度人の手を介しながら選択していくのが良いのかなぁと思います。

プロセスが大事だ大事だと言いつつも、このように人の判断でプロジェクトを進めて行くというのは曖昧だなぁとは思いつつも、同じプロセスを使ってもこういったところで差が出るのかなぁとも思いますし、使いこなせるというのはおそらくこういう点でスムーズにかつ的確な判断が出来るようになるという事なんだろうなぁ、等と思うわけです。

インタビューの内容をクラスタリングしてインサイトを抽出する

下記のようにしてリッチプロフィールを作成したあとは、この内容を分析して、どのようなニーズがあるのか、どのようなデザイン機会がありそうか等を導出するためにクラスタリングを行って行きます。

ddcph.hatenablog.com

今回の場合で言うと、In-depthインタビュー、つまり1時間程度かけてじっくり話を聞いたインタビューが3名、ゲリラインタビューとして5分から10分程度でインタビューさせて頂いた方が10名程度いらっしゃったわけですが、彼らの発言で印象に残った点や、インタビュー中に気がついた事等を、ポストイットであったり、小さめの紙等に印刷し、テーブルの上に並べて行きます。

クラスタリング自体はわりと直感的に行う事が多いのかな。この紙に書かれている事とこの紙に書かれている事は似ているなとか、自然言語で書かれている事なので厳密に野郎にも限界がありますので、ある程度曖昧に、直感に頼らざるを得ないのは仕方ないのでしょう。

クラスタリングの具体的なラベルとしては私達のプロジェクトの場合で言えば「家庭における教育」であったり「子どもとのコミュニケーション」だったり「地域における図書館」等様々ですが、これに関してはプロジェクトによるし、そもそもインタビュー結果によるところが大きいので、内容に即したものであるべきでしょう。

クラスタリングを行う際のグループ数ですが、あまり数が多くてバラバラでもその後が大変だし、少なすぎても可能性を狭めてしまうことになりかねません。絶対にこの個数にしなければならないと言うのは無いと思います。でも５、６個ぐらいのグループに分けるのが良いのでは、という印象を受けました。

なお、ここのクラスタリングのプロセスにおいては、不可逆に行うのではなく、行ったりきたりしながら行うのが良いように思います。つまりグループに対して行ったラベリングは絶対的なものではなく、クラスタリングの過程でスコープをズームインしたりズームアウトしたりするわけですね。一度ラベルをつけて、それに関する情報をそこに集めて見たものの、思ったより少なかったからもうちょっと範囲を広げて見ようだとか、またその逆もあり得ると思います。

さて、この後はクラスタリングした各グループからインサイトを抽出していきます。これに関しては下記の記事に書いてある内容と重複しますので、よろしければご覧ください。

ddcph.hatenablog.com

インタビューから作成するリッチプロフィールについて

昨日はIn-Depthインタビューについて紹介しました。

ddcph.hatenablog.com

このようにして行ったIn-Depth Interviewは下記のような流れで、リッチプロフィールの作成、インサイトの抽出と進めて行きます。

ddcph.hatenablog.com

が、このプロセスも３回目なので、いくつか補足的な事を事をここに書いておきたいと思います。まず、リッチプロフィールの作成についてですが、何を含める必要があって、何を含めなくても良いかに関しては、比較的柔軟に対応すれば良いのかな、と思っています。

例えば、前回のスポーツ施設に関するプロジェクトでは、下記のような項目をリッチプロフィールに含めて居ました。

• 名前
• 属性（ユーザーか非ユーザーかなど）
• 経歴
• どこに住んでいるか（スポーツ施設からの距離）
• スポーツ施設のことをどの程度知っているか
• インタビューの中で出てきた興味深いストーリーを３つ
• スポーツ施設の事をどう思っているか
• 最も印象に残ったセリフ

ところが、今回作成したリッチプロフィールでは、下記のような項目が含まれています。

• 名前
• 属性（家族構成など）
• 図書館の利用頻度
• 図書館の事をどう思っているか
• 知的好奇心を満たす３つの方法
• 知識を得る上で必要だと思っている点３つ
• 社会の中で、誰かと一緒に何らかの活動をしているか
• 最も印象に残ったセリフ

一見すると似ているようですが全然違う事がわかるかと思います。このリッチプロフィールの項目自体は教授からこれを使えと言われて配布されたものなので、この項目をどうやって設定するのが適切なのかについてちゃんと説明があったわけではないのですが、おそらく今回のクライアントが目指している「Getting Smarter Togetther」を元に項目を作っているんだろうなと思います。

ただ、結局のところリッチプロフィールからは、その人がどういう人で、デザインの対象に対してどういう考えを持っているかがわかれば良いわけです。もちろん、ここからインサイトを抽出していくわけですから、インサイトを抽出しやすさ、と言うのがそれなりに必要ではあるのです。

どのようなものがあるとインサイトを抽出しやすいかに関して考えてみると、結局デザイン対象にどのような思いを持っているか。どのように利用しているか等の情報があると良いわけで、そのあたりを考慮しつつ、リッチプロフィールの項目を設定していけば良いのかなと思います。

In-Depth Interviewで対象者からインサイトを引き出す

デザインリサーチ手法には色々ありますが、重要なものをひとつ挙げろと言われたらIn-Depth Interviewを外す事はできないと思います。

In-Depth Interviewを簡単に説明すると、対象者の経験や普段の行動、考えなどについて深く掘り下げながらインタビューを行う事です。対象者は、例えば図書館に関するリサーチであれば、図書館利用者である場合もあれば、利用してない人に対してインタビューを行う場合もあります。エクストリームユーザと呼ぶ事もありますが、極端なユーザーに対してインタビューを行う事もあります。

toyokeizai.net

時間は長くても１時間程度に収めるのが良いと言われていますが実際にはこれがなかなか難しい。例えば、ひとつのインタビューの冒頭だけでも、これだけの話をする必要があるわけです。

• 挨拶
• チームの紹介
• インタビューの目的の説明
• 合意書（写真や情報の資料で使用することなど）の説明

そしてこれらが一通り終わると、インタビューの核心に入る前にインタビュイーの事を知る時間を取ります。例えば下記のような項目でしょうか。

• アイスブレイク的な会話
• これまでの経歴
• トピックに関連した質問

そしてその後、核心の質問に入っていくわけですが、ここまででヘタすると20分とか30分経過してしまう事もあるんですよね。そうなると核心の質問にさく時間がほとんど残ってないと言う事になりかねず、色々聞こうとすると簡単に時間オーバーしてしまいます。

そのため、聞きたいポイントを絞って、深堀するにしても全部を深堀するのではなくポイントを絞って話を進めて行かなければなりません。

予め計画を立てたり、以前紹介したようなツールを利用する事で、この辺りの効率を高める事が出来るのだとは思うのですが、それでも直感が効いてくる事も否めないのかなぁとも思います。経験を積めば面白いトピックに踏み込んで行けるのかも知れないけれど、使いまわせる定形のパターンがあるようにも思えないし。

ddcph.hatenablog.com

ちなみに私の場合は、こういったリサーチ活動のビギナーと言うことだけでなく、言語的な壁が非常に大きいということでかなり苦戦して居るのも事実なのですが、日本に帰国後、この経験を少しでも活かす事ができるように、こうして言語化することによって血肉としたいところです。