こんにちわ。INVITROの小蔵です。Design Strategistとしてサービスデザインを中心とした課題解決を行なっており、社内ではDesign Managerとしてメンバーの育成やデザインプログラムの設計と実施などをやっております。 今回は弊社でいつも使っているUXのアウトプットであるService Workflow Mapを紹介したいと思います。プロダクトやサービスを作っているデザイナーさんやPdMさん、UXリサーチャーさんがサービス設計する際の全体像の把握と共有を簡単にしてくれる便利な方法です。

こんな風に便利

• サービス全てのUXをEpic storyで時系列化する

• 確実に発生するワークフローをアドホックに検討し次第にMECEにできる

• IAの文字列だけだと気がつけないロールプレイヤー間の関わりやアクションのステップに気がつける=抜け落ちてしまうものを視覚化し、より詳細に検討する

• プロジェクトの規模が大きい時に活躍する整理方法

• 調査や検討結果を記録でき、再利用やコミュニケーションの中心にできる

最後のほうにFigmaのテンプレートファイルを公開しているので是非本稿お目通しの上ご利用いただければと思います。
noteの画像仕様のため雰囲気しか見えない感じになってしまいましたので、具体的にはFigmaファイルからご確認いただければと！

Service Workflow Mapを使ってサービス全体のUXをチームで計画しよう

UXデザインはターゲットセグメントの代表となるペルソナに焦点を絞ってUXを調査し、ペインやニーズをもとにサービス上で体験するタッチポイントをデザインしていくアプローチです。
カスタマージャーニーマップ（CJM）などの流通しているUX資料の形式では、カスタマーの体験は定義できますが、複数のペルソナやサービサー側のオペレーター、管理者などのロールプレイヤーが登場すると記述が難しくなってしまいます。
サービスに登場するロールプレイヤーはエンドユーザー（カスタマー）ではなくてもユーザーなので、各種のオペレーションやシステムとのインタラクションが数多発生します。
そのため、Service Workflowmapで開発の有無にかかわらず作りたいサービスの全体像が時系列で計画し、誰がいつどのシステム内外でどんなアクションをするかを明示する必要があります。それによりボトルネックやISSUEの発見、開発必要性の有無の判断をチームで理解しやすくなります。
エンドユーザーのUXは担当者がいてもその他のロールプレイヤーやサービス全体のUXに責任を持つ人がいなく、気の利いた末端人材の有無に左右されてしまうプロジェクトは意外と多いのではないでしょうか。サービス全体のUXを一人のUXリサーチャーやデザイナーが担当するのはかなり大変ですのでチームで効率良くやるのがいろいろな面で良いのではないかという気がします。

ユースケース:どんな時にService Workflowmapを使って何を検討できるのか

①UX調査,デザインエスノグラフィの調査結果として使う

その組織にとって新規のインダストリー案件で現場オペレーションやステークホルダー間でなされるコミュニケーション(アナログ・デジタル両者）の記録などインダストリーの固有性と共通前提、フレームワークやISSUEの抽出に使います。コンサルティングファームが行なっているナレッジマネジメントのように、インダストリー毎にワークフローやフレームワークを蓄えて行けるのも良い点ですね。

②新規事業のワークフローとシステムの検討に使う

前述の調査結果を受けて新しいサービス・システムを作ろうとなった場合にそのサービスの全ワークフローと作るべきシステムを検討に使います。該当のロールプレイヤーやペルソナがサービスに関わるアクションをする際のインタラクションを網羅的に検討し、ビジネス上の検証すべき仮説やISSUEのリストアップを行なったり、エンジニアリングの必要性などを共有します。

③既存事業のワークフローとシステム視覚化に使う

既存事業の改善業務にアサインされた、事業をリードしているがナレッジマネジメントに課題があるなどといった場合に既存事業をまとめる意味でService Workflowmapを作成します。各担当者の知識として暗黙知となっている重要な情報を集める、誰も言語化できていなかったボトルネックを発見する、サービスの最適化を進める際に利用できると思います。どんなサービスなのかが把握できたら、改善版の検討を行いましょう。

一つの情報設計でUIデザイン(以降のアウトプット)につなぐことができる

ビジネス・UX調査-IA-UIデザイン-プロダクトバックログ-開発-テストという一連の流れをユーザーストーリーマッピング（弊社ではEpic-Storyという名称)の形式で情報設計することで各検討フェーズへアウトプットを効率よく繋いでいくことが理想です。
Service Workflowmapを作るときにはもとになるEpic-Storyがあり、その情報を引き継ぐ事でどういうコンテクストと必要性から画面や情報、アクションが必要になるのか理解しながらUIデザインを行うことができます。

プロジェクトのステークホルダーに共有し、チーム内の共通認識として一箇所で運用できると良い

どんなナレッジでも共通して言えることですが、プロジェクトの内外ステークホルダーがUX資料を一箇所でみることができると共通認識として運用しやすくなりとても良いと思います。
本稿の場合はFigmaファイル上にペルソナ資料(ペルソナ資料は今回は割愛しています)やService Workflowmapを集約して一箇所で管理することでアクセスしやすいナレッジとして運用していくとう前提になります。

CJMやサービスブループリントとの違い

サービスワークフローマップとサービスブループリントは似ているがサービスワークフローマップはサービスブループリントとCJMが合体したような感じ
CJM(Customer Journey Map)、サービスブループリントとは必要に応じて使い分けするのが良いと思いますが、Service Workflowmapを検討する方針で、弊社の経験上困ることがあまりないです。

CJMのスコープ

スコープ
・エンドユーザーやカスタマーのタッチポイントや行動、感情を記述

課題
・誰がサービス全体のUXを担保するのか?
・他のステークホルダーのUXは言及しにくく、定義されていないプロジェクトは多いように思われる
・行動の文脈やステークホルダーやメディア間で往来する情報など付帯項目を記述しにくい
・網羅性が低くシステム全体を設計したい時に粒度感が違う

利点
・toCビジネスでカスタマー中心の大まかなUXの定義や抽出はしやすい。有名なフレームワーク

使い所
・カスタマーの課題解決やサービスの肝となるUXの設計

サービスブループリント

スコープ
・ステークホルダー全てと関連システムをダイアグラム的に記述
課題
・アクションの詳細度が低い
・細かいステークホルダー全てのUXを検討できない
利点
・サービスの全ロールプレイヤーと必要になるシステムの関係を検討できる
使い所
・システムを含めたサービスの大枠の計画 開発実装寄りの設計

サービスワークフローマップ

スコープ
・サービス全てのUXをEpic storyで時系列化する
課題
・全てのアクションを記述するので長大になる
利点
・確実に発生するワークフローをアドホックに検討し次第にMECEにできる ・IAの文字列だけだと気がつけないロールプレイヤー間の関わりやアクションのステップに気がつける=抜け落ちてしまうものを視覚化し、より詳細に検討する
・プロジェクトの規模が大きい時に活躍する整理方法
使い所
・サービス全体のUX検討や課題抽出、新規インダストリーの調査記録

Figmaでテンプレートを公開しています

リラックスやチルアウトをテーマに架空のEC事業＋SPアプリの新規事業のサービス像をWorkflowmapにしてみました。実際の検討ではないので記述精度はあまり高くなくビジネスモデルなども甘いですが参考になればと思います。UXタイムスパン毎にカスタマーがサービスにどのように関わったり行動したりするかや、サービサー側のアクションなども検討できるところが良いところではないかと思います。是非参考にしてみてください。

Figmaのテンプレートはこちら

需要あればService Workflowmapの具体的な中身の解説とかも書こうかなと思います。それではまた。