「ストーリーマッピングをはじめよう」を読んだ
本を読んだらまとめる癖をつけよう…その第一弾。
人間は筋道がたっているのを求める
ストーリーには構造があるという話から始まる。
本書では、ストーリーの構造を「ナラティブアーク（導入からクライマックスまで盛り上げていき、最後に落とすという起伏を表現する曲線）」と、それに沿った「7つのフェーズ」に分類して説明している。
ナラティブアークに沿ってストーリーを作ることは、ストーリーに起伏をつけることになる。これによって、ユーザにプロダクトを強く印象づけることができるし、オチやエンディングを設計することでクリフハンガー（ユーザの気持ちが最高潮に高まったところから、一気に落とされて印象に残らない、あるいはネガティブな印象を残すこと）を避ける効果があるとのこと。身近なプロダクトで今すぐ考えたほうがいいと感じた。(参考: ピーク・エンドの法則 - Wikipedia )
また、筆者による実際の映画やプロダクトを分析した実例がたくさん載っているので、実際にやってみるときのイメージがつかみやすいのも良いと思う。
3種類のストーリー
実際のプロダクト（特に既に世に出ているもの）のストーリーを収集し、マッピングしようと思うと超巨大なマップになってしまって、「そうだね。さて次は？」となってしまった経験はあるだろうか？（私はたくさんある…）
他の書籍でも様々な手法が提案されているが、本書では以下の3つに分類することを紹介しいている。
- コンセプトストーリー
- オリジンストーリー
- ユーセージストーリー
プロダクトのフェースや目的、あるいはチームの状況に合わせて、最初にユーザの心をつかむことに注力したいのか、ユーザのある特定の問題を解決してファンになってもらうことに注力したいのか、あるいはユーザも気づいていない潜在的な欲求を根本的に解決したいのか。どれに注力するのかが明確になっているのであれば、自分たちに必要な部分を同じフレームワークでマッピングすることができるのは、共通言語という意味でも勝ちがあるように思う。
まとめ
プロダクトを使うユーザのエンゲージメントを獲得したいなら、デザインスべきはシステムはなく、人間の体験です。システムは複雑です。しかし人間の体験は1本の線です。体験は時間の流れに沿ってしか起こりません。
最後の章にある文章が印象に残っている。「複雑だから」「たくさんの機能があるから」という言葉に負けずに、ユーザの体験をデザインしなければいけないし、それは人それぞれではあるけど時系列に並ぶ一本の線になる。
