ストーリーボードとサービスブループリント

はじめに

こんぬづは、無職の田中です。

最近知り合いのデザイナーさんにデザインについて教えてもらう機会があり、その中で「ストーリーボード」と「サービスブループリント」というものが出てきたので、知識を固めるために自分でも調べ直しました。今回はそのまとめです。

サービスブループリントについては実際にワークショップをやってもらったので、少し分量多め。

ストーリーボード

共感を測るためのツールという印象。(「印象」と書いたのは、ネットをナナメ読みしたからそんなに自信が無いのと、人によって認識が違いそうだったから)

画像や絵を使って、ユーザーの感情や行動をストーリーに落として、そのストーリーに共感できるかどうかでサービスの価値を図ることにつなげる。

ユーザーテストじゃないけど、ストーリーボードを組んで人に見てもらうのは、市場調査段階でやると良さそう。

参考

サービスブループリント

ユーザーがサービスをどこから知り、どんなプラットフォームを介して触れるのか(タッチポイント)に重きを置いている印象。

具体的なビジネスに落とし込んで考えているとも言えそう。 ある記事には「ビジネスセッション」と「テクニカルセッション」という2つのセッションでこのツールを使っていくことが書かれていた。 ビジネスセッションで、ビジネス上の理想形(青写真)を描いて、テクニカルセッションで理想を実現可能な形で落とし込む。

テクニカルセッションを経ることで、サービスを提供することができるかどうか測れるのが良さそう。

参考

ストーリーボードとサービスブループリントの違い

ストーリーボードとサービスブループリントは部分的に一致するところもあるが、サービスを提供する側の行動や提供するものまでを想定しているかどうかの違いがありそう。

ストーリーボード: 市場調査段階でやると良さそう サービスブループリント: 需要が見込めて、実現可能かを測るのに良さそう

という感じ。

感想

f:id:ktanaka117:20180523121640j:plain

違いでも書いた通り、それぞれ「使うフェーズが違う」と思った。

エンジニアは実現可能性に目を向けがちだと思った。 最近自分は技術的な面で1→10にするためのスキルを磨いている傾向にあると思っていて、0→1が弱いと感じていたのだけれど、今回触れた2つのツールには良いヒントがあった。

デザインを考える手法やツールはこれまでいくつか触れてきたことがあって、部分的に一致する様々なものがあるので混乱していた。今回人に教えてもらって、調べたことで「なるほど、こういう違いの傾向にあるのか、完全に理解した(←わかってない)」となれてよかった。

雑な理解だけど、もっと深く知るのはより必要になった時にまわそうと思う。

追記

デザイナーさんとは「本来【デザインする】って言った時は、こういったツール/フレームワークを使って深掘りするところから始めないと、どういう見た目にすればいいかも考えられない」なんて話もした。

確かにこの段階を踏まえないと、どういう目標地点に向けたデザインをすればいいかわからないと思った。これを踏まえないで【デザインする】ことって結構多いんじゃないかとも思った。

仕事を始めるとき、「うちの会社(やり方)ではお客さんとのヒアリングで最初にこれをやるんです」くらいに決め打ちをお客さんに要求してしまってもいい気がした。自前のサービスでも。