「ユーザーストーリー」を採り入れてみる

ユーザー中心設計 (User Centered Design : UCD) において、ターゲットユーザー像を明確にするために、ペルソナやシナリオを用いることは多いと思います。

ペルソナやシナリオは使いかた次第で、プロジェクト内の意思疎通や意志決定に大いに役立ちますが、正しく運用するのはそれなりに大変です。思い込みやステレオタイプで作ってはいけませんし (エスノグラフィックな実地調査を通じて練り上げるのが基本)、コミュニケーションツールとして効果的に使われ続けるようにまとめるには、勘所の押さえも含め、ある程度習熟が必要です。

また、アクセスしてくるユーザーの目的やニーズが多種多様なウェブサイトの場合 (特にコーポレートサイトや自治体サイトなど、サイトの規模が大きく、提供すべきコンテンツが多岐にわたるもの)、主要なターゲットユーザー象のペルソナを用意するだけではコンテンツ戦略が不十分 (あるユーザーセグメントに対するアプローチが全然できていなかったり…) になる可能性があります。

UCD を、もっと手軽に実践できないだろうか。また、多種多様なユーザーニーズを幅広く拾った設計ができないだろうか。— そんなとき、アジャイルのプロジェクトで用いられている「ユーザーストーリー」を使うという手もありかもしれません。実際にいくつかのプロジェクトで試しましたが、あらゆるプロジェクトで汎用的に使える最善の方法、というわけではないものの、UCD に馴染みのないチームでは、それなりに採り入れやすかったという印象です。以下、やってみて気づいたことや、課題などをまとめました。

ユーザーストーリーとは？

ユーザーストーリーとは、以下の簡易的なフォーマットで記述されるセンテンスです。(参照 : User story - Wikipedia)

As a [role], I want [goal/desire] so that [benefit].

[ある特定の役割や立場] である私は、[目的や望みごと] をしたい。それによって [こんな利益やよいことが得られる] だから。

このフォーマットで穴埋め式に書くだけです。実際にやってみて、以下の利点があると感じました。

ユーザーストーリーを書く

私がペルソナ/シナリオの代わりに敢えてこの簡易的なフォーマットを用いるのは、多種多様なユーザーニーズをプロジェクト関係者みんなで洗い出したい場合です。なので、まずは想定されるあらゆるストーリーを抽出するつもりで、ブレスト的に、ユーザーストーリーをたくさん書き出してみます。

ただし、空想 (まったくの作り話) は、的はずれなユーザーストーリーになってしまう恐れがあるので NG とします。実際の経験 (顧客タッチポイントでの見聞)、カスタマーサポートの記録、アクセス解析データ、など事実に基づいていること (またはデータを基に仮説立てすること) が大事です。自らがユーザーであれば自身の体験を基に書き出しても構いません。

当然ながら、ユーザーストーリーは、いわゆる「顧客」(製品購入者やサービス利用者) に限定しません。たとえばコーポレートサイトであれば、就職/転職希望者、メディア関係者、個人投資家、事業分野やその周辺に興味関心がある人 (マニアやウォッチャー、その分野について調べる学生など)、社会見学希望者、事業所地域の住民、などなど、様々な人がウェブサイトにアクセスする可能性があることを、この際にじっくりと考えてみましょう。

なお、上述のフォーマットの [goal/desire (目的や望みごと)] には、具体的な機能、デザイン成果物のあり様を盛り込まないようにしましょう (それは、後の工程で検討すべきことだからです)。あくまでも、ユーザーが最終的に達成したいこと (満足できる状態) を書きます。

また、[benefit (こんな利益やよいことが得られる)] をしっかり押さえることも意識しましょう。この部分では、ユーザーが得られる UX の価値を端的に表現します。

ユーザーストーリーの整理と優先度付け

ブレスト的にユーザーストーリーをたくさん書き出してみると、何十ものストーリーができ上がることでしょう。これらのストーリーを等しく扱ってしまうとデザインにならないので、こんどは、ストーリーを整理して優先度を付けます。

プロジェクト関係者みんなで、ストーリーを並べて読み合わせをし、違和感があるものは修正または削除し、重複するストーリーは統合します。ストーリーを並べる際は無記名とし、筆跡を消すためにいったん電子データ化 (タイピング) して出力してもよいでしょう。「誰が書いたか」という手掛かりを排除して、建設的にストーリー内容だけをディスカッションできるように配慮します。

そのうえで、ユーザーストーリーの優先度を付けます。優先度を決めるためのパラメーターは組織やプロジェクトによって異なると思いますが、細かく優先度付けをすることにこだわると大変なので、たとえば、プライマリー (第1レベル) なストーリーをひとつだけ決めて、他をセカンダリー (第2レベル) なストーリーとする、という形でもよいと思います。プライマリーストーリーをスムーズに実現できるよう第一優先で設計することとし、セカンダリーストーリーは実現可能であればよい (プライマリーなストーリー実現を阻害する恐れがある場合はプライマリーストーリーを優先しつつ) という具合です。このあたりは「プライマリーペルソナ」「セカンダリーペルソナ」の考えかたに近い感覚です。

もちろん、プライマリーストーリー以外のストーリーが多すぎる場合は、もう少しレベル分けしてもよいでしょう。個人的な感覚としては、ターシャリー (第3レベル) なストーリーくらいまではあってもよいかな、と思います。

ユーザーストーリーをもとにコンテンツやナビゲーションを洗い出す

ユーザーストーリーの整理と優先度付けができたら、ストーリーごとに、どんなコンテンツが必要かを洗い出します (最終的には、コンテンツインベントリーやサイトマップとしてまとめるとよいでしょう)。また、ペーパープロトタイピングなどによって、各ストーリーの実現に必要なナビゲーションやラベリングも検討します。たとえば、セカンダリーなストーリーに対しては、サイト共通のナビゲーションシステム (グローバルナビなど) で導線を明示的にするが、ターシャリーなストーリーに対してはホーム (トップページ) の補足的なエリアやビッグフッターからの導線があればよい、といった具合です。

コンテンツやナビゲーションを検討する際には、コンテキストのバリエーションも同時に意識しましょう。同じ内容のユーザーストーリーであっても、コンテキストが異なることで解決方法が異なることもあるからです。ユーザーストーリーごとに、想定されるコンテキスト (利用デバイス、場所、日時、など) も併せて書き出しておくと、コンテンツやナビゲーションを設計する際のヒントになります。

課題 (プロジェクトを通して共感できるツールとして)

ユーザーストーリーは手軽で導入しやすい手法ではありますが、プロジェクトが進んでゆくにつれて、単なる「定型文の羅列」になってしまうかもしれません。ストーリーを作った時点では共感できても、その共感がプロジェクトを通じて維持されるか、プロジェクトの折々で立ち返ることができるコミュニケーションツールとしてストーリーが機能するか、が課題だなと感じます。

そもそも、ユーザーストーリーのフォーマットには「誰それさん」を端的に示す情報が無いこともあり、プロジェクト内のちょっとした会話の中で、特定のストーリーを指し示すのが案外難しかったりします。[role (ある特定の役割や立場)] の記述はありますが、それを手掛かりにプロジェクト内で会話しても、どうもまどろっこしいのです。以下のような工夫で「誰それさん」情報を付加するのも一考かと思います。

この他にも、特に優先度の高いユーザーストーリーについては、より詳細にペルソナやシナリオ (あるいは To-be なカスタマージャーニーマップやストーリーボードなど) を用意してもよいでしょう。プロジェクト進行中もユーザーに対する共感を維持するために、できる工夫を採り入れてみたいものです。

ユーザー本人にストーリーを書いてもらうという手も…？

ユーザーストーリーは、フォーマットが明確で、一文で書けて、また主語が一人称 (私) なので、実際のユーザー自身に書いてもらう、ということも難しくないでしょう。ユーザーにインタビューする機会やサーベイを実施する機会があれば、ついでに (ユーザー本人の視点で) ユーザーストーリーを書いてもらい、それらを蓄積し、分析して設計に活かす…ということもできそうです (私自身はやったことがありませんが、いつか試してみる機会があれば、と思います)。