この記事は「UXとかHCDとかその辺りの何かをひとりで黙々とまとめる Advent Calendar 2013」の7日目の記事です。6日目は「人間中心デザインの方法論についてまとめてみる(1周目1/4)」でした。
5日目からは人間中心デザイン(Human Centered Design,HCD)について書いています。本日は「ユーザーの要求事項の明示」について書きたいと思います。
5日目からは人間中心デザイン(Human Centered Design,HCD)について書いています。本日は「ユーザーの要求事項の明示」について書きたいと思います。
ユーザーの要求事項の明示では、1つ前の「利用状況の把握と明示」で得られた情報を元に、要求事項をまとめます。実はISO9241-210でいう「ユーザー」には定義上すべてのステークホルダーが含まれているので、ユーザーと組織の要求事項となります。まぁー分かりにくいと思うんですけど。
主な手法としては、何らかのカードソート法(いわゆるKJ法ですが、発想法として使ってないという意味でカードソートかなぁと)などで調査結果をまとめていく形になるかと思います。ユーザーの要望をカードソートで分類するとなると一番好きなのは「KA法」ですね。安藤研究室のブログを見ていただくなり、hcdvalueのhokorinさんにワークショップを依頼するのがよいかと思われます。hcdvalueメンバーはだいたいできるように思います。
価値の分析法でいくと「本質的価値抽出法」とかラダリングと言われているものがあります。これはExperience Visionの一部として説明されています。
その他、よく聞くのは「ペルソナ・シナリオ法」ですね。
ペルソナ4 ザ・ゴールデン [Video Game] ではなく、仮想(≠架空)のユーザーを作成して、そのユーザーが体験するシナリオをつくり、考えるためのツール群、です(だと思います)。ただ、これがまぜこぜにしてしまうと色々ややこしいです…(私も分かってません
ペルソナは大きく二つの目的があるように思います。
1つは一緒につくるチームのメンバー間の意識を揃えるためです。コラボレーションのための1ツールという側面で、この場合だとユーザー調査の結果を遣わなくても、「妄想」でペルソナを作成するこもヨシとしています。「プラグマティック・ペルソナ」という名前で広まっているように思います。ただし、これは「捨てる」前提に立つ必要があるからです。「仮」であり「妄想」で、実際のユーザーにインタビューして顧客を見つけるまでのペルソナのはずです。
もうひとつはそれをアウトプットとして用いるために、しっかりつくり込む、実際のユーザーに相当するレベルまでつくり込むという考え方です。ユーザー調査の結果をキッチリまとめあげる必要があり、期間・費用といったコストがかかります。
どちらがより良いなどはないのですが、後者はだんだん減っている印象があります。コストがかかる割にどう活かすか見えないなどがあったのだろうと思っているのですが、 「妄想」が入るか入らないかでだいぶ異なるので注意が必要なのかなと考えています。
シナリオもAs-IsとTo-Beという二つの性格があります。現状シナリオ分析かあるべきシナリオか、ですね。To-Beシナリオはある程度アイデア発想が必要な側面もあるので、注意が必要かな、と思います。
また、シナリオの粒度問題も発生します。どのくらいの粒度のシナリオで書くか、ですね。これについてはエクスペリエンス・ビジョンにある「構造化シナリオ法」の3分類である「バリューシナリオ」「アクティビティシナリオ」「インタラクションシナリオ」を意識して書けることが重要かなと感じています。実際、インタラクションシナリオに囚われてしまうことが多いのですが、バリューに視点を移したり、アクティビティを考えたりする必要があります。ちなみに、アクティビティとはインタラクションよりも抽象度が高く、浅野先生の言葉を借りれば「時代が変わっても変わらないこと」です。「情報を知らせる」=ケイタイでメールする、かわら版で知らせる、などなど。
最近だと、ユーザージャーニーマップ、サービスブループリント、ユーザーエクスペリエンスマップなどなどといったマッピングも多数あります。それぞれ微妙な差分はあるのですが、私は得意分野ではないので説明が難しいところです。 (すみません
といったところで、「利用状況の把握と明示」のまとめを終わりたいと思います。全然分かってないことがまるわかりですね!!!
明日は「設計による解決策の作成」についてまとめたいと思います。
主な手法としては、何らかのカードソート法(いわゆるKJ法ですが、発想法として使ってないという意味でカードソートかなぁと)などで調査結果をまとめていく形になるかと思います。ユーザーの要望をカードソートで分類するとなると一番好きなのは「KA法」ですね。安藤研究室のブログを見ていただくなり、hcdvalueのhokorinさんにワークショップを依頼するのがよいかと思われます。hcdvalueメンバーはだいたいできるように思います。
浅田 和実
日本能率協会マネジメントセンター
2006-02
価値の分析法でいくと「本質的価値抽出法」とかラダリングと言われているものがあります。これはExperience Visionの一部として説明されています。
その他、よく聞くのは「ペルソナ・シナリオ法」ですね。
ペルソナ4 ザ・ゴールデン [Video Game] ではなく、仮想(≠架空)のユーザーを作成して、そのユーザーが体験するシナリオをつくり、考えるためのツール群、です(だと思います)。ただ、これがまぜこぜにしてしまうと色々ややこしいです…(私も分かってません
ペルソナは大きく二つの目的があるように思います。
1つは一緒につくるチームのメンバー間の意識を揃えるためです。コラボレーションのための1ツールという側面で、この場合だとユーザー調査の結果を遣わなくても、「妄想」でペルソナを作成するこもヨシとしています。「プラグマティック・ペルソナ」という名前で広まっているように思います。ただし、これは「捨てる」前提に立つ必要があるからです。「仮」であり「妄想」で、実際のユーザーにインタビューして顧客を見つけるまでのペルソナのはずです。
もうひとつはそれをアウトプットとして用いるために、しっかりつくり込む、実際のユーザーに相当するレベルまでつくり込むという考え方です。ユーザー調査の結果をキッチリまとめあげる必要があり、期間・費用といったコストがかかります。
どちらがより良いなどはないのですが、後者はだんだん減っている印象があります。コストがかかる割にどう活かすか見えないなどがあったのだろうと思っているのですが、 「妄想」が入るか入らないかでだいぶ異なるので注意が必要なのかなと考えています。
シナリオもAs-IsとTo-Beという二つの性格があります。現状シナリオ分析かあるべきシナリオか、ですね。To-Beシナリオはある程度アイデア発想が必要な側面もあるので、注意が必要かな、と思います。
また、シナリオの粒度問題も発生します。どのくらいの粒度のシナリオで書くか、ですね。これについてはエクスペリエンス・ビジョンにある「構造化シナリオ法」の3分類である「バリューシナリオ」「アクティビティシナリオ」「インタラクションシナリオ」を意識して書けることが重要かなと感じています。実際、インタラクションシナリオに囚われてしまうことが多いのですが、バリューに視点を移したり、アクティビティを考えたりする必要があります。ちなみに、アクティビティとはインタラクションよりも抽象度が高く、浅野先生の言葉を借りれば「時代が変わっても変わらないこと」です。「情報を知らせる」=ケイタイでメールする、かわら版で知らせる、などなど。
最近だと、ユーザージャーニーマップ、サービスブループリント、ユーザーエクスペリエンスマップなどなどといったマッピングも多数あります。それぞれ微妙な差分はあるのですが、私は得意分野ではないので説明が難しいところです。 (すみません
といったところで、「利用状況の把握と明示」のまとめを終わりたいと思います。全然分かってないことがまるわかりですね!!!
明日は「設計による解決策の作成」についてまとめたいと思います。
コメント