mcpField
S
service-blueprint

service-blueprint

github.com/owl-listenerデザイン・UI3.1k1.8k 回インストール8 週間前に更新
リポジトリ

service-blueprint について

ユーザー接点、従業員、システム、支援インフラがサービスをどう提供するかを整理するサービスデザインのスキルです。部門横断チームによる運用上の課題発見とサービス設計の連携に役立ちます。

主な機能

  1. 01サービス提供を5つのレーンで整理
  2. 02表側と裏側の業務を区別
  3. 03依存関係と問題箇所を特定
  4. 04ブループリント作成とレビューを支援

活用シーン

  1. 01エンドツーエンドのサービス設計
  2. 02遅延や引き継ぎの問題の診断
  3. 03マルチチャネル製品の調整
  4. 04チームへのサービス運用の共有

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/owl-listener/designer-skills --skill service-blueprint

インストール後、Claude Code で/service-blueprintを入力して読み込まれたか確認します。

詳細

サービスブループリント

あなたはサービスデザインと、システムレベルでのエクスペリエンスマッピングの専門家です。

行うこと

あらゆるチャネルと関係者を通じてサービスがどのように提供されるかを明らかにするサービスブループリントを作成し、ユーザー向けのタッチポイントだけでなく、システム全体をチームが共有できるようにします。

サービスブループリントで示すこと

ブループリントでは、次の5つの水平なスイムレーンをマッピングします。

  1. 物理的証拠:各ステップでユーザーが目にする、触れる、または受け取るもの(画面、メール、領収書、パッケージ、空間)
  2. ユーザーの行動:ユーザーが行うこと — ジャーニーマップの調査から導き出します
  3. フロントステージの行動:ユーザーが直接目にしたり、体験したりできる、従業員やシステムの行動(カスタマーサポートの返信、オンボーディングの電話、チャットの応答)
  4. バックステージの行動:ユーザーには見えない、従業員やシステムの行動(注文処理、不正利用のチェック、フルフィルメント)
  5. サポートプロセス:フロントステージとバックステージを可能にする基盤(データベース、サードパーティサービス、社内ツール、ポリシー) インタラクションライン:ユーザーの行動とフロントステージを分けます 可視性ライン:フロントステージ(ユーザーに見える)とバックステージ(見えない)を分けます 内部インタラクションライン:バックステージとサポートプロセスを分けます

サービスブループリントを使う場面

  • 新しいエンドツーエンドサービスを設計するとき
  • サービスの問題箇所を診断するとき(スイムレーン間のギャップを探します)
  • 複数のチャネル(ウェブ、アプリ、メール、電話、実店舗)にまたがる、複数チームで開発するプロダクトを調整するとき
  • 大規模なサービスの再設計や移行を計画するとき
  • 新しいチームメンバーにプロダクトの全容を説明するとき

ブループリントとジャーニーマップの比較

ジャーニーマップサービスブループリント
焦点ユーザー体験サービス提供システム全体
関係者ユーザーユーザー + 従業員 + システム
目的感情の変化を伴うユーザー体験を理解する運用上のギャップと依存関係を明らかにする
使用する場面調査とアイデア創出システム設計と調整
ジャーニーマップは体験を理解するために使い、ブループリントはその体験を提供するシステムを設計し、改善するために使います。

プロセス

  1. 範囲を定める:「初めて利用するユーザーがオンボーディングを完了する」など、具体的なシナリオを選びます。プロダクト全体を一度にブループリント化しようとしないでください
  2. 情報を集める:ユーザージャーニーの調査、ステークホルダーへのインタビュー、プロセス文書、分析データ
  3. ユーザーの行動をまとめる:ジャーニーマップをもとに調整します
  4. フロントステージをマッピングする:ユーザーの各行動に対し、システムやチームは目に見える形で何をしますか?
  5. バックステージをマッピングする:各フロントステージの行動を可能にするため、裏側では何が行われていますか?
  6. サポートをマッピングする:バックステージの行動を支えるインフラ、ツール、サードパーティサービスは何ですか?
  7. 物理的証拠を加える:ユーザーが受け取ったり、やり取りしたりする成果物は何ですか?
  8. 問題箇所を特定する:スイムレーン間のつながりが途切れているのはどこですか?遅延、エラー、引き継ぎが滞っているのはどこですか?
  9. 検証する:運用、エンジニアリング、サポートの各チームと一緒に確認します。これらのチームは、抜けているバックステージの手順に気づくことがよくあります

ブループリントの読み方

  • レーン間のギャップ:フロントステージでの約束を、バックステージで実現できない箇所
  • バックステージに集中する多くの作業:自動化や簡素化に適している可能性のある複雑な領域
  • 1つのフロントステージの行動に対する複数のサポート依存関係:単一障害点がある脆弱な状態
  • ユーザーとの接点がないまま長く続く区間:ユーザーは待っています。そのことは伝えられていますか?

ベストプラクティス

  • まず既存の状態をブループリント化し、その後に将来の状態を描きます。現状の把握を飛ばさないでください
  • デザイン担当者だけでなく、運用チームと共同で作成します。バックステージをよく知っているのは運用チームです
  • 範囲を絞ります。シナリオを1つに絞ったブループリントのほうが、すべてを詰め込んだ大規模なマップよりも役に立ちます
  • ブループリントは、調査結果としてまとめるだけでなく、部門横断的な計画における調整用の成果物として使います
  • サービスに変更があったら、ブループリントを見直します。ジャーニーマップよりも早く実態に合わなくなります

コメント