[レポート] UX DAYS TOKYO 2019 サービスデザインを用いた、楽しませる規模を拡大させる体験の設計

[レポート] UX DAYS TOKYO 2019 サービスデザインを用いた、楽しませる規模を拡大させる体験の設計

Clock Icon2019.04.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

4/5-4/7 に行われた UX DAYS TOKYO 2019 でのワークショップの中の一つである「サービスデザインを用いた、楽しませる規模を拡大させる体験の設計」に参加しました。その内容をお伝えします。
10時開始18時終了、昼食を含めると合計で8時間のワークショップでした。
サービスデザインとは何か、どのように実践するか、とても学ぶことが多い充実したワークショップでした。
英語同時通訳の進行でしたが、参加できなかった方に内容を出来るかぎり正確にお伝えできればと思います。

ワークショップ

スピーカーの Nick Remis さん(ヘルスケア企業コレクティブヘルス社のリードデザイナー)がスライドを交えてプレゼンした内容を、途中で何度かテーブルごとのメンバーで実践を行う形式でした。

1. Quick review of service design

  • 物理的ではない(物理的に触れるようなことができない)サービスがある
  • 無形であるサービス
    • 例えば、Adobe 社が消えたら Adobe Creative Cloud は利用できなくなるが、パッケージ版(CD)であれば、Adobe 社が消えても手にのこる
  • サービスは関係性が伴い、常に客との接点を持っている。
    • サイクルを持っている
    • 例えば、中断すれば、再開ができるような設計を念頭に入れる必要がある
  • 同じサービスであっても、異なるオーケストレーションができる
    • オーケストレーションとは様々な事象が組織立って一つになったもの
    • 例えば、従業員と会話せずに決済 or カウンターで注文 or 席でオーダー 等
    • オーケストレーションが異なれば、サービス体験は全く異なったものになる
  • サービス体験は望むべき結果を達成するために、全ての複雑性をオーケストレートして考える必要がある
    • ユーザー体験であれば、時として単一のタッチポイントしか存在しないことはある
  • Service design ( SxD )では、客とどのような関係を持つだけではなく、スタッフがどう関わるか、オペレーションや構造、カルチャーをオーケストレートする必要がある。
  • Core principles of SxD
    • Human-centered
    • Co-creative
    • Orchestrated
    • Tangible 例)会話をよりスムースに進めるために、有形な体験として手に取ったりできるようにする
    • Holistic エンドツーエンドで包括的
  • サービスデザインは一人だけの仕事ではない
    • すべての関係者をパートナーとして巻き込む必要がある
    • 最終的なサービスでは色々な人が稼働するから
    • この辺でデザイナーが一人で頑張って失敗することが多い
    • 連携を取らないと、非現実的なものをデザイナーとして作ってしまうかもしれない可能性がある
  • プロダクトではなく、サービスを管理している、というスタンス
    • だけど、いまでも巷ではプロダクトありきという固定観念が蔓延っているのはたしか
  • 自分たちのチームを超えて連携するのが大事
    • エグゼクティブと話すのも大事
    • トップダウンだと連携しやすいが、ボトムアップでも可能
      • モバイルとウェブの連携、次にマーケティングを巻き込む、とか
    • ゆっくりと時間をかけて連携していくのも一つのやり方
    • 立ち上げの時は特に大変

2. Current-State Blueprints

  • サービスにはフロントステージとバックステージがある
    • ディズニーランドの a magical trash story の話
      • ディズニーランドにはゴミがないし、間違ったキャラクターが場違いなアトラクションに立っていることもない
      • ディズニーは初めからその仕組みを考えた
      • パークの下に都市を作った
      • ゴミの処理をしたり、社員を動かしたり
      • 上が体験(客に見える)、下が魔法(客から見えない)
    • デジタル体験においても、モバイルとなどの画面がタッチポイントとなるが、バックステージではサーバー保守やコーディングをする人がいる
    • 意図的にバックステージを設計しないと、全てを客任せにすることになる
      • そうなると、サービス体験としては最低
    • 例えば駅においては、タッチパネル、順番を示すモニター、足元の順路表示、従業員との会話を経てチケットを変える流れがあるが、それは誰かによって設計がされたものである
  • サービスブループリントとは
    • ブループリントはオペレーショナルツールであり、プロセスや相互作用を表す
    • 客にとって、そしてスタッフ(フロントステージ/バックステージ)やサポートがオーケストレートするため理想を示す
    • どのように使うか
      • 既存のブループリント(Current-State Blueprints)によって現状を知る
      • 未来のブループリント(Future- State Blueprints)によって、最終的にこうなる、プランやプロトタイプを示す
    • サービスブループリントの価値
      • Visualize...
      • Align... チームの連携
      • Prototype...
    • ブループリントの特性
      • MULTI-CHANNEL
      • 360° VIEW 多面的な見方
      • ORCHESTRATION
    • Blueprint building blocks
      • ブループリントの中にイメージを埋め込むのも可能
      • 大きなビジョンの中で個々を確認できる
      • ズームのレベルを考える
        • どれだけ詳細にするか、一部に焦点を当てるか、など
        • 十分でないと思ったら、ズームインして何が足りないのかを突き止めていく
    • 使うツール
      • ポストイット、スプレッドシート、オンラインツール 等(この日は模造紙とポストイットを使用)
    • 今回のワークショップのスピーカーであるNickさんによって書かれたサービスブループリントに関するガイドです(必読)

実践

  • 航空会社のデザインチームという設定で Current-State Blueprints を作成しました

3. Service Storming

  • 新サービスのアイデアを産むために、実際に演じる手法
    • 実演しましたが、寸劇のようなものを演じました(例:Aさんはスマホ役)
  • サービスとは劇場で演じられているようなパフォーマンスである
    • サービスは異なる要素を集めて体験として提供する
    • 物事を簡単に変えたり、全体を評価することができる
    • たとえば、キオスク(役)の話し方にしても、礼儀正しく話したり、フランクにしたり、幅を持たすことができる
    • 感情的で移ろいやすい人間的な表現により、ドラマを生むことができる
  • サイエンスとアート
    • サイエンス的側面:実際に体を動かして脳の違う領域を使うことでの気づきはである
    • アート的側面:演じてみて、それを観た人の心を動かしたなら、それはうまくいく可能性が高い
  • サービスストーミングアはサービスデザインのプロセスを通して使えるし、すばやくリファイメントできる
  • サービスストーミングのコツ
    • NO SITTING
    • NO PITCHING (売り込みのようには演じない)
    • PAUSE, REWIND, ITERATE

実践

  • 3つの軸からひとつのアイデアを選択してそれに沿った Storming にする制約がありました
    • ハイテク
    • 食べ物が充実(これを選択しました)
    • 豪華な旅
  • 私のグループ(5人)では、私はボディスキャナーの右側面、機内の添乗員という役柄でストーミングしました
  • どのグループでも演る方も観る方も楽しく気づきが得られており、チームビルディングとしての機能もあると思いました

4. Storytelling

  • どんなビジョンを持っているか、簡単に伝え、共通理解を促すことができる
  • 構成要素を明確化し、感情・情熱も伝える
  • 明確な始まりと終わりを示す
  • UIデザイナーであれば静止画で伝えるが、一方でサービスデザイナーであれば時間軸で語る
  • ストーリーテリングのタイプ
    • SERVICE STORMS
    • STORYBOARDS
      • 今回のワークショップではこれを作成しましたが、4コマ漫画とそのコマ毎の説明を書く、という感じでした。
      • より詳細には、ストーリーのタイトル / コマ(Key Moment)タイトル /1、2センテンスの説明 / そのフィーチャーです
    • VISION STORIES
    • EXPERIENCE VIDEOS
  • 盛り込む要素
    • Key moments and interactions
    • Emotions and thoughts
    • Context
    • Time!
  • 戦略がどんなものであっても、ベストなストーリーを持っているプロジェクトが成功する

実践

  • 四コマ漫画風の絵とその説明を描きました
  • とても良いものができたのですが、写真撮ったと思ったら撮れていなかったので、載せられません…すみません

5. Future-state Blueprints

  • 開発を始める前にオペレーションの流れを計画・プロトタイプするために作成する
  • Service Storming や Storytelling を通して描いたビジョン・ストーリーを加味して作成する
  • ステークホルダーとの関わりにおいては、service blueprintで始めるのではなく、まず service vision に興味を持ってもらってから、service blueprint を作成してオペレーションを示すようにする
  • future-state blueprint の成果
    • 未来の体験のプロトタイプ
    • 顧客側の体験、オペレーション側の体験のコンビネーション
    • プランニングの際の戦略ツール
  • ブループリントの中身は事業に合わせてカスタマイズする
  • 比較をするために、future-state blueprint は current-state blueprint の下に貼る
    • future-state に向けてどのような変化や創造が必要なのかが比較できる

実践

  • このワークショップでは限られた時間の中で迅速に進める必要があったので、future-state blueprint と current-state blueprintに共通する付箋は future-state blueprint の方には貼るのを実質的には省きました 

6. Evolving services

  • 例えばケーキで言えば、スポンジだけのケーキを食べたい人はいない
    • なので、スポンジ → 中の具 → デコレーション のようなスケールの仕方はよろしくない
    • ケーキをスケールしたいなら、カップケーキ → バースデーケーキ → ウェディングケーキ というスケールの仕方が必要になる
    • どのステートにおいても市場に出せばちゃんと機能するサービスとして提供されている、ということです
  • 少ない機能ではあるが、品質が高ければうまくいく
  • たくさん機能があっても、品質が低ければうまくいかない
  • アイデアをサービスの形にするのはとても大変
  • evolution plan を定義する
    • evolution map の要素
      • DESCRIPTION
      • CUSTOMER VALUE
      • BUSINESS VALUE
      • FEATURES / FUNCTIONALITY
      • SKILL SET
    • evolution map の考慮すべき点
      • mapはどこに向かっているか
      • それぞれのステージでどのスコープにするか
        • MVP ではじめる 等
      • ステージからステージの移行の際の体験の設計
    • evolution map が説明する要素
      • 競合
      • 組織構成
      • リスク
      • やる / やらない
      • 革新
  • Feature card & Project Card
    • Feature card
      • カスタマーが受ける体験が書かれたカード
    • Project Card
      • Feature をカスタマーに届けるために必要となるプロジェクト
    • それぞのれカードには名前 / 説明 / 依存関係 / 価値(重要度 / 期間 / 投資 ※三段階で評価)で記載
    • 例)
      • Feature Card: ロボの犬がカスタマーの荷物を運ぶ
      • Project Card: ロボの犬の開発、犬の電気チャージャーの用意 etc
  • カスタマーに届く価値が意識できることが重要
  • どんなシンプルな価値を提供できるか、からはじめてそれを進化させていく
  • 初めはテクノロジーを入れない方がピボッドさせやすい
    • 人ができる部分はシステム化(デジタル化)せずに人が運用する、など
    • いきなりテクノロジーを入れるとコストがかかる
  • 先の話になる場合、あまりディテールを作り込み過ぎない方が良い

実践(Feature card & Project Card)

まとめ・所感

  • 個人的な経験として、これまでにデザイナーとして参加したプロジェクトではユーザーストーリーマッピングなどの手法を取り入れていました。しかし、例えば、既存のアプリの改修が主となるプロジェクトでは、既存のアプリが存在しているため、それをどのように扱うかについては疑問に思っていました。しかし、今回のワークショップでは、(未来だけではなく)現在のステートを考慮する手法だったため、痒いところに手が届いた気がしました
  • current-state blueprint とはデジタル化されているオペレーションに限らず、デジタル化されていないサービスのデジタル化(受託開発・新規事業に限らずこういったケースが結構あるかと思います)にも適用可能な手法ですので、とても有用だと思います
  • サービス全体を包括的にオーケストレート・デザインする必要性を十分に理解しました。
  • 質疑応答の際には、突っ込んだ難しい質問も出ていましたが、スピーカーの Nick さんは的確にその意図を汲んで、ご自身の経験をに基づいた実践的な回答をされていました。ワークショップの質も非常に高かったですが、その辺りのプロフェッショナルさもリスペクトを感じました
  • 参加されている方々も英語がペラペラだったり、統率の力や説明の能力が非常に高い方ばかりで、とてもよい刺激を受けることができました
  • 日本の場合だとデザイナーという括りで一連の業務をすべてこなすことが多いように思いますが、海外では明確な分業があるような印象を受けました。(サービスデザイナー / オペレーションマネージャー / デザインマネージャー / コミュニケーションデザイナー 等)

リンク

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.