第一部 リサーチ

なぜリサーチが必要か？

ターゲットは明確でも、ターゲット自身が「自分自身の欲しいもの」か分かっていない。つまり「何が必要ですか？」と聞いて答えを鵜呑みにしてはいけない。

どのようなリサーチが効果的か？

• 人々は自分の求めるものがわかっていないので、こちらから訪問して相手が行っていることを観察しなければならない
• 具体的な質問をすれば有益な情報が得られるが、結論を下す前に複数の人にインタビューする
• ペルソナを作るためには、ユーザーリサーチで得た情報を、具体的な人物像に反映させることで、製品のターゲットを定義する際に役立ち、チーム内のコニュニケーションを円滑にする
• ペルソナはユーザーの代わりにはならないので、現実の人間を相手にデザインをテストする
• 「人間中心」のデザインか「活動中心」のデザインかは、製品の性質によって異なるが、どちらにフォーカスするかを早い段階で決めることが重要

どのようなリサーチは避けるべきか？

• 小さなチームではペルソナはさほど効果的ではない（ユーザー像をよく把握しているため）
• ペルソナはユーザーリサーチの代わりにはならない（ユーザーリサーチの結果を製品に組み込むのに役立つだけ）

第二部 デザイン

「繰り返し」がテーマ。デザインし、試し、うまくいかない部分は受け入れる。この過程を繰り返す。

リサーチを通して、目指す製品の対象ユーザーや解決すべき問題が明確になっても、解決方法を決めてしまわないほうがよい。即断は禁物。「自分は間違っているかもしれない」と自問する余裕を常にもっておく。早いうちに失敗するのはよいこと。
いきなり完全なものとして構想をまとめ上げる作業を始めるのではなく、徐々に進める。

ユーザーが関心を寄せる対象は、提供するツールではなく、ツールを使うことによってできること。

ユーザーからフィードバックがあったときは、トヨタ式の5回のなぜを繰り返して、根本原因を見つける。

テレビゲームに学ぶ

人が面白さを感じるのは、目標があり、その目標達成までの道のりをフィードバックが常にあり、目標達成が不可能ではないものの容易でもない程度の技能をその人がもっている場合。

• 意味のある難問や課題があるとき
• その難問の答えにどれほど近づいたか、課題をどれほど習得したかなどを計測する方法があるとき
• 自分にその難問を解く、あるいは課題を習得する能力があるとき

製品とゲームが異なる点
課題は、ゲームはゲーム自体が、製品はユーザーが用意する。製品は課題を解決するための道具。
難易度は、ゲームはデザイナーが制御する。製品はユーザーが制御する。

ゲームから学べること

• 進捗状況
• 上達
• 発見と報酬
• 競争
• 収集
• 一貫性のあるルール
• 面白い vs 使える（使えるアプリの中の面白いアプリ。面白いアプリだけど使えないアプリはアート作品）

テクニック

付随資料の作成（逆光方式）

開発プロセスの初期段階から、マニュアル、ブログ投稿、スクリーンキャスト、プレスリリースのような自分の製品に興味をもってもらい、使い方を理解してもらう資料類を用意する。

これによりデザインの問題点が見つけやすくなる。説明しにくい部分は、その製品が使いにくいかもしれない。
解決したい問題に意識を向けるのにも役立つ。自分の製品を簡潔に説明できない場合は目的が多すぎるか、具体的な問題の解決になっていないかもしれない。

• マニュアル（製品の一部。「ユーザーはどう使うのか？」「マニュアルの構成は？」「内容として欠かせないものは？」を自問する）
• ブログ投稿（「なぜその機能がすばらしいのか、それを使うとどんなにすばらしいことができるのか」を記事にする。これを簡単に説明できない場合は、デザイン変更の余地があるかもしれない）
• スクリーンショット（プロトタイプができたら、製品や機能に興味を持ってもらうには、どんな仕掛けが必要か？問題の具体例とその解決方法、簡潔なストーリー展開で説明するテストビデオを用意する）
• プレスリリース（自分の製品についてワクワクするような説明ができているか確認する。前もってプレスリリースを書くことで、自分たちがどう考えているかではなく、人々が製品をどう見るかがはっきりする。製品の広告やスローガンを簡潔な文章で表現できるか確認するのもいい）
• 「どんな機能があるか」ではなく「何ができるか」を語る