こんにちは、スマートバンクCXOのtakejuneです。最近はプロダクト本部という組織を立ち上げ、プロダクトマネージャー、デザイナー、UXリサーチャー、カスタマーサポートのチームをマネジメントしています。このチームでは、各職種の持つノウハウを型化して再現性を持たせる取り組みを行っており、その中で「Think N1 シート」というツールを作りました。このエントリーでは、その中身をご紹介したいと思います。

「Think N1 シート」とは？

「Think N1 シート」は、新しいプロダクトや機能のWhyとWhatを定義するための設計書です。

これを使うことで、N1インタビューからユーザーの課題を捉えて、それを解決する方法をさがす「スマートバンクらしいプロダクトデザインプロセス」を誰でも実行できるようになることを目指しています。シートと言っても、物理的な紙ではなくNotionのテンプレートとして、その特性を活かして作成しています。

ちなみに、「Think N1」はスマートバンクの3つのバリューの1つで「対話と分析を重ねて、本当に重要な課題を発見しよう」という意味が込められている、会社を象徴する言葉です。

blog.smartbank.co.jp

なぜつくったのか？

元々は、新機能を考えるときは Krafts&Co. 倉光さんの「ユーザーストーリーシート」、新プロダクトを考えるときは ROLLCAKE inc. 伊野さんの「ユーザー体験設計書」を参考にしていました。

でもやっぱり、自分たちが作ったものではないので使い方を完全には理解できていなかったり、実際のプロセスにピッタリとハマらないと感じることがあったんですよね。

なので、一度自分たちのプロダクトの作り方を棚卸しして、それをフォーマット化したドキュメントの型をつくろうと思ったわけです。

誰が使うものか？

機能やサービスを企画する人なら誰でも使えるものになっていて、スマートバンクでは主にプロダクトマネージャーが使うことを想定しています。

いつ使うものか

リサーチ → 要件定義 → プロトタイピング → 詳細設計 → 実装というプロセスの中のリサーチ〜要件定義で使います。Think N1シートが書けているとユーザー課題と提供価値に対する解像度が高まっているので、自信をもってプロトタイピングに進むことができます。

どうやって使うのか

どんな課題を解決すべきかをクリアにする「課題定義」→ どんな価値を提供すべきかの「価値定義」というステップで進めていきます。

1. 課題定義

まず最初のステップは、ユーザーの課題をまとめた「課題仮説」を書くことです。次の表を書けるところから穴埋めしていきましょう。

誰が、どんなときに、何をしたくて、何によって実現できず、どんな代替手段で解決していることから、どんな課題があることがわかるのか、想像を巡らせて記述してみましょう。

書いたことが間違っていても構いません。というかほぼ確実に間違っています。大切なのは次のステップで、ユーザーにN1インタビューを行うことです。

N1インタビューを重ねながら「何を知らないのか」「何を知っているのか」をDiscovery Boardというデータベースに記録していきます。そして、それを参考に次回のインタビューでユーザーから聞き出すことを検討します。

(※リサーチ手法については過去にリサーチャーのharokaさんが書いた記事や書籍はじめてのUXリサーチを参照してください。)

そうして 確認済み の項目が増える毎に課題仮説を随時見直していきます。

最初は想像によって課題仮説を書き、インタビューを通じてそれを覆していくのがこのプロセスの醍醐味です。最初は慣れないかもしれないですが大丈夫です。すぐに自分の仮説が覆ることに喜びを感じるようになります。

インタビューのログは個別のページに残しておき、ある程度の量が集まったらインタビューから得られた洞察をまとめていきます。

2. 価値定義

次にインタビューから得られた洞察を基に「価値仮説」を書いていきます。このフォーマットはユーザーストーリーシートとほぼ同じですが、課題仮説とリサーチをベースに書くというプロセスが最大の違いです。それにも関わらず、価値仮説もインタビューによって二転三転することがあります。しつこいようですが、私たちはそれが重要だと思っています。

次に、価値提供の先にあるユーザー・社会・私たちの「長期的ゴール」を考えます。使い続けることで積み重なるユーザーにとっての価値は何なのか、それが社会にどのような影響を与えて、結果的に自社にどのような利益をもたらすのかを記述していきます。

これを書く意味はいくつかあって、まずサービスには「初めて使った瞬間得られる価値」と「使い続けることにより積み上がる価値」の2つがありますが、後者を意図的に作っていくためにもこれを書いたほうが良いと考えています。

またこれがあると遠くまでの見通しが良い状態で「あるべき姿」を考えられるようになります。そうするとやるべきでないことが明確になり、シンプルに素早く意思決定できるようになります。

そして、価値仮説を実現するために「提供すべき利便性」を考えます。ここはまだ書式の改善が必要だと思っているのですが、長期的ゴールを実現するために必要なことや、ユーザーの生活のどの部分にどのようにハマって習慣化されるのかを意識して書いていきます。

この後はどうしたらいいの？

次のステップとしては、定義した価値仮説・提供すべき利便性の実現方法を考えるために、デザイナー主導でPMが伴走する形でプロトタイピングに入っていきます。 Howを定義するための設計書「Be Openシート(仮)」もいま開発中なので、また別の機会にご紹介できればと思います。

よくありそうな質問

疑問に思われそうな点について、いくつか補足説明をさせてください。

実際には施策(How)の方を先に思いつくものでは？

課題仮説・価値仮説よりも先に良い施策を思いつくこともよくあるので、その場合はアイデアの検証をThink N1シートを使って行いましょう。重要なのはデザインプロセス全体を反復的なプロセスと意識することです。

他に仕様書的なものはあるの？

プロジェクトの概要・制約・優先順位など詳細な情報を記述する、PRDと呼ばれるようなドキュメントが別途ありますが、これはプロトタイピングを進めながら出来ていくことが多いです。どちらが先にあるべきかの厳密さにこだわるのでなく、どれから書いたとしても必要なだけリサーチを繰り返しながら内容をアップデートすることを意識しています。しっかりやると、全体を1回は書き直すことになるんじゃないかと思います。